Comments (5)
@larsbuntemeyer my reading of the CF conventions section 7.1 on cell boundaries includes
A boundary variable inherits the values of some attributes from its parent coordinate variable. If a coordinate variable has any of the attributes marked "BI" (for "inherit") in the "Use" column of Appendix A, Attributes, they are assumed to apply to its bounds variable as well. It is recommended that BI attributes not be included on a boundary variable. If a BI attribute is included, it must also be present in the parent variable, and it must exactly match the parent attribute’s data type and value. A bounds variable may have any of the attributes marked "BO" for ("own") in the "Use" column of Appendix A, Attributes. These attributes take precedence over any corresponding attributes of the parent variable. In these cases, the parent variable’s attribute does not apply to the bounds variable, regardless of whether the latter has its own attribute.
The _FillValue
and missing_value
attributes are marked BO
in the table linked in appendix A, so may be included. units
is marked BI
so provided this attribute is identical in the vertices_
variables and their "parent" coordinate then this is acceptable. As such I think that the CMOR output is compliant, but @taylor13 might be able to be more definitive.
I note that the examples in the CF conventions documentation are fairly minimal in the attributes included for the bounds variables. It might be useful if there were some more expansive examples, but I can see that it would also be valuable to keep that document concise.
from cmor.
Thanks @matthew-mizielinski for the link. I think you are right and the output should be fine and compliant. I was unsure, because cf-checker and also compliance-checker give me same warnings for my examples (and also the MPI file) about that those attributes should not be there. However, i guess that those details might not be implemented. I'll go and maybe search their issues...
from cmor.
Ok, it seems to have been a recommendation before CF-1.11 that
Boundary variables should not have the _FillValue, missing_value, units, standard_name, axis, positive, calendar, leap_month, leap_year or month_lengths attributes.
which has change in latest recommendation of CF-1.11 (December 2023) to
Boundary variables should not include inheritable attributes, i.e. any of those marked "BI" in the "Use" column of Appendix A.
That just simply doesn't seem to be implemented in the compliance-checker yet...
from cmor.
@larsbuntemeyer @matthew-mizielinski
I agree the above file is CF-compliant. What do the "checker" warnings say? Are they misleading?
You said "Even if i remove the units attribute, it will write some original_units attribute." How did you remove the units attribute? Did you edit the cmip6_grids.json file? I would have thought we could easily remove the "units" attribute for vertices by simply setting "units": ""
for both vertices_longitude
and vertices_latitude
. Should I suggest that to Chris who is updating CMOR?
from cmor.
What do the "checker" warnings say? Are they misleading?
If i check for CF-1.7, it correctly warns:
compliance-checker -t cf:1.7 tos_Omon_MPI-ESM1-2-LR_historical_r1i1p1f1_gn_185001-186912.nc
gives
--------------------------------------------------------------------------------
IOOS Compliance Checker Report
Version 5.1.0
Report generated 2024-02-21T08:26:06Z
cf:1.7
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html
--------------------------------------------------------------------------------
Corrective Actions
tos_Omon_MPI-ESM1-2-LR_historical_r1i1p1f1_gn_185001-186912.nc has 4 potential issues
Warnings
--------------------------------------------------------------------------------
§2.5 Variables
§4.1 Latitude Coordinate
* latitude variable 'vertices_latitude' should define standard_name='latitude' or axis='Y'
§4.2 Longitude Coordinate
* longitude variable 'vertices_longitude' should define standard_name='longitude' or axis='X'
§7.1 Cell Boundaries
* The Boundary variables 'vertices_latitude' should not have the attributes: '['units', 'missing_value', '_FillValue']'
* The Boundary variables 'vertices_longitude' should not have the attributes: '['units', 'missing_value', '_FillValue']'
I think the warning about the cell boundaries here is correct for CF-1.7 but relaxed since CF-1.11. They are not misleading but i wouldn't know how to get rid of them if wanted to cmorize today for CF-1.7 conventions.
How did you remove the units attribute? Did you edit the cmip6_grids.json file? I would have thought we could easily remove the "units" attribute for vertices by simply setting
"units": ""
for bothvertices_longitude
andvertices_latitude
.
Yes, that's what i tried, i set "units": ""
for both vertices_longitude
and vertices_latitude
in the grids file which results in an attribute called original_units = "degrees_north"
obviously derived from the parent latitude
/ longitude
coordinate. Note that this all refers to 2D auxilliary coordinates (for 1D native coordinates and bounds there are no attributes in most CMIP6 files i look at)...
from cmor.
Related Issues (20)
- Exposing latest netcdf 4.9.x library functionality: quantize, zstandard HOT 13
- Remove unused attributes when processing CMIP6Plus datasets HOT 14
- Exposing latest netcdf 4.9.x library functionality: quantize, zstandard HOT 48
- unclear warning... HOT 5
- bounds required on singleton lon and lat? HOT 5
- Calibrating CMOR3 & 4 forward development plans HOT 7
- CMOR 3.8.0 Release HOT 4
- Update README.md to remove v3.7 reference
- default `realm = "REALM"` is always written although not required by CV HOT 2
- order in `required_global_attributes` matters HOT 1
- input time type as INT HOT 3
- CircleCI current image deprecated HOT 1
- Numpy 2.0 compatibility issue HOT 2
- File output size and chunking HOT 10
- Message Logging generates duplicated output lines
- DESTDIR support HOT 2
- Failure invoking set_deflate HOT 1
- user defined grid mapping
- Add CITATION.cff file HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cmor.