Open SeanBryan51 opened 11 months ago
- 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
andtime
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".
@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.
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
andy
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.
Judging from this comment, I think the developer is aware of cf-xarray
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.
Here is the patch to allow for flexible NetCDF dimension names: https://github.com/rubisco-sfa/ILAMB/pull/105
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?
@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.
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
.
Here is the revised patch: https://github.com/rubisco-sfa/ILAMB/pull/106
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-
to1
or removeunits
attribute.x -> lon
,y -> lat
. Note: this is not required by CF conventions.~lat
,lon
andtime
respectively.Note: ILAMB is tested with CABLE model output from the latest trunk (CABLE3).