Dangerous default setting of ln_useCT

[timgraham]

Description

The variable ln_useCT is set to True in nameos in namelist_ref. This variable is not used directly in eos but is used in SBC to determine whether the model is using conservative temperature and therefore needs to convert to potential temperature before SBC modules are called. This could potentially cause errors in the simulation if the value of nn_eos and ln_useCT are not consistent

For example, if nn_eos=0 (to use EOS-80) but ln_useCT=True then the model will be using potential temperature but the function to convert from conservative to potential temperature will still be called in SBC.

Alternatively, if nn_eos=-1 (to use TEOS-10) then the model will be using conservative temperature but the it won't be converted to potential temperature for use in SBC.

Please correct me if I'm wrong about this

Recommendation

I think there are 2 possible solutions:

1) Add a consistency check to stop the model if the values of nn_eos and ln_useCT are not consistent (probably the less invasive option for nemo_v3.6_STABLE

2) Remove ln_useCT and base the decision on nn_eos alone.

[gm]

You are correct. When we (with Fabien) introduced TEOS-10 and the Conservative Temperature (CT), we were thinking that using CT instead of Potential Temperature (PT) in the calculation of air-sea fluxes (either bulk or coupled case) should not make errors larger than the uncertainty in the bulk formulea themselves. This was to potentially avoid the compute PT from CT at each timestep. It was a wrong good idea. They may exist systematic large scale differences with CT compared to PT.

I strongly suggest your second solution for the trunk: just remove the ln_useCT from the namelist and force the call of the SST conversion from CT to PT using nn_eos namelist parameter. 

For v3.6, I think we can live with that. People are not changing the EOS every days, and if they want to do so, they should read the documentation which precise the use of ln_useCT. 

Gurvan

PS: for the trunk, I think it will be even better if nn_eos is replaced by three logical (ln_EOS80, ln_TEOS10 and ln_SEOS) all false by default in the namelist_ref, so that for each configuration, the user have to chose an equation of state. Tell me if you want to go that far. If not I will probably do that myself in the SIMPLI_1 branch.

[timgraham]

Consistency check added to nemo_v3_6_STABLE at r6482. I'd already coded this before you made your comment Gurvan so it made sense to commit it.

For the trunk I'm happy to change nn_eos to 3 logicals. I was planning to keep the variable ln_useCT so that it is still checked in SBC but remove it from the namelist and set the value based on nn_eos (or the logicals that replace it). If in future we decided to add yet another different equation of state I think this would make it easier.

[timgraham]

Fixed in trunk (including Gurvan's suggestion for replacing nn_eos with logicals described above) at r6489

[gm]

With the changes a bug has been introduced in the trunk only (v3.6_stable is OK).

The bug concern the 2 routines providing the freezing point. In both routine, the following 2 couples of lines (1022 and 1035) in eos_fzp_2d) and (1072 and 1081) in eos_fzp_2d have to be changed from:

      CASE ( np_teos10, np_eos80 )                !==  CT,SA (TEOS-10 formulation) ==!
...
      CASE ( np_seos )                     !==  PT,SP (UNESCO formulation)  ==!

to:

      CASE ( np_teos10, np_seos )      !==  CT,SA (TEOS-10 and S-EOS formulations) ==!
...
      CASE ( np_eos80 )                !==  PT,SP (UNESCO formulation)  ==!

Correction done in revision rev=6504