New URL for NEMO forge!

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#1687 (Dangerous default setting of ln_useCT) – NEMO

Opened 8 years ago

Closed 8 years ago

#1687 closed Bug (fixed)

Dangerous default setting of ln_useCT

Reported by: timgraham Owned by: nemo
Priority: low Milestone: 2015 simplification
Component: OCE Version: trunk
Severity: Keywords:



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


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.

Commit History (3)


#1687 - trunk: correct an error in the EOS-80 freezing point


#1687 fixed. Namelist changes required.


#1687 - Add a consistency check for the setting of ln_useCT and nn_eos

Change History (5)

comment:1 Changed 8 years ago by 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. 


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.

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by timgraham

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:4 Changed 8 years ago by gm

  • Milestone changed from 2015 nemo_v3_6_STABLE to 2015 NEMO simplification
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Type changed from Defect to Bug
  • Version changed from v3.6 to trunk

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)  ==!


      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

comment:5 Changed 8 years ago by gm

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.