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?
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.
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?
Aidan
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
5
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
@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.
Aidan
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
9
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
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)
