Fixed error in ice thermodynamic conservation

[akturner]

Non-accounting of enthalpy removal for thin snow/ice in enthalpy adjustment can result in a non-conservation error in prescribed ice mode with short time steps. This appears to occur when small amounts of snow accumulate after removal of snow layer.

Fixes #5124

[Non-BFB]

[akturner]

@mkstratos : Could you check this fixes the issues you've had recently with the prescribed ice mode in MPAS-Seaice?

[mkstratos]

Fantastic! This has solved the issue we'd been experiencing with the F2010 compset run at dtime=1.

[rljacob]

@jonbob is this non-BFB for the v2 low res config?

[jonbob]

@rljacob - I think it may be, since it changes convergence criteria in specific situations. I was going to touch base with you about it, once I ran some of the nightly tests for comparison. How would you prefer to handle this?

[rljacob]

Just would like a note on the merge commit message about when its non-BFB.

[jonbob]

OK, I'll make sure

[jonbob]

I ran e3sm_developer on a test merge and everything passed except:

• ERS.ne30pg2_r05_EC30to60E2r2.GPMPAS-JRA.chrysalis_intel.mosart-rof_ocn_2way
• SMS_P12x2.ne4_oQU240.WCYCL1850NS.chrysalis_intel.allactive-mach_mods
• SMS.T62_oQU120_ais20.MPAS_LISIO_TEST.chrysalis_intel

so pretty much every test with mpas-seaice in its non-prescribed ice mode. @akturner, does this match your expectations?

[akturner]

@jonbob: The change is non-BFB and it would only take the particular condition to be called once for the run to be non-BFB, so I'm not surprised the BFB tests dont pass. Is there a tool to compare climatologies available?

[jonbob]

@akturner -- there is no such tool right now, other than comparing longer runs by hand. The deep dive Mark Taylor led came up with some requirements for the next phase but they are not yet supported, so it may mean we should do at least some 10-year comparison runs just to make sure this all looks like round-off level changes.

[jonbob]

Started two 10-year LR tests on anvil to check the impact of this non-BFB PR

[eclare108213]

@jonbob would it be possible to output ice volume (or thickness) daily for 5 years? Then @darincomeau might be able to run a QC test on the output (maybe after this PR is merged) as part of the QC development effort?

[jonbob]

@eclare108213 -- hmmm, these runs are already started. I am happy to make a five-year test with daily seaice output whenever you think the codebase in the repo is ready. It might make more sense to do that separately instead of leveraging these tests, so please just let me know

[jonbob]

@akturner - the test run with this PR failed after 17 days with seaice errors. If you want to look at the output, it's on lcrc at:

/lcrc/group/acme/ac.jwolfe/scratch/anvil/20220908.PR5146.anvil/run

[darincomeau]

@eclare108213 @jonbob I'm happy to run my own tests off this branch (or once its merged) for QC purposes. I'd stick with D-cases for QC purposes, and I don't imagine those would be run as part of testing here. (BTW I just make changes to the output stream to turn it on, and add iceVolumeCell as daily output for QC testing).

[rljacob]

telecon notes: need to look at fail.

[akturner]

@eclare108213, @njeffery : So this change should not be applied as is to adjust_enthalpy where the tracer isn't enthalpy. smliq and smice have units of freshn - should freshn be applied here instead of fhocn? Should fhocn, fsaltn, or freshn be applied to rsnw?

[njeffery]

@akturner : smice, smliq and rsnw are not involved in ocean fluxes or conservation of fresh water, salt or heat. You could make fhocn optional, but it might be simpler to correct ocean fluxes for small snow thicknesses before the adjust_enthalpy subroutine and keep that routine for just redistributing tracers.

[eclare108213]

The correction to fhocn does not belong in subroutine adjust_enthalpy. That routine just remaps quantities vertically (and ought to be renamed -- it used to be only used for enthalpy, now more generally). I recommend doing the correction just before the call to adjust_enthalpy in ice_snow.F90. Then most (maybe all) of your other changes to the code are unnecessary.

[jonbob]

I ran a ten-year test after commit 0559859 - the maps-analysis comparison with a baseline can be seen at 20220921.PR5146.anvil. I didn't see anything that makes me think this PR changes anything beyond roundoff, but @akturner please take a look. For what it's worth, I think the commit 6c95bcd has a problem, but I did not include it in my test