ESCOMP / ESCOMP/CTSM

Consider requiring user to explicitly set reset_dynbal_baselines in certain scenarios

Open
#4,186 4 comments 0 reactions 2 assignees Claimed by @Katetc View on GitHub
usability
Dominant language
Fortran
Stars
352
Forks
361
Avg merge
2d 21h
Merged PRs (30d)
7

Description

The `reset_dynbal_baselines` flag is subtle but can be important to reduce the conservation adjustment fluxes that arise from dynamic landunits when running with an evolving ice sheet model (as described [here](https://escomp.github.io/cism-docs/cism-in-cesm/versions/master/html/clm-cism-coupling.html#resetting-clm-s-baseline-states-for-dynamic-landunits)).

We recently discovered that this flag wasn't set when it probably should have been, when introducing a dynamic ice sheet into the CESM3 simulations. Now that it's getting more common to include CISM in standard CESM3 configurations, relying on users to know that they need to set this flag seems more problematic.

Therefore, I've been thinking about how we could catch at least some common scenarios where a user should probably be setting reset_dynbal_baselines to true. The default is false, and it feels risky to automatically set it to true in certain scenarios, because doing so at the wrong time could break conservation (though it may be that that's acceptable).

Instead of having reset_dynbal_baselines be a logical, we could change it to a string with three values: on, off, or unset. In the Fortran, unset would be interpreted the same as off. However, there would be some scenarios (ideally caught at build-namelist time, but if that's not possible, at least caught at runtime) where an unset value would trigger an error saying that the user needs to explicitly set it to on / off.

Then this creates the question of when to force the user to set this. This would be some combination of there being an evolving ice sheet along with some other condition(s). We would probably need to add some metadata to the CTSM restart file that specifies more things about the run that generated that restart file. Then we could say, "when the current run is set up like X and it's using an initial conditions file that was set up like Y, together with having an evolving ice sheet, that's a condition where the user should at least actively consider whether they need to set this flag".

More work is needed to come up with the exact conditions where this should trigger.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.