### Author:  [@Flick.Chun](https://forum.access-hive.org.au/u/Flick.Chun)
#### Post date: [30 September 2024 07:16 UTC](https://forum.access-hive.org.au/t/inconsistent-latitude-dimensions-in-published-access-esm1-5/3744/1 "2024-09-30T07:16:09Z")
Found from an error running an ESMValTool recipe in this [question](https://github.com/ESMValGroup/ESMValTool/discussions/3733#discussioncomment-10750788). 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 > 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?
---
### Author:  [@Scott](https://forum.access-hive.org.au/u/Scott)
#### Post date: [30 September 2024 23:41 UTC](https://forum.access-hive.org.au/t/inconsistent-latitude-dimensions-in-published-access-esm1-5/3744/2 "2024-09-30T23:41:57Z")
The atmosphere model uses an [Arakawa C Grid](https://en.wikipedia.org/wiki/Arakawa_grids#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.
---
### Author:  [@Aidan](https://forum.access-hive.org.au/u/Aidan)
#### Post date: [30 September 2024 23:50 UTC](https://forum.access-hive.org.au/t/inconsistent-latitude-dimensions-in-published-access-esm1-5/3744/3 "2024-09-30T23:50:52Z")
> [@Flick.Chun](#):
>
> 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.
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).
---
### Author:  [@Flick.Chun](https://forum.access-hive.org.au/u/Flick.Chun)
#### Post date: [1 October 2024 00:53 UTC](https://forum.access-hive.org.au/t/inconsistent-latitude-dimensions-in-published-access-esm1-5/3744/4 "2024-10-01T00:53:31Z")
Thanks for enlightening me!
Is there a rule or indication on how to apply the area file?
---
### Author:  [@Aidan](https://forum.access-hive.org.au/u/Aidan)
#### Post date: [1 October 2024 04:51 UTC](https://forum.access-hive.org.au/t/inconsistent-latitude-dimensions-in-published-access-esm1-5/3744/5 "2024-10-01T04:51:38Z")
> [@Flick.Chun](#):
>
> Is there a rule or indication on how to apply the area file?
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.
---
### Author:  [@anton](https://forum.access-hive.org.au/u/anton)
#### Post date: [1 October 2024 05:22 UTC](https://forum.access-hive.org.au/t/inconsistent-latitude-dimensions-in-published-access-esm1-5/3744/6 "2024-10-01T05:22:33Z")
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:
```auto
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.
---
### Author:  [@anton](https://forum.access-hive.org.au/u/anton)
#### Post date: [1 October 2024 06:27 UTC](https://forum.access-hive.org.au/t/inconsistent-latitude-dimensions-in-published-access-esm1-5/3744/7 "2024-10-01T06:27:11Z")
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](https://scitools-iris.readthedocs.io/en/v3.0.1/generated/api/iris/analysis/cartography.html#iris.analysis.cartography.area_weights))
---
### Author:  [@Flick.Chun](https://forum.access-hive.org.au/u/Flick.Chun)
#### Post date: [2 October 2024 05:34 UTC](https://forum.access-hive.org.au/t/inconsistent-latitude-dimensions-in-published-access-esm1-5/3744/8 "2024-10-02T05:34:27Z")
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