#147: clarification of standard and correction of conformance doc: formula_terms
-----------------------------+------------------------------
Reporter: taylor13 | Owner: cf-conventions@…
Type: defect | Status: new
Priority: high | Milestone:
Component: cf-conventions | Version:
Resolution: | Keywords:
-----------------------------+------------------------------
Comment (by jonathan):
Dear Karl
At the start of this ticket, you said, "Based on a statement appearing in
the conformance document, the CF checker raises an error when the
formula_terms attribute is attached to a variable other than a coordinate
variable." Which statement is that? Is it this one?
The `formula_terms` attribute is only allowed on a coordinate variable
which has a `standard_name` listed in Appendix C.
If so, perhaps this is a misunderstanding. I think that point of that
statement is not that the variable is a coordinate variable, but that it
has a `standard_name` from App C, because without that you can't know what
formula applies. So I would suggest amending the statement to
The `formula_terms` attribute is only allowed on a variable which has a
`standard_name` listed in Appendix C.
To make CMIP6 data compliant, you'd have to add a `standard_name` to
bounds variables. That would be legal, but it would be unnecessary if
David's ticket 140 was accepted. Could you support ticket 140? If both
this ticket and ticket 140 were accepted now and put in CF 1.7 (which is
still under construction - we agreed a deadline of end of Jan for tickets,
but that was to meet the needs of CMIP6), I would suggest modifying the
conformance document to satisfy both this ticket and that ticket thus:
The `formula_terms` attribute is only allowed on a variable which has a
`standard_name` listed in Appendix C, or on a bounds variable of a
variable which has a `standard_name` listed in Appendix C.
In that case, `formula_terms` on bounds will not cause an error. The CF
document does not prohibit bounds on `formula_terms` at present, and I
don't think it should, as we've discussed earlier in this ticket. You're
not convinced about that, I know. One of your objections is monotonicity,
but I would point out that we allow bounds on auxiliary coordinate
variables, which aren't necessarily monotonic. For example, a trajectory
in 1D might reverse direction at one of its cell boundaries; this boundary
would then not lie between the points that it separates. Formula terms
aren't as bad as that anyway: they might not be strictly monotonic (i.e.
they might have repeated values) but I expect they're monotonic.
I continue to think we should allow bounds on formula terms or formula
terms on bounds, because it's convenient. This is not replication of
metadata, but it allows two possible routes to the metadata. Since both
would need to be supported, they may as well be allowed together. In that
case, the CF checker could detect an inconsistency quite easily, starting
from the coordinate variable. That's a third case to add to David's two.
{{{
dimensions:
z = 19 ;
y = 73 ;
x = 96 ;
bound = 2 ;
variables:
double hybrid_sigma(z) ;
hybrid_sigma.standard_name =
"atmosphere_hybrid_sigma_pressure_coordinate" ;
hybrid_sigma.formula_terms = "a: A b: B ps: PS" ;
hybrid_sigma.bounds = "hybrid_sigma_bounds" ;
double A(z) ; // HAS bounds
A.bounds = "A_bounds" ;
double B(z) ; // HAS bounds
B.bounds = "B_bounds" ;
double PS(y, x) ;
double hybrid_sigma_bounds(z, bounds) ;
hybrid_sigma_bounds.formula_terms = "a: A_bounds b: B_bounds
ps: PS" ;
double A_bounds(z, bounds) ;
double B_bounds(z, bounds) ;
}}}
Here, starting from hybrid_sigma, you can reach A_bounds via
hybrid_sigma.formula_terms and A.bounds, or via hybrid_sigma.bounds and
hybrid_sigma_bounds.formula_terms. (NB David's second example should have
hybrid_sigma_bounds.formula_terms in the third line from the end.)
Cheers
Jonathan
--
Ticket URL: <https://cf-trac.llnl.gov/trac/ticket/147#comment:22>
CF Metadata <http://cf-convention.github.io/>
CF Metadata
