Closed bnlawrence closed 1 year ago
Using areacella requires making sure we have a file with the areas somewhere sensible in our directory tree:
"variable_entry": {
"areacella": {
"frequency": "fx",
"modeling_realm": "atmos land",
"standard_name": "cell_area",
"units": "m2",
"cell_methods": "area: sum",
"cell_measures": "",
"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.",
"dimensions": "longitude latitude",
"out_name": "areacella",
"type": "real",
"positive": "",
"valid_min": "",
"valid_max": "",
"ok_min_mean_abs": "",
"ok_max_mean_abs": ""
},
per David - these are not necessary for atmosphere files - cf python can figure it out (other tools? - don't know) added to the xml for ocean files cice files?
Indeed. cf-python can easily compute atmosphere cell measures on the fly from 1-d lats and lons, provided they have bounds (as can some other tools, I image). You could of course store it/them externally, though. When it needs weights, cf-python will use cell measures by preference, but if they are missing then it will just calculate them if it can, anyway. External external cell measures are easily provided via the external
keyword to cf.read
, but only if you remember to use it :)
We decided to add cell_measures areacella
and areacello
and external_variables
to handle this
What are we doing with cell measures, and what should we be doing?
(E.g. there is a lot of use of areacella(atmosphere) and areacello (ocean) in the CMIP6 files, a la
tas:cell_measures = "area: areacella"
)