-
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 all 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,28 @@ | |
| <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
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. ESM naming has diverged from CF naming in some aspects. I notice that CF has 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. just to say, met office marine models have already been using the sea_water_potential_temperature CF names for multiple years. I think we notified that we wanted these in these standards a few years ago? CF standard names would be preferred if you want to share with other modelling centers? @svahl991 has a spreadsheet with the names we discussed on it somewhere I think. 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.
+1 to @twsearle 's post above, keeping the CF name would be preferential. |
||
| 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 practical salinity of sea water"> | ||
| <type units="PSU">real</type> | ||
| </standard_name> | ||
| <standard_name name="sea_water_absolute_salinity" | ||
| description="The absolute salinity of sea water"> | ||
| <type units="g kg-1">real</type> | ||
| </standard_name> | ||
|
Comment on lines
+1012
to
+1019
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 took a look at the CF conventions, and added their names for these two quantities. It looks to me like CF uses
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. OK, I looked again, closer, and CF naming has three names:
Do we want to duplicate all three names in ESM? I need scientific guidance here. 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. @Dooruk referred me to this issue. sea_water_salinity with units of 1e-3 (which I believe is equivalent to ppt): I don’t think it is necessary to keep this variable, as it reflects an older and less precise definition of salinity. sea_water_practical_salinity with units of 1 (which Travis noted is equivalent to PSU): This variable should be retained, as it is consistent with in-situ observations and is useful for validation and diagnostic analyses. sea_water_absolute_salinity with units of g kg⁻¹: This represents the most recent and precise definition of salinity and is therefore also worth keeping. If only one salinity variable were to be retained, I would lean toward sea_water_absolute_salinity, assuming it comes directly from the model output.
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. Thanks, @lren20 , for your insights. That's very helpful. Since these variables are all new to this ESM naming standard, we are free to do what makes sense and is clear for the modern community. We can look to CF naming for insight, but don't need to be constrained by it. Given what you've said, I propose we add two salinity names to ESM Naming in this PR:
Regarding the two options described in 1) above, currently this PR contains I will make that change later today unless I hear objections. 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 will ask @sinakhani and @guillaumevernieres input here (please see temperature unit comment above as well). @ss421 I see this turned out to be a can of worms, we could also discuss it during the Thursday JCSDA meeting?
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.
To be clear, it is only in JEDI generic code (such as VADER, SABER, and UFO) where we make a strong attempt to conform to using ESM names for the model variables. This is because it is most important in generic code to be clear and unambiguous about what the variables represent (and what units they have) since the code can be used by multiple models and organizations. So if, say, we choose to use the ESM name We also need to make sure we know which salinity units are appropriate for the new VADER code that inspired this PR (referenced in the PR description), so that we are sure to have an appropriate name for use there. (i.e., if the code formulas in VADER are expecting salinity to be in 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. Ok thanks, that separation makes more sense now. 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 think [ppt] is identical to [g/kg] based on their definitions. If I am also not wrong, 1 PSU should approximately equal to 1 ppt in oceanography (PSU is more recent definition for salinity but ppt is an older one). I expect all these three variables to be very close -- are they very different in your data outputs? For temperature, I think it is a choice to use degC or K since they only differ by a constant 273.15. As long as the dataset gives a unit for temperature, either choice is fine in my view. |
||
| <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).