Open aekiss opened 1 year ago
Note that this will determine whether the prognostic temperature is potential or conservative temperature, and the initial condition should match this - see https://github.com/COSIMA/access-om3/issues/47 and https://github.com/COSIMA/access-om2/issues/206. Or to put it the other way around, if we set up a config that uses the ACCESS-OM2 initial condition (which is conservative temperature), we need to use a matching equation of state in MOM6.
I'm not sure if this also applies in MOM6, but in MOM5 the surface temp diagnostic is simply the prognostic temperature. If this is conservative temperature it differs from the potential temperature people normally think of when they want "SST", and so we need to output surface potential temperature as well - see https://github.com/COSIMA/access-om2/issues/203#issuecomment-707507691
Using conservative surface temperature for the CICE default
initial condition is not ideal but probably acceptable, as the the numerical difference is between -0.15 C and 0.10 C for 99% of the surface ocean: https://github.com/COSIMA/access-om2/issues/206 and the sea ice adjusts away from the IC quite quickly, forgetting the IC in a few years.
Another wrinkle: ACCESS-OM2 uses the pre-TEOS10 EOS which is Jackett et al. 2006 (see https://github.com/COSIMA/access-om2/issues/140), but AFAIK this EOS is not available in MOM6 so we were intending to use ROQUET_RHO
which is the Roquet el al 2015 expressions for TEOS-10. This is not quite the same conservative temperature, but I suspect the difference is very small so we can use the ACCESS-OM2 initial condition.
We may also need to be careful to use freezing point settings that are appropriate for the EOS we choose.
My understanding is that we'll have to regenerate/modify the ACCESS-OM2 initial condition regardless of which EOS we choose?
If we stick with what is currently used in the CIME configuration (the default: WRIGHT
) we'll need to create an initial condition of potential temperatures instead of conservative temperatures
If we change to ROQUET_RHO
, we'll need to create an initial condition of absolute salinities instead of practical salinities
The latter, however, potentially also requires changes to the NUOPC cap and elsewhere - from the comment on the USE_CONTEMP_ABSSAL
parameter in MOM_input, which sets prognostic T&S to the conservative temperature and absolute salinity:
Care should be taken to convert them to potential temperature and practical salinity before exchanging them with the coupler and/or reporting T&S diagnostics.
@aekiss, what's the best way forward here? Is there any value in first trying to get WRIGHT
working (which seems simpler) before moving on to ROQUET_RHO
?
I saw in Jackett et al. 2006:
The difference between practical salinity and absolute salinity is discussed, and it is shown that the present practice of essentially ignoring the difference between these two different salinities is unlikely to cause significant errors in ocean models.
Is this still considered to be the case?
I think it would be fine to do initial tests with WRIGHT
, incorrectly using the conservative temperature initial condition, but if possible we should change to ROQUET_RHO
before doing any production runs.
Good point re. the surface values for diagnostics and (especially) coupling. If the MOM6 cap doesn't enable coupling with potential T we should discuss with other modelling groups to see how they manage it. In MOM5 this is controlled by pottemp_equal_contemp
which defaults to false, meaning potential temp is passed to the coupler even if prognostic temp is conservative - see https://github.com/COSIMA/access-om2/issues/148
Re. practical vs absolute salinity: I'm not sure how much they differ (OM2 uses a pre-TEOS10 EOS that uses practical salinity) - I'd need to look into it some more to find out what people normally do.
Just noting that we need to be careful with setting the value of Cp in accordance with the EOS - see https://github.com/COSIMA/MOM6-CICE6/pull/5#discussion_r1287810507
The latter, however, potentially also requires changes to the NUOPC cap and elsewhere - from the comment on the
USE_CONTEMP_ABSSAL
parameter in MOM_input, which sets prognostic T&S to the conservative temperature and absolute salinity:
Upon reviewing the codebase for the utilization of USE_CONTEMP_ABSSAL
, when USE_CONTEMP_ABSSAL
is set to true, the prognostic temperature is configured to the conservative temperature and the prognostic salinity is set to absolute salinity. Refer this code
If the MOM6 cap doesn't enable coupling with potential T we should discuss with other modelling groups to see how they manage it.
Within the Nuopc cap (mom_ocean_model_nuopc.F90
), the conservative temperature is converted to potential temperature specifically when sfc_state%T_is_conT
is true, which is the case only when USE_CONTEMP_ABSSAL
is also true. Similarly, the conversion of absolute salinity to practical salinity happens when sfc_state%S_is_absS
is true, and this is true only when USE_CONTEMP_ABSSAL
is set to true. Refer this code
Thanks for looking in to this @ezhilsabareesh8. That's good news that the NUOPC cap already handles the conversion. So if we turn on USE_CONTEMP_ABSSAL
, we're one step closer to being consistent with ACCESS-OM2 and its initial conditions.
The next question then is do we initially want to use an EOS that is the same/similar to the pre-TEOS10
EOS used in ACCESS-OM2? It looks to me as though there is a JACKETT06
EOS in MOM6 that looks to be the same/similar? Should we have a configuration using this before moving on to ROQUET_RHO
?
Then there's also the question of salinities. I think the ACCESS-OM2 initial conditions are conservative temps and practical salinities? But in MOM6 it doesn't appear to be possible to run with these as prognostic variables together. So should we:
Thoughts @aekiss
The pressure gradient calculation may be a lot slower if we use anything other than WRIGHT
- see https://mom6.readthedocs.io/en/main/api/generated/pages/Discrete_PG.html:
All the above definite integrals are specific to the Wright equation of state; the use of a different equation of state requires analytic integration of the appropriate equations. We have found, however, that high-order numerical integration appears to be sufficient. Although the numerical implementation is more general (allowing the use of arbitrary equations of state), it is significantly more expensive and so we advocate the analytic implementation for efficiency.
But that would be irrelevant if the pressure gradient calculation is a negligible component of the overall cost.
See Bob's response to @adele-morrison: https://github.com/mom-ocean/MOM6/discussions/1592
Might be good to use WRIGHT_REDUCED
as the interim EOS to get a reproducible order of operations - see https://github.com/NOAA-GFDL/MOM6/pull/331 and https://github.com/mom-ocean/MOM6/issues/1331#issuecomment-2011622593
Just noting, the most recent MOM_input we have from GFDL OM5 still uses WRIGHT
, but @stephengriffies has said that they plan to move to a TEOS10-based EOS (I'm guessing ROQUET_RHO
).
In our testing in mom6-panan NEMO
(equivalent to ROQUET_RHO
) was 8.5% slower than WRIGHT
(3:37 vs 3:20 for a 3mo run). I'm guessing the new ROQUET_RHO
implementation is similar.
@AndyHoggANU, @adele-morrison is that an acceptable price to pay?
We would need to convert conservative temperature to potential temperature SST for coupling to CICE (and the UM in ACCESS-OM3). Does anyone know if this can be done in MOM6 or the CMEPS mediator?
In our testing in mom6-panan
NEMO
(equivalent toROQUET_RHO
) was 8.5% slower thanWRIGHT
(3:37 vs 3:20 for a 3mo run). I'm guessing the newROQUET_RHO
implementation is similar.@AndyHoggANU, @adele-morrison is that an acceptable price to pay?
Does seem a surprisingly heavy price to pay. But I would like to re-test with our @minghangli-uni ’s current timing methods before we make a call …
We would need to convert conservative temperature to potential temperature SST for coupling to CICE (and the UM in ACCESS-OM3). Does anyone know if this can be done in MOM6 or the CMEPS mediator?
I thought this is already done in the NUOPC cap - see this comment above.
Within the Nuopc cap (
mom_ocean_model_nuopc.F90
), the conservative temperature is converted to potential temperature specifically whensfc_state%T_is_conT
is true, which is the case only whenUSE_CONTEMP_ABSSAL
is also true. Similarly, the conversion of absolute salinity to practical salinity happens whensfc_state%S_is_absS
is true, and this is true only whenUSE_CONTEMP_ABSSAL
is set to true. Refer this code
This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:
https://forum.access-hive.org.au/t/cosima-twg-meeting-minutes-2024/1734/16
We should choose a suitable equation of state.
ROQUET_RHO
looks good - see discussion: https://github.com/COSIMA/mom6-panan/issues/24