Generalise rofi spreading#23
Conversation
409852a to
51a7084
Compare
There was a problem hiding this comment.
Should we move this to after
med_map_field_packed( &
FBSrc=FBrof_r, &
FBDst=is_local%wrap%FBImp(comprof,compocn), &
and use FBImp(comprof,compocn) instead for consistency across components ?
There was a problem hiding this comment.
I'm having second thoughts about this suggestion.
As FBImp(comprof,compocn) is fields on the ocean mesh, which includes a landmask, does this mean than any runoff over land cells got discarded before the spreading happens? Rather than getting redistributed at the spreading step
There was a problem hiding this comment.
Does the mapping from rof to ocn mapfcopy? If so, that doesn't use the masks so should be fine.
Happy to move it back, agnostic either way.
There was a problem hiding this comment.
Nah it uses conservative. But either way doesn't the portion over land get discard moving from a nomask to mask mesh ?
New suggestion, how about the hemisphericaly sum of runoff volume is calculate on the incoming mesh (rof/atm), and then applied on the outgoing mesh (ocn)
| character(*), parameter :: u_FILE_u = & | ||
| __FILE__ | ||
| character(len=9), parameter :: fields_to_spread_runoff(1) = & | ||
| ['Faoa_rofi'] |
There was a problem hiding this comment.
did rofi and rofl get seperated elsewhere ?
There was a problem hiding this comment.
In access-esm rofl only contains the river runoff, and rofi contains both the iceberg basal and calving melt fluxes. The spreading here simultaneously does your calving flux spreading + a coastal distribution for the basal melt. Is that what you meant?
There was a problem hiding this comment.
Oh - ah, I think it's better to have seperate steps in the mediator for basal and iceberg right ?
basal fraction, gets remapped with a fixed remapping weights file to put it along coastlines
and iceberg gets spread like this change
There was a problem hiding this comment.
It would be great if what was done was as close as possible consistent with OM3.
So that would mean splitting the iceberg and basal proportions before they leave the mediator. And having separate rofi/rofl fields to correspond to the MOM fields. It's relatively clear in the MOM diagnostics that rofi should be for the iceberg fraction - e.g. https://github.com/ACCESS-NRI/access-om3-configs/blob/b14a2797812531d5b4728f04cd67dcee19bfe439/docs/available_diags.000000#L4548, although less clear about the liquid proportion (e.g. there are lrunoff_glc fields available which OM3 doesn't use). Having separate fields for rofi and rofl means the rofi spreading input file can be the same across the two models. It also supports future/ongoing work to figure out how to spread the basal melt fraction vertically
The proposal to put the basal melt component in rofi by having a single pattern with 50% of the volume at the coastline will continue to give issues with supercooled water & excess sea ice from the large latent heat flux at the coastlines.
Co-authored-by: Anton Steketee <79179784+anton-seaice@users.noreply.github.com>
Co-authored-by: Anton Steketee <79179784+anton-seaice@users.noreply.github.com>
Co-authored-by: Anton Steketee <79179784+anton-seaice@users.noreply.github.com>
This PR generalises the rofi spreading to be used by arbitrary components. It also applies it in the post atmosphere phase for access-cm3.
In CM3/ESM3, to account for latent heat and conserve energy, all iceberg runoff (calving and basal) is passed to the frozen runoff field. Because of this, the basal and calving spreading is combined into a single weight file. The 50/50 split between basal and runoff is encoded in this file.
To make this easier to generalise, this change removes
spread_rofi_nhandspread_rofi_shfrommed_phases_post_rof_spread_rofiandmed_phases_post_rof_init_rof_spread_rofi.I'm pretty sure this doesn't change the logic. These seem to be either both
trueor bothfalse. If truemed_phases_post_rof_init_rof_spread_rofiis called, if there's an inconsistency in the spreading weights, one/both of these are set tofalseand an error is thrown. If the program continues/no error is called, then these are still bothtrue. The same applies tomed_phases_post_rof_spread_rofi. So I think it's safe to assume thatspread_rofi_nhandspread_rofi_share true in these subroutines, and just throw an error if there's an inconsistency in the weights.Associated
access3-sharePR