Add flexibility for TFreeze form w/ different model definition of temp/salt#893
Conversation
…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.
|
@Hallberg-NOAA this seems to work as desired in OM5, so I think it is ready for evaluation. |
|
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 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. |
|
Gaea regression: https://gitlab.gfdl.noaa.gov/ogrp/mom6ci/MOM6/-/pipelines/27372 ✔️ 🟡 New reported parameters:
This PR should be squash-merged. |
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.