#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