Required changes to CABLE model output

[SeanBryan51]

This issue thread documents the changes needed for CABLE model output to be used directly with ILAMB.

• Albedo units are not CF compliant: change from - to 1 or remove units attribute.
• Rename netCDF dimensions and coordinate variables: x -> lon, y -> lat. Note: this is not required by CF conventions.
  • It looks like ILAMB is not fully model agnostic and makes assumptions in model output data. For example, in ilamblib.py:L754, ILAMB assumes dimensions for latitude, longitude and time are called lat, lon and time respectively.
  • A patch has been added to ILAMB to address this (see Use cf-conventions to infer dimension names rubisco-sfa/ILAMB#106)
• Add time bounds variable. Note: this is not required by CF conventions.
  • Explicit time bounds will be required if we want to run ILAMB on model outputs that are split across multiple years (see #81 in the ILAMB repository).

Note: ILAMB is tested with CABLE model output from the latest trunk (CABLE3).

[aidanheerdegen]

• It looks like ILAMB is not fully model agnostic and makes assumptions in model output data. For example, in ilamblib.py:L754, ILAMB assumes dimensions for latitude, longitude and time are called lat, lon and time respectively.

Shouldn't iLAMB be fixed to properly support CF conventions? That could be a lot easier than forcing all data to comply with an arbitrary "standard".

[SeanBryan51]

@aidanheerdegen I agree. There is currently ongoing development of a new version of ILAMB which uses xarray as its backend but it is yet to be released. It looks like they are taking a CF compliant approach in the new version (e.g. see here).

It might be worth submitting a patch to (current) ILAMB to support x and y as the dimension / coordinate variable names when reading NetCDF datasets.

[aidanheerdegen]

There is currently ongoing development of a new version of ILAMB which uses xarray as its backend but it is yet to be released. It looks like they are taking a CF compliant approach in the new version (e.g. see here).

Seems promising, but have they heard of https://github.com/xarray-contrib/cf-xarray?

I'd be using that in a heartbeat for CF compliance and making data access as agnostic as possible.

It might be worth submitting a patch to (current) ILAMB to support x and y as the dimension / coordinate variable names when reading NetCDF datasets.

Agreed. From a cursory appraisal it looks like the code would be relatively easy to change to support this.

[SeanBryan51]

Judging from this comment, I think the developer is aware of cf-xarray

[aidanheerdegen]

Judging from this comment, I think the developer is aware of cf-xarray

Hah hah! Good catch, actually reading the code.

Well they have their reasons, but I'd standardise on the good thing and treat the outlier as the exception.

[SeanBryan51]

Here is the patch to allow for flexible NetCDF dimension names: rubisco-sfa/ILAMB#105

[aidanheerdegen]

Here is the patch to allow for flexible NetCDF dimension names: rubisco-sfa/ILAMB#105

This doesn't implement CF conventions (examining units, standard_name or axis attribute). I thought the CABLE data had some of the correct attributions, but perhaps I got confused?

[SeanBryan51]

@aidanheerdegen I see. I agree that examining the attributes on the coordinate variables for either units, standard_name or axis attributes would be a more future proof solution.

Here are the NetCDF coordinate variables currently in the CABLE model output along with their attributes:

double time(time) ;
        time:units = "seconds since 1901-01-01 00:00:00" ;
        time:coordinate = "GMT" ;
        time:calendar = "standard" ;
float x(x) ;
        x:units = "degrees_east" ;
        x:comment = "x coordinate variable for GrADS compatibility" ;
float y(y) ;
        y:units = "degrees_north" ;
        y:comment = "y coordinate variable for GrADS compatibility" ;

They all have a units attribute so it should be enough to identify the spatiotemporal axis (T, Z, Y, X) of a given coordinate variable.

[aidanheerdegen]

They all have a units attribute so it should be enough to identify the spatiotemporal axis (T, Z, Y, X) of a given coordinate variable.

Agreed.

I don't think you should do this, but note for completeness you also have the option to add an axis attribute without breaking backwards compatibility with tools that have x, y hard-coded for the lon/lat.

[SeanBryan51]

Here is the revised patch: rubisco-sfa/ILAMB#106