-
Notifications
You must be signed in to change notification settings - Fork 18
Add some marine variables #131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 2 commits
f7fd6ba
2cfaeb5
7c9475d
36f43b1
bd83e9b
c5f139e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1000,6 +1000,24 @@ | |
| <type units="m3 m-3">real</type> | ||
| </standard_name> | ||
| </section> | ||
| <section name="marine"> | ||
| <standard_name name="potential_temperature_of_sea_water" | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I've commented above on why I have this naming inconsistency. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @svahl991 Oops, sorry, I missed your comment. Should we follow the same convention for salinity then?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Do you mean There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FYI @svahl991 : the CF name for sea water potential temperature is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @climbfuji agreed. I dont think reordering the potential temperature of sea water variable improves clarity or makes the name any different in terms of ambiguity from the cf name. I dont think consistency with atmosphere names is a good reason to deviate from the CF names if we don't need to personally.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, the crux is that CF is inconsistent in that regard. You find names like One of the goals of ESMStandardNames is to provide a clear framework for how to construct new names. To do that, you need a clear set of rules for how to compose names. After reviewing the names in the CF conventions and the different, inconsistent ways to construct names based on those, we spent considerable effort to decide on one way to compose these names. Consequently, all names in the ESMStandardNames must follow these rules, even if that means that they differ from CF. The rules are defined in https://github.com/ESCOMP/ESMStandardNames/blob/main/StandardNamesRules.rst. It basically comes down to "what is the base name" and what is a qualifier such as "component", "medium", ... Looking at the rules and at this particular example, "sea_water_potential_temperature", I can see your point. For one, there is no prefix "potential_temperature" and I would argue that it hardly qualifies as a "component" of a base name. Also, just "sea_water" by itself is not really a base name? Is the base name then The longer you stare at this stuff, the more confusing it gets ...
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @climbfuji
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@mkavulich , So are you suggesting that maybe ESM should be changed to conform to the CF name for
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @svahl991 No, I'm suggesting the opposite. The rules as we currently have them specify that the name should be base_name_[in_medium], though this needs to be updated to include [of_medium] as an option for cases like this where the base name is an inherent property of the medium, not something contained in it (this is something we have discussed before but apparently never got around to adding). So |
||
| description="sea water potential temperature"> | ||
| <type units="K">real</type> | ||
| </standard_name> | ||
| <standard_name name="sea_water_depth" | ||
| description="The depth below the surface of the sea"> | ||
| <type units="m">real</type> | ||
| </standard_name> | ||
| <standard_name name="sea_water_salinity" | ||
| description="The salinity of sea water"> | ||
| <type units="ppt m">real</type> | ||
|
||
| </standard_name> | ||
| <standard_name name="sea_water_temperature" | ||
| description="The temperature of sea water"> | ||
| <type units="K">real</type> | ||
| </standard_name> | ||
| </section> | ||
| <section name="diagnostics"> | ||
| <standard_name name="total_precipitation_rate_at_surface"> | ||
| <type units="m s-1">real</type> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will comment here that while
Kis used in some products, degC is more common. MOM6 (model SOCA interfaces) outputs model fields indegC. Looking at a few common products I see they differ though, like so:OISST, SODA, ORAS5 uses
degCEN4, OSTIA (GHRSST) uses
KI guess we can't make up our mind.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a note here that GHRSST includes a lot of members from all over the world https://www.ghrsst.org/about-ghrsst/ not just OSTIA (Australian Bureau Of Meterology, NOAA, Canadian Meterological and Oceanographic Society, among many others from elsewhere in Europe etc). See here for a list:
https://www.ghrsst.org/ghrsst-data-services/for-sst-data-producers/ghrsst-catalogue/#/search?from=1&to=30
The GHRSST conventions follow the CF conventions as far as possible with a little extra metadata. Documented in GDS2.1 (page 83, convention is Kelvin for SST variable there).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Dooruk In the Standard Names dictionary the exact units are not binding, but rather guidelines on the dimensionality of the described quantity (https://github.com/ESCOMP/ESMStandardNames/blob/main/StandardNamesRules.rst#units). We prefer to use SI units wherever possible, since those are standard and unambiguous in their dimensionality, so
Kis preferred over any other temperature variable here.