PCMDI / cmip6-cmor-tables

JSON Tables for CMOR3 to create CMIP6 dataset
BSD 3-Clause "New" or "Revised" License
31 stars 46 forks source link

positive attribute of `upward_air_velocity` #421

Open larsbuntemeyer opened 1 week ago

larsbuntemeyer commented 1 week ago

Basically a duplication of

upward_air_velocity should probably have the positive = up attribute. This is not the case in the corresponding cmip6 cmor table but i guess from the logic it should have the positive attribute set... (all other standard names containg one of ["incoming", "outgoing", "downward", "upward", "downwelling", "upwelling", "sinking"] are directional variables with a positive attribute set either up or down except for upward_air_velocity...)

taylor13 commented 1 week ago

In the CMIP data request tables, a "positive" attribute that can be attached to a variable (like a flux of energy) has no grounding in CF. The "positive" attribute in CF applies to coordinate variables (and their bounds) only. The CMIP-defined "positive" attribute, although not a part of CF, does not make CMIP files non-compliant with CF because CF permits users to define "extra" metadata, which CF knows nothing about.

The "positive" attribute attached to some regular CMIP variables was introduced as an aid to modeling groups attempting to write model output conforming to the CMIP requirements. For example, the CMOR code used by many modeling groups could determine which direction a flux was considered to be positive (from the "positive" attribute specified) without "reading" the standard_name. The data writer could specify which direction was assumed to be positive for their own flux variable (through an argument passed to CMOR), and then CMOR could check to see whether the sign needed to be reversed before writing the variable to a CMIP-compliant file.

Bottom line is that for CMIP, yes, positive=up could be defined for this variable, but it is irrelevant to the CF conventions.

larsbuntemeyer commented 1 week ago

Yes, agreed! Thanks for clarifications!