This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#104: Clarify the interpretation of scalar coordinate variables -----------------------------+---------------------------------------------- Reporter: jonathan | Owner: [email protected] Type: defect | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by jonathan): Dear Mark Thanks for your example. I think it is notable that you say netCDF datasets with many scalar coordinate variables have often been converted from other formats. I would suggest this means the people who wrote the converters didn't fully understand the CF convention, and if so, this is a mistake. Indeed, a previous email exchange that we had revealed that I had made such a mistake in my conversion program pp_cfwrite, which I'll correct. (Namely, even if there is only one model level, it should have a size-one dimension for the level, in order to indicate that the model level number and the vertical coordinate are linked.) Why are a, p0 and b included as auxiliary coordinate variables? - David also asks about them. I guess they are formula terms for the atmosphere hybrid sigma pressure coordinate. Formula terms are not normally listed by the coordinates attribute; there is no prohibition on doing that, but I don't see it suggested in Section 4.3.2. Similarly perhaps surface_pressure is also a formula term (ps in the formula) and should not be in the coordinates attribute. Why isn't there a vertical coordinate variable (perhaps a scalar)? This variable ought to have a formula_terms attribute, pointing to these other quantities. As you and Richard have pointed out before, there is a link between forecast_period, forecast_reference_time and time. This link should be indicated in the file by use of coordinate and auxiliary coordinate variables, rather than coding them all as scalars. In the CF convention, source is an attribute, not a coordinate variable. If experiment_id and model_id could vary separately, it is fine to have them as scalar coordinate variables. On the other hand, if this data variable is really one from a set of experiment--model combinations, it would be more informative to encode them as auxiliary coordinate variables of a shared size one dimension, because they belong together. I think this variable is probably equivalent to one which has six independent dimensions (latitude, longitude, vertical, time, forecast time, and ensemble member). This is fine, I think, since a variable in which all six of these dimensions were multivalued is quite likely to be useful sometimes. I'm not suggesting that the file is erroneous. It no doubt passes the CF checker and is CF-compliant, but it is not ideal. It suggests that certain quantities are independent coordinates which actually are not. The problem is that many errors cannot be formally detected, because much of CF is optional, and because we allow everything which is not explicitly probibited, in order to allow other conventions to be used in combination with CF. So I don't think the data creator should be worried by our being more precise about what CF is intended to mean. It will still be a valid file, but not a good example of CF. Best wishes Jonathan -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/104#comment:16> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
