Skip to content

Ice shelf-specific forcing depths - #78

Closed
angus-g wants to merge 5 commits into
ACCESS-NRI:2026.05from
angus-g:angus-g/shelf-forcing
Closed

angus-g wants to merge 5 commits into
ACCESS-NRI:2026.05from
angus-g:angus-g/shelf-forcing

Conversation

@angus-g

@angus-g angus-g commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

This is a draft for @claireyung to test whether we can specify different depths for a) the calculation of the surface boundary layer that feeds into the melt parameterisation; b) the application of the melt fluxes. There are three new parameters:

  1. SHELF_FORCING_DEPTH: the equivalent to MINIMUM_FORCING_DEPTH applied in shelf regions;
  2. HMIX_SHELF_PROP; the equivalent to HMIX_SFC_PROP (for T/S) applied in shelf regions;
  3. HMIX_UV_SHELF_PROP; the equivalent to HMIX_UV_SFC_PROP (for velocity) applied in shelf regions.

@dougiesquire

Copy link
Copy Markdown
Collaborator

Hi @angus-g. I'm curious whether there's any overlap here with what I'm mucking around with in #72.

That PR is specifically for when there is no active ice-shelf, to allow distributing basal/submarine melt over a depth range. But I wonder if we could be sharing some of the same machinery?

@angus-g

angus-g commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator Author

Thanks @dougiesquire, this looks cool too. Maybe there could be something shared with distribute_brunoff, although I'm not sure there's a mass flux coming out of the melt parametrisation so it is a bit of a different field. I agree that it would probably make sense to consolidate: maybe unified parameters? Is it the case that you'd have a coupler-provided basal runoff and the ice shelf model simultaneously?

@dougiesquire

Copy link
Copy Markdown
Collaborator

Is it the case that you'd have a coupler-provided basal runoff and the ice shelf model simultaneously?

Possibly?... I'm actually thinking I'll generalize the brunoff field to something like srunoff (for "submarine" runoff) and then also route ice sheet frontal melt around Greenland to that field (see my latest thinking for the OM3 forcing here). So I guess there could be a case in the future where we have both. Iceberg melt could also be added to srunoff - there are a few papers that suggest this should also be distributed over depth in the ocean.

The boundary layer used for the melt parameterisation must match the
depth over which the forcing is applied. The only controls for these
are global: HMIX_SFC_PROP/HMIX_UV_SFC_PROP control the boundary layer
for computing the parameterisation, and MINIMUM_FORCING_DEPTH controls
the depth over which the melt is applied.

We introduce new optional parameters to applyBoundaryFluxesInOut() to
modify IforcingDepthScale to use a different `shelf_forcing_depth`
according to the fraction of the cell covered by ice shelf.
This is the analogue to MINIMUM_FORCING_DEPTH, applied under ice
shelves. It is only read when an ice shelf coverage field is provided
to the diabatic driver initialisation routine.
@angus-g
angus-g force-pushed the angus-g/shelf-forcing branch from 29c655c to a36db5d Compare October 14, 2026 04:47
This only affects the path when using the non-legacy ALE diabatic
driver. In this case, the frac_shelf_h array is passed through, and
used to apply a different forcing depth as required.
This adds HMIX_SHELF_PROP and HMIX_UV_SHELF_PROP, which are analogues
to the `SFC` parameters. These determine the boundary layer depth for
near-shelf temperature, salinity and velocities, which are used for
calculation of melt parameterisation.
This now takes frac_shelf_h into account when computing depth_ml
used for calculating the surface state.
@dougiesquire

dougiesquire commented Oct 23, 2026 •

Copy link
Copy Markdown
Collaborator

Hi @angus-g and @claireyung, I've had a think about whether/how this relates to #72. My thinking now is that they're just serving different purposes and we should keep them separate (at least for now).

My understanding is that this PR is about controlling the region over which the 3-equation stuff is handled with an active ice shelf. The melt occurs at depth over some small configurable region at the shelf/ocean interface.

#72 is about better handling of coupled ice melt fluxes that are provided as 2D fields despite actually having a depth dependence in the real world (e.g Antarctic basal melt or iceberg calving fields from JRA55-do). It provides the ability to distribute the mass/heat over a depth range.

I'm not sure there's much parameter unification to be had between the two PRs since the parameters represent quite different things. SHELF_FORCING_DEPTH provides a small amount of spreading at the local ice/ocean interface depth, whereas SRUNOFF_MAX_DEPTH is a crude estimate of the depth range of the whole (melting) submerged ice-ocean interface (in the future we may specify spatially-variable depth bounds).

I could well be missing something here so keen to hear your thoughts.

Also, out of curiosity, was this change motivated by physical or numerical reasons?

@claireyung

Copy link
Copy Markdown
Collaborator

Hi @dougiesquire
That makes sense, I agree the purpose of the PRs is quite different but @angus-g can maybe comment more

As for the motivation, it is kind of a numerical trick but related to a physical process - sampling the meltwater from a bigger depth range means the effect of cold meltwater stratifying the upper ocean is reduced, so your thermal driving is bigger. Distributing it over a bigger range is needed for consistency with the sampling depth, but also implicitly increases mixing and reduces stratification. Gwyther 2020 has more details. In reality, we expect strong stratification in some places, but in the model we have a very high resolution compared to most models and maybe we don't have enough mixing to compensate (tides or related to sub-grid stuff or otherwise). We were trying this in the pan-Antarctic in the hope it would increase melting and fix our bias claireyung/mom6-panAn-iceshelf-tools#82

To demonstrate it works, this is a zoom in of a temperature profile under Thwaites ice shelf; left is 1.08m sampling/distribution distance, right is 3m distance; and stratification seems to follow those distances :)
Screenshot 2026-10-26 at 3 28 00 pm

@dougiesquire

Copy link
Copy Markdown
Collaborator

Sorry @angus-g, I've just noticed this is coming from your fork. Could you please redo from a branch on this repo?

@angus-g

angus-g commented Oct 26, 2026

Copy link
Copy Markdown
Collaborator Author

Oops, one day I'll remember to open it from the right place 😁

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