Issue with CICE diagnostic `dvidtt` in ACCESS-ESM / the CMIP6 pre-industrial archive

I’ve been running some test simulations with ACCESS-ESM branching from the pre-industrial control. I’m interested in looking at the sea ice response, and in doing so, I’ve noticed a problem with the dvidtt (thermodynamic volume tendency) diagnostic every January.

I’ve gone back into the CMIP6 archive (/g/data/p73/archive/CMIP6/ACCESS-ESM1-5/PI-02/history/ice/) and I think the same problem persists there. Basically, every January, the values of dvidtt are unrealistic/much too high. See this gist example. The values for every other month seem fine.

I think it’s a problem with the output, rather than with how xarray handles reading in the data.

Has anyone noticed this before (with this or other diagnostics), and does anyone know how I might go about fixing this for new experiments? It doesn’t seem to be a problem in the ocean-sea ice ACCESS-OM2 models - see example gist linked above.

Given that it’s every January (when the model restarts), could it be something to do with how the model is initiating this diagnostic?

Thanks for posting @hrsdawson! We’re finding someone to help with this. @sofarrell have you come across this before or do you have any thoughts?

Hi @hrsdawson and @dougiesquire, yes this is a known issue and on the list to be fixed for ACCESS ESM1.6, this data field and a number of other similar effected ones were not published for ACCESS ESM1.5 data in CMIP6. As you are picking up raw model data from the p73 archive then the data will still be there and also any runs you do yourself with ACCESS ESM1.5 you need to be wary of fields that weren’t published in ACCESS ESM1.5 we filtered out fields that we had issues with during the post processing.
Happy to chat more in email.

2 Likes

Great, thanks for clarifying @sofarrell, that’s good to know! So for my own understanding, will this still be a problem in the ACCESS-NRI supported version of ACCESS-ESM, when that’s released?

ACCESS-ESM1.5 I assume? Unless we fix it, then yes. Is this essential for your work? It sounds kinda terrible, but we can’t fix every known problem, and certainly not immediately, so we would need to know how this affects your work in order to understand how to prioritise it.

Thanks @Aidan. No, at this stage it’s not essential for my work, but I guess it is essential for me to know which diagnostics I should/shouldn’t trust :slight_smile:

@dougiesquire thanks for the example gist showing which sea-ice variables/diagnostics are available in the ACCESS-ESM1.5 CMIP6 holdings. Why do the variable names differ from those in the raw data? Is that a CMIP6 naming protocol thing?

Yup, all data published for CMIP must be “standardised”. Among many other things, this includes using a common set of variable names. You can find definitions of each of the monthly sea-ice variables in this table, for example.

Note, you can also load the data through the catalog if that’s useful. See the last part of the example here.

1 Like

great, thank you @dougiesquire!

If (and it’s a big IF) the CICE diagnostics defined standard_names in their netcdf metadata then you could use cf_xarray to write your notebooks and access the data through the standard_name it would work with raw and CMORised data

https://cf-xarray.readthedocs.io/en/latest/selecting.html#by-standard-name

Which is kinda cool. I highly recommend cf_xarray.

1 Like

@Aidan I might need to revise this answer. Could turn out to be quite essential for what we want to do. I’ll get back to you next week about this.

1 Like

This is a limitation in the ESM1.5 coupling which means all the variables measuring a rate are incorrect in the first output after a restart.

These variables which are configured to output from CICE have this issue in ESM1.5:

#cmip_variable definable_in_access access_variable(s)
#sfdsi no fsalt_ai aice
#sidconcdyn no daidtd
#sidconcth no daidtt
#sidmassdyn no dvidtd
#sidmassgrowthbot no congel
#sidmassgrowthwat no frazil
#sidmasslat no meltl
#sidmassmeltbot no meltb
#sidmassmelttop no meltt
#sidmasssi no snoice
#sidmassth no dvidtt
#siflswdbot no fswthru_ai aice
#sitemptop no Tsfc aice
#sndmasssi no snoice aice

This issue doesn’t occur in ACCESS-CM2, so that might be an alternative. Note CM2 uses the cmorized / CMIP6 standard variable names, rather than the CICE variable names. There are some corrections applied to this output by the APP4 post-processing tool, so its best to use this when using CM2. (Although no changes are made to sidmassth)

3 Likes

This will be address for ESM1.6 by either making a fix to the CICE4 setup or moving to CICE5.

Its captured in Erroneous diagnostics in ESM1.5 output · Issue #7 · ACCESS-NRI/cice4 · GitHub

2 Likes