Generation of non CF-compliant files (invalid formula_terms attribute on bounds variable) about cmor

[doutriaux1]

@durack1 yes I far as I rememember it is builtin CMOR, but maybe via the tables, I need to double check

[doutriaux1]

yes see: https://github.com/PCMDI/cmip5-cmor-tables/blob/master/Tables/CMIP5_Amon#L503-L520

[durack1]

As below:

From: Karl Taylor
Date: Wednesday, December 9, 2015 at 11:47 AM
To: "martin**@stfc.ac.uk"
Cc: "Durack , Paul J.", "Doutriaux, Charles", "Nadeau, Denis"
Subject: Re: CF errors in CMIP5

Dear Martin and all,

Regarding:
I've just scanned a sample of CMIP5 files, 5 random files from every CMOR variable,
with the CF Checker. This turns up a few errors from the data providers, but many
which appear to come from CMOR. Out of 4435 files checked, 1327 are non-compliant.
The commonest error, in 936 files, is "ERROR (4.3.2): formula_terms attribute only
allowed on coordinate variables" which is triggered by having a formula_terms
attribute on a bounds variable -- which the checker does not accept.


Is the use of formula_terms on bounds variables something which is built into CMOR?
Could it be switched off or blocked, or is there some justification for keeping it and
proposing an amendment to the convention?

I think this is indeed an error in the CF checker, *not* CMOR.  I reviewed the CF
standards document, and this is the only explicit statement about what formula_terms
is associated with:

"A new attribute, formula_terms , is used to associate terms in the definitions with
variables in a netCDF file."  

Note that it doesn't say that formula_terms can *only* be attached to variables that
are "coordinates variables".  Certainly formula_terms attached to the vertical
coordinate bounds are just as essential as having them available for the coordinates
themselves because without those terms we can't convert the bounds to something
physical (e.g., pressure or height).  If we accept that the terms are essential, then
they need to appear in CMIP files.  If we agree that CF doesn't forbid this
(and I don't think it does), then we need to modify the CF checker so that it won't
raise an error.  If we think CF does forbid it (or might be interpreted that way), then
we need to file a ticket to the convention site with clarifying wording (which I would
consider to be a "defect", not a modification of the standard, so would expect no
objections to be raised). 

In any case I don't think we should change the way the formula_terms appear in
CMIP files.

Best regards,
Karl

[martinjuckes]

I think the CF checker is following the conformance document statement that:
"The formula_terms attribute is only allowed on a coordinate variable which has a standard_name listed in Appendix C".

Given the consistency between the conformance document and the checker, I hadn't looked at the standards document. But the above statement is slightly ambiguous -- your analysis of the standards document suggests it should be something like "Coordinate variables can only carry a formula_terms attributes if they also have a standard_name which is listed in Appendix C", rather than the alternative interpretation which the CF Checker is enforcing: "The formula_terms attribute is only allowed on variables which are coordinate variables having a standard_name which is listed in Appendix C".

The convention states that the bounds variables is considered as part of the variable meta data and it is not necessary to provide it with "attributes such as long_name and units". Are you suggesting that there is a need for a separate statement of the formula_terms? Are there cases when the formula_terms of the bounds are different from those of the coordinate variable it is associated with?

[taylor13]

Hi Martin,
I hadn't read the conformance document, but I trust your analysis and think we will need to make some change(s) (in the conformance document at least and maybe a clarification also in the conventions document).
For dimensionless coordinates where formula_terms are needed, the formula will be the same for both the coordinates and their bounds, but because the bounds don't coincide (in the vertical dimension) with the coordinates themselves, different values must be assigned to the terms. This means that the formula_terms attached to the bounds will point to different variables (e.g., defined on half-levels) compared with the variables associated with the coordinates themselves (e.g., defined on full levels). So the formula will be the same, but the term variables (coefficient values) will invariably be different.
Does this make sense?
I think use of formula_terms should be allowed (and only allowed) when a variable is stored with a standard_name listed in Appendix C. The variable could be a coordinates variable or bounds on a coordinates variable, or just a regular variable in the file (after all you might want to store coordinate information in a file even if no variable is a function of that coordinate). I think we need to modify the conformance document along the lines you suggest; here's an option: "The formula_terms attribute can only be attached to a variable that has a standard_name listed in Appendix C." In the CF conventions themselves, we could add a sentence to the discussion of formula_terms that makes it clear that they can be attached to any type of variable as long as it has a standard_name listed in Appendix C.
Unless there are objections, we should transfer some of this discussion now to a new CF conventions "ticket". What do you think?
cheers,
Karl

[martinjuckes]

Hi Karl,

Thanks .. I understand the requirement for formula_terms on the bounds now (and associated additional variables).

I agree that a transfer to a CF ticket would be good,

regards,
Martin

---

From: taylor13 [[email protected]]
Sent: 11 December 2015 17:05
To: PCMDI/cmor
Cc: Juckes, Martin (STFC,RAL,RALSP)
Subject: Re: [cmor] Generation of non CF-compliant files (invalid formula_terms attribute on bounds variable) (#47)

Hi Martin,
I hadn't read the conformance document, but I trust your analysis and think we will need to make some change(s) (in the conformance document at least and maybe a clarification also in the conventions document).

For dimensionless coordinates where formula_terms are needed, the formula will be the same for both the coordinates and their bounds, but because the bounds don't coincide (in the vertical dimension) with the coordinates themselves, different values must be assigned to the terms. This means that the formula_terms attached to the bounds will point to different variables (e.g., defined on half-levels) compared with the variables associated with the coordinates themselves (e.g., defined on full levels). So the formula will be the same, but the term variables (coefficient values) will invariably be different.
Does this make sense?
I think use of formula_terms should be allowed (and only allowed) when a variable is stored with a standard_name listed in Appendix C. The variable could be a coordinates variable or bounds on a coordinates variable, or just a regular variable in the file (after all you might want to store coordinate information in a file even if no variable is a function of that coordinate). I think we need to modify the conformance document along the lines you suggest; here's an option: "The formula_terms attribute can only be attached to a variable that has a standard_name listed in Appendix C." In the CF conventions themselves, we could add a sentence to the discussion of formula_terms that makes it clear that they can be attached to any type of variable as long as it has a standard_name listed in Appendix C.

Unless there are objections, we should transfer some of this discussion now to a new CF conventions "ticket". What do you think?
cheers,
Karl

�
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-163991759.

[dnadeau4]

I copied all the formula terms from the CMIP5 tables. I created axes from the CMIP5 tables and then create missing ones from dreq.xml.

[dnadeau4]

@martinjuckes @taylor13 @doutriaux1 @durack1 Do we have a CF ticket for this? Should we change the way we handle formula_terms in CMOR? Note that ESGF will use cfchecker and CMIP6_Validator before publishing, so I would like to make sure that we are following the CF-1 convention to avoid confusion.

[durack1]

@dnadeau4 just for reference the current version of CF is 1.6, however 1.7 is due for release fairly soon..

[taylor13]

This issue is being actively worked on the CF trac system. Expect we will be in compliance with version 1.7 of CF

[durack1]

@dnadeau4 should this be moved to the 3.2.4 milestone?

[dnadeau4]

@taylor13 Can you check on this with CF 1.7?

[taylor13]

Yes, version 1.7 is about to be released, and our files will be compliant with it. (It may be a few months at least before the CF checker is updated.)

[dnadeau4]

I will set the milestone to 3.2.6 and when CF 1.7 is out, we can close the issue.

[dnadeau4]

CF 1.7 convention is now out.