Skip to content

Generalise rofi spreading#23

Open
kieranricardo wants to merge 14 commits into
cmeps1.1.35-xfrom
generalise-rofi-spreading
Open

Generalise rofi spreading#23
kieranricardo wants to merge 14 commits into
cmeps1.1.35-xfrom
generalise-rofi-spreading

Conversation

@kieranricardo

@kieranricardo kieranricardo commented Jun 15, 2026

Copy link
Copy Markdown

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_nh and spread_rofi_sh from med_phases_post_rof_spread_rofi and med_phases_post_rof_init_rof_spread_rofi.

I'm pretty sure this doesn't change the logic. These seem to be either both true or both false. If true med_phases_post_rof_init_rof_spread_rofi is called, if there's an inconsistency in the spreading weights, one/both of these are set to false and an error is thrown. If the program continues/no error is called, then these are still both true. The same applies to med_phases_post_rof_spread_rofi. So I think it's safe to assume that spread_rofi_nh and spread_rofi_sh are true in these subroutines, and just throw an error if there's an inconsistency in the weights.

Associated access3-share PR

@kieranricardo kieranricardo force-pushed the generalise-rofi-spreading branch from 409852a to 51a7084 Compare June 15, 2026 04:34
@kieranricardo kieranricardo marked this pull request as ready for review June 15, 2026 05:01
Comment thread mediator/med_phases_post_rof_mod.F90 Outdated
Comment thread mediator/med_phases_post_rof_mod.F90
Comment thread mediator/med_phases_post_rof_mod.F90 Outdated
Comment thread mediator/med_phases_post_rof_mod.F90 Outdated
Comment on lines 205 to 211

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@anton-seaice anton-seaice Jun 18, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, I thought CDEPS mapped the runoff (conservatively) to the ocean grid, before passing it to the mediator. And then the mediator just does a redistribution/mapfcopy?

Remappings by default ignore masks unless specified with srcMaskValues and dstMaskValues. These aren't set for mapfcopy. See bilinear for contrast.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like your suggestion though! Seems much safer. I'll go ahead and implement.

Comment thread mediator/med_phases_post_atm_mod.F90 Outdated
Comment thread mediator/med_phases_post_atm_mod.F90 Outdated
Comment thread mediator/med_phases_post_atm_mod.F90
character(*), parameter :: u_FILE_u = &
__FILE__
character(len=9), parameter :: fields_to_spread_runoff(1) = &
['Faoa_rofi']

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did rofi and rofl get seperated elsewhere ?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately this will be tricky! The coupled model needs to have energy balance, and ignoring the basal melt latent heat will give us a persistent +0.05 W/m^2 (averaged over the entire earth) bias.

The latent heat at the coastal point doesn't seem to cause issues, the maximum sea-ice thickness matches OM3. If it does cause issues in the future we can add this splitting in and put the latent heat somewhere else.

But either way I don't think this will change the spreading routine itself, just how and where we apply it in post_atm. Shall we leave this as is, and change how we apply the spreading routine to CM3 if needed in a future PR?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dougiesquire - do you have a view on this? The question is whether the put all the atmosphere runoff from icesheets into the Foxx_rofi/ficeberg field, or split into seperate fields for icebergs and basal melt. The second option probably needs some code changes in MOM6 to account for latent heat of the basal melt fraction, (and probably add a Faoa_rofl_glc or similar)

@dougiesquire dougiesquire Jun 24, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neither option seems amazing. I think the _glc fields are for when there is a coupled glacier model. Could we add a new field for the basal melt?

@dougiesquire dougiesquire Jun 24, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, I think I agree with splitting the basal and iceberg contributions for consistency with OM3, but I'm not sure I like the idea of using rofl_glc for basal

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the atmosphere just a really basic glacier model ? 😅

Well probably need to split the rofl field from datm into rivers / basal at some point, so would be good if the same name could be used for both cases .

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well probably need to split the rofl field from datm into rivers / basal at some point, so would be good if the same name could be used for both cases .

Yeah. My thinking is that we want specific logic in MOM for the basal flux (latent heat and potentially other things, e.g. insertion at depth). I feels like the implementation will be cleaner with a new field.

Comment thread mediator/med_phases_post_rof_mod.F90 Outdated
Comment thread mediator/med_phases_post_rof_mod.F90
Comment thread mediator/med_phases_post_rof_mod.F90 Outdated
kieranricardo and others added 6 commits June 17, 2026 10:52
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants