Post-processing of ACCESS-CM2 sea ice freeze and melt terms

I’ve got a question about the post-processing of the freeze , melt and thermodynamic/dynamic terms in ACCESS-CM2. I believe the net freeze - melt terms should match the thermodynamic term, but the latter is ~3 orders of magnitude smaller:

Net freeze - melt:

Thermodynamic term:

This post by Anton notes that corrections (dividing by 1800) have been made to the freeze and melt terms via the APP4 post-processing toolbox, but not to the thermodynamic and dynamic terms, which would explain the difference. My question is, does anyone know why these corrections were made and where the 1800 value comes from?

For reference, the freeze terms are: sidmassgrowthbot, sidmassgrowthwat, sidmasssi
Melt terms are: sidmassmelttop, sidmassmeltbot, sidmasslat
Thermodynamic and dynamic terms are: sidmassth, sidmassdyn

1 Like

It looks like, the thermodynamics and dynamics terms are quantities as a mass per area (although still a mass gain/loss) and the melt and freeze are rates over time if the post-processing is not applied. Which is not very intuitive.

1800 would be 1800s = 30 mins = the cice/coupling/mom thermo timestep

Okay, thanks. That was Wills hypothesis. But all diagnostics are listed as having units of kg / m2 / s. Is this incorrect for the thermodynamic and dynamic terms?

Possibly, I will look more carefully tomorrow :slight_smile:

1 Like

TLDR: If look at the CM2 output without applying post-processing, then the units will be inconsistent with the data and should be kg / m2 / timestep for freeze/melt terms. Dividing by 1800 as done in the post-processing would fix this in the published CMIP data (e.g. that available through ESGF) so that the units shown (kg / m2 / s) are correct.

Hi Hannah

poking through the CICE5 code used in CM2, shows that sidmassgrowthbot diagnostics is calculated as :

aice(i,j,iblk)*congel(i,j,iblk)*rhoi / aice_init(i,j,iblk)

where congel is in m/timestep, rho is in kg/m^3 and aice/aice_init is a fraction. Following through the units there, that gives kg/m^2/timestep. However as you note, cice diagnostics are labelled the units as kg/m^2/s . The post-processing corrects this by dividing by 1800 and keeping the units labelled as kg/m^2/s .

This has been fixed in CICE6, and I need to finalise a PR to fix this for cice5. And appears to be consistent across all the melt/freeze terms.

It’s probable that the aice/aice_init factor applied to the melt/freeze may mean that they don’t match exactly with the thermodynamic term (which doesn’t have this factor applied). Although at a large scale I guess that would average out to a small error.

1 Like

Thanks for looking into this @anton. I’m still running into the problem of big (orders of magnitude) differences between the freeze/melt terms and the thermodynamic/dynamic terms though.

I’ve looked at the CICE5 code you linked. It looks like the thermodynamic term (sidmassth) is calculated by dvidtt(i,j,iblk) * rhoi where dvidtt is in cm/day. So am I right in thinking the listed units for this term (kg / m^2 / s) are indeed wrong and I need to convert the diagnostic as follows in order to get to kg / m^2 / s?

  • Multiple by 100 (convert cm to m)
  • Divide by 86400 (seconds in day)?

From your earlier post though, it sounds like the thermodynamic and dynamic terms should not be a rate of change, but rather a net change for that month?

That’s stange. dvidtt is internally to cice in m/s, only the diagnostic is in cm/day (there is a correction here)

Apologies - I dug some more and think they “should” all be rates per second but the melt/freeze terms if not post-processed are reported as rates per timestep

Thanks for looking into this @anton. If the units are correct, then I’m still not sure why the thermodynamic term (the one that is not divided by 1800) is 3 orders of magnitude smaller than the sum of the freeze and melt terms (see below). My understanding is that these should match. The spatial pattern looks good, but the magnitude is off and not by a constant value:

Sum of freeze and melt terms:

Thermodynamic term (note the different color bar scale):

Difference between the two (sum of freeze and melt minus thermodynamic term):

Do you or @sofarrell know why this is?

Also, the basal melt terms in my output are all positive values, but the post-processing repository suggests they should be negative. Does this mean my output has been processed using a different version of the code?

Do you have a notebook you could share? Scrappy hacks are very welcome of course

Sure: example_sea_ice_terms.ipynb · GitHub

Sorry I wasn’t very clear! The post-processing is not automatically applied, only if intentionally run afterwards. So you’ll need to manually make the adjustment for 1800s.

I think the difference in basal melt being positive/negative is just different definitions between cice and CMIP6.

Does Sea-ice mass change through evaporation and sublimation sidmassevapsubl need to be included ?

1 Like

Ohhhhh, I thought it had been automatically applied because the naming matches the CMIP conventions but that explains everything. Edit: Sorry, nevermind my question about running it now. But for future reference, is this the code/instructions I should use if I were to apply it, or is there an updated xp65 version?

Yes, it should be included but it’s very small so I’ve neglected it for now.

1 Like

I believe GitHub - ACCESS-NRI/ACCESS-MOPPeR: ACCESS-MOPPeR is the tool to use now. It should give the same results as APP4.

There is a getting started notebook - ACCESS-MOPPeR/notebooks/Getting_started.ipynb at v2 · ACCESS-NRI/ACCESS-MOPPeR · GitHub but it does very much say its an alpha release :slight_smile:

Hi @hrsdawson, just picked up this thread, it looks like @anton has solved the issue you werent putting it through the post processor which corrected all the bugs that were in the original code which we copied from the original Met office verios, because we had runs at various stage of production we did all the fixes post processing and we assumed all the university groups would follow this same process, perhaps this should have been made in clear in the instructions.

For ESM1.6 CICE5 set up we have put the fixes into the code.