Skip to content
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

Resolve warning about S_REF units #425

Merged
merged 2 commits into from
Aug 21, 2023

Conversation

adcroft
Copy link
Member

@adcroft adcroft commented Jul 25, 2023

The units of S_REF were first registered in "PSU" and then later by benchmark in "ppt" which led to a WARNING. Although there is no uniformity to the units of S_REF throughout the user code (currently PSU, ppt, and 1e-3, are all used), benchmark is the only one that leads to a warning in the current suite and changing all to be consistent would 1) unnecessarily update the doc files, and 2) not be correct for all models. Bottom line, I'm punting on the best way to handle units of salinity. This commit resolves the only WARNING we currently get in the MOM6-examples suite.

The units of S_REF were first registered in "PSU" and then later by
benchmark in "ppt" which led to a WARNING. Although there is no uniformity
to the units of S_REF throughout the user code (currently PSU, ppt, and 1e-3)
are all used, benchmark is the only one that leads to a warning in the current
suite and changing all to be consistent would 1) unnecessarily update the doc
files, and 2) not be correct for all models. Bottom line, I'm punting on
the best way to handle units of salinity. This commit resolves the only WARNING
we currently get in the MOM6-examples suite.
@codecov
Copy link

codecov bot commented Jul 28, 2023

Codecov Report

Merging #425 (a9de007) into dev/gfdl (d107737) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

❗ Current head a9de007 differs from pull request most recent head 11dd301. Consider uploading reports for the commit 11dd301 to get more accurate results

@@             Coverage Diff              @@
##           dev/gfdl     #425      +/-   ##
============================================
- Coverage     38.05%   38.05%   -0.01%     
============================================
  Files           269      269              
  Lines         77417    77417              
  Branches      14300    14300              
============================================
- Hits          29462    29461       -1     
  Misses        42613    42613              
- Partials       5342     5343       +1     
Files Changed Coverage Δ
src/user/benchmark_initialization.F90 95.95% <100.00%> (ø)

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@Hallberg-NOAA
Copy link
Member

I think that this may be the most parsimonious solution, but it is going in the wrong direction. "ppt" and "1e-3" are generally synonymous (although some might point out that "ppt" could also mean "1e-12" for parts per trillion), but "PSU" is only used with one specific definition of salinity, based on the measured conductivity of water, and is only useable with a subset of our equations of state. My preference would be to move the generic functions (like the ones that set the vertical coordinate) toward all using "ppt".

@marshallward
Copy link
Member

Any idea how much work that would be? I found about 7 instances of psu in unit fields, and about 50 for 1e-3.

Although in the wrong direction, maybe this could be taken as fixing one problem while leaving the other problem in more or less the same state?

@Hallberg-NOAA
Copy link
Member

My count in the code is 27 instances of PSU as a part of a units= argument, 46 instances of 1e-3, and 37 instances of ppt. If we exclude the much less heavily standardized user/ and tracer/ code, these numbers are 17, 2, and 12. Some of these are in numerators, while others are in denominators.

These are not large numbers, and they are easy enough to find. There are, however, more than 700 instances where salinity units are documented in comments via a construct like '[S ~> ppt]', and the only instances where we use '[S ~> PSU]' is in some of the equation of state code where the salinity must be in PSU for the expressions to be physically correct.

My proposal would be to use 'PSU' only when we actually mean PSU and not parts per thousand. As for the others, I would suggest we try to standardize the parameter units with ppt or 1e-3, although 'ppt-1' might be better than '1e3' or '(1e-3)-1' when salinity units appear in the denominator.

@StephenGriffies
Copy link

I concur with all the points raised by @Hallberg-NOAA .

Copy link
Member

@marshallward marshallward left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've agreed to apporve this PR for now, and address the ppt/PSU/10-3 unit issue later.

@marshallward
Copy link
Member

Gaea regression: https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/20375 ✔️

@marshallward marshallward merged commit 5afb122 into NOAA-GFDL:dev/gfdl Aug 21, 2023
@adcroft adcroft deleted the user-benchmark-s-unit branch October 24, 2024 13:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants