Skip to content

Add flexibility for TFreeze form w/ different model definition of temp/salt#893

Merged
marshallward merged 6 commits into
NOAA-GFDL:dev/gfdlfrom
breichl:TFreeze_error
May 8, 2025
Merged

Add flexibility for TFreeze form w/ different model definition of temp/salt#893
marshallward merged 6 commits into
NOAA-GFDL:dev/gfdlfrom
breichl:TFreeze_error

Conversation

@breichl
Copy link
Copy Markdown

@breichl breichl commented Apr 30, 2025

The current code won't allow running with the TEOS10 or Roquet equation of state with a linear freezing temperature. While the TEOS10 and Roquet equation of states were not designed for linear freezing point equations, there are valid cases where a user may desire to use a linear freezing point equation. For example, SIS2 only uses a linear freezing point equation, so it may be preferred to use MOM6 with the same equation as SIS2. Therefore, this PR suggests to change the FATAL error to a WARNING.

@breichl breichl requested a review from Hallberg-NOAA April 30, 2025 14:07
…m model

- If the model is absolute salinity, this allows one to convert the salinity to practical salinity before calling the freezing point subroutine.
- If the model is conservative temperature but the freezing point subroutine returns the potential temperature, this allows one to convert the freezing point to conservative temperature.
- The new flags are TFREEZE_S_IS_PRACS = True if TFreeze expects practical salinity (default is false for TEOS10 or TEOS_POLY TFREEZE_FORM, otherwise it is true) and TFREEZE_T_IS_POTT = True if TFreeze returns a potential temperature (default is flase for TEOS10 or TEOS_POLY TFREEZE_FORM, otherwise it is true).
- The EOS type now stores the use_conT_absS flag to make these checks easier.
@breichl breichl changed the title Change fatal TFreeze error to a warning error with Roquet/TEOS10 EOS. Add flexibility for TFreeze form w/ different model definition of temp/salt May 5, 2025
@breichl
Copy link
Copy Markdown
Author

breichl commented May 5, 2025

@Hallberg-NOAA this seems to work as desired in OM5, so I think it is ready for evaluation.

@breichl
Copy link
Copy Markdown
Author

breichl commented May 5, 2025

The previous issue was in the unit testing, thanks to @marshallward I figured out that it was the unit test for the second derivative of density with respect to temperature when using WRIGHT that was failing:

The values of WRIGHT drho_dT_dT disagree. -1.1402818751119731E-02 and -7.2448
371213340561E-03 differ by -4.15798163E-03 ( -4.46E-01), tol= 3.11848682E-04
The values of WRIGHT drho_dT_dP disagree. -1.1893735082701434E-09 and -1.3077
249288733402E-09 differ by 1.18351421E-10 ( 9.48E-02), tol= 8.87638143E-12

I don't understand this problem at all. But I fixed it by initializing the three new logicals in the EOS unit type. Could it be related to the "use_Wright_2nd_deriv_bug" logical that is also in this type? I don't know, but the code passes the tests now.

@marshallward
Copy link
Copy Markdown
Member

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

New reported parameters:

  • TFREEZE_T_IS_POTT
  • TFREEZE_S_IS_PRACS

This PR should be squash-merged.

@marshallward marshallward merged commit cd2ee22 into NOAA-GFDL:dev/gfdl May 8, 2025
51 checks passed
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.

3 participants