Inconsistent latitude dimensions in published ACCESS-ESM1.5

Earth System Earth System Model
,
1

Found from an error running an ESMValTool recipe in this question. Which is using iris in python to load the files.
It looks like it cannot use the cell area file areacella as the dimensions are different from the variable ta for air temperature. The latitude length is 145 for area and 144 for ta.

I’ve looked into some other variables, mainly looking at the variables here: /g/data/fs38/publications/CMIP6/CMIP/CSIRO/ACCESS-ESM1-5/historical/r1i1p1f1/Amon (not sure if in other experiments or ensembles.)
and have found some have a latitude dimension length of 145, some 144.
eg.
Cube.summary of <iris 'Cube' of surface_upward_sensible_heat_flux / (W m-2) (time: 1980; latitude: 145; longitude: 192)>> hfss

These are latitude: 145:
['hfss', 'tas', 'hfls', 'rsuscs', 'uas', 'cl', 'phalf', 'clivi', 'prw', 'ps', 'prc', 'rtmt', 'evspsbl', 'sci', 'rlutcs', 'tasmin', 'rsdscs', 'rldscs', 'tasmax', 'tauu', 'ts', 'rlds', 'rsds', 'huss', 'cli', 'rsutcs', 'clw', 'rsdt', 'hurs', 'pfull', 'psl', 'prsn', 'rlut', 'clt', 'rsut', 'sfcWind', 'pr', 'rlus', 'rsus', 'sbl']
These are latitude: 144:
['wap', 'ta', 'hur', 'ua', 'vas', 'hus', 'va', 'tauv', 'zg']
Is there an explanation for this?

2

The atmosphere model uses an Arakawa C Grid - some fields are offset by half a grid spacing.

Some of the fields with 145 latitude cells will have an offset in longitude, e.g. tauu, since longitude wraps you still get 192 values along that access.

2 Likes
3

To follow up on @Scott’s reply: it is common to have staggered grids like this.

The ocean grid is also staggered, though it is a B-grid. Usually there are cell areas for the different grids, the ocean distinguishes them as t (tracer) and u (velocity).

1 Like
4

Thanks for enlightening me!
Is there a rule or indication on how to apply the area file?

5

If there isn’t an area variable with the correct coordinate dimension then you’re kinda stuffed.

You can can go back into the source data and try and find if such a beast is still available, otherwise you’d need to generate a new area variable from the one you have available and the coordinates of the two grids. It’s possible. @ezhilsabareesh8 and @anton have been doing a lot of grid reverse-engineering on some of the older grids and so may be able to assist.

6

In general, scalar quantities will be on the a-grid and averaged over the “normal” cell area.

I thought the ‘cell_measures’ attribute will tell you which area is relevant for the quantity.

e.g.
for /g/data/fs38/publications/CMIP6/CMIP/CSIRO/ACCESS-ESM1-5/historical/r1i1p1f1/Amon/psl/gn/latest/psl_Amon_ACCESS-ESM1-5_historical_r1i1p1f1_gn_185001-201412.nc

in the attributes for the psl variable, it states cell_measures : area: areacella - Which is surely incorrect, because areacella has 145 latitudes but psl has 144 latititudes ?

But then for uas, which has 145 latitude cells and therefore is a c-grid quantity, it still says cell_measures : area: areacella

It looks like cmip6 only requested one area for atmosphere (i.e. is only one area saved in /g/data/fs38/publications/CMIP6/CMIP/CSIRO/ACCESS-ESM1-5/historical/r1i1p1f1/fx/) with these attributes:

standard_name :
cell_area
long_name :
Grid-Cell Area for Atmospheric Grid Variables
comment :
For atmospheres with more than 1 mesh (e.g., staggered grids), report areas that apply to surface vertical fluxes of energy.

I would assume there are grid cell areas for the t-points in the original model output, maybe it doesn’t make it through to the post-processed output.

7

I had a quick look in the not post-processed output in p73 and couldn’t see anything obvious containing cell areas.

Sonya suggested Iris has built in calculation of areas (possibly iris.analysis.cartography — Iris 3.0.1 documentation)

1 Like
8

Thanks for the info! Yes, we can tell it to skip the area file and it would do its own calculation for area, just was unsure if ‘correct’, cheers

1 Like