search

CABLE-LSM / CABLE

Home to the CABLE land surface model and its documentation
https://cable.readthedocs.io/en/latest/
Other
8 stars 4 forks source link

Support for `lat-lon` dimensions and coordinate variables in CABLE model output #401

Closed SeanBryan51 closed 1 week ago

SeanBryan51 commented 2 weeks ago

As part of https://github.com/CABLE-LSM/CABLE/issues/210, ILAMB requires the spatial NetCDF dimensions and coordinate variables in the CABLE model output to be named lat and lon (or similar[^1]).

It looks like CABLE output files have been hard coded to be compatible with GrADS tool (uses x and y convention):

https://github.com/CABLE-LSM/CABLE/blob/0448257503a7a424807a6ee8daf3f1960faaf603/src/offline/cable_output.F90#L294-L302

https://github.com/CABLE-LSM/CABLE/blob/0448257503a7a424807a6ee8daf3f1960faaf603/src/offline/cable_output.F90#L402-L428

[^1]: the latitude/longitude dimension and coordinate variable must contain lat/lon as a substring in the dimension and coordinate variable name (see here).

SeanBryan51 commented 2 weeks ago

I'm thinking we add a new optional field to the output namelist entry which allows the dimension and coordinate variable names to be configurable (with the default being the current GrADS names).

aidanheerdegen commented 2 weeks ago

See https://github.com/CABLE-LSM/benchcab-ilamb-config/issues/1#issuecomment-2354448846

ccarouge commented 2 weeks ago

GrADS is using the COARDS convention. In this convention, the name of the coordinate variables is not standardized and normally a latitude or longitude coordinate is identifiable only by its unit.

In other words, are we sure we have to keep the "x" and "y" options for compatibility?

aidanheerdegen commented 1 week ago

GrADS is using the COARDS convention. In this convention, the name of the coordinate variables is not standardized and normally a latitude or longitude coordinate is identifiable only by its unit.

In other words, are we sure we have to keep the "x" and "y" options for compatibility?

Longitude and latitude variable names are not standardised in the CF convention either. CF uses units, standard_name and axis attributes to identify lat/lon.

It seems CABLE has sufficient metadata to be CF compliant in this respect, it's just that Benchcab isn't implementing CF compliance currently.

ccarouge commented 1 week ago

@aidanheerdegen

Benchcab isn't implementing CF compliance currently

benchcab doesn't touch the output format, it only deals with the filenames. So if there is a problem, it's in the CABLE output format :)

aidanheerdegen commented 1 week ago

Sorry. When I said Benchab I meant iLAMB. Sorry.

SeanBryan51 commented 1 week ago

Closing this issue for now - CABLE output currently has enough CF metadata to identify the spatiotemporal axis (T, Z, Y, X) of a given coordinate variable, so I agree with Aidan in that we should try and push ILAMB to accept CF compliant NetCDF data. If that falls over then we can consider changing the dimension names in the CABLE output.