Note on possible system simplification

Last edited Timestamp?

We need to simplify the code for both maintenance and future evolution. This means fewer options, and a consensus on the default (and thus well validated) set of numerics.

The idea is to change the used choices from :

linear filtered free surface ocean with TVD, "Madec" isoneutral diffusion, and standard equation of state ; levitating sea-ice with virtual salt fluxes

to :

Non linear (vvl) split-explicit (ts) free surface with 3rd order advection (UBS), "Griffies" isoneutral diffusion and TEOS10 ; embedded multi-category sea-ice (exact fluxes).

Environment :

• suppress most of the CPP keys, if not all of them

• dynamical allocation: return back to standard allocation (no more CALL wrk_alloc and CALL wrk_dealloc)

Free surface & vertical coordinate :

• remove filtered free surface and all associated solvers

• default : non-linear free surface

• linear option set without optimization (i.e. starting from the non-linear case with minimal changes, not optimal changes), or linear case suppressed ??

• vertical coordinate : default option mixte zps/s-tilde coordinate (thus with variable volume level), with mixte zps*/s*, mixte z/s, zps, z and s coordinate system as sub-option (same code used)

Needs :

• split-explicit free surface adapted to AGRIF refinements and TAM

• tracer solved systematically as thickness weighted tracer: D_t(e_3t T)

• no more substitute (domzgr_substitute.h90): all e3 always defined at before, now and after time steps.

• sea-ice : embedded sea-ice only, so management of land-fast ice and especially sea-ice approaching the ocean-bottom.
  

Equation of State (eos) :

• EOS10 as default + 1 simplified eos. Suppression of the now used EOS.

• EOS provides systematically alpha and beta (used in ldf_iso, bbl, mld, npc…)

• no more potential density (mixed layer depth computed from alpha & beta)

• efficient transfer function from conservative temperature to potential temperature and vice versa.
  

Coupled interface to the atmosphere :

• OASIS-MCT only: remove OASIS 3 interface.

• Multi-category sea-ice interface
  

Physics :

• avm defined at t-point ==> suppress avmu, avmv and ~10 lbc_lnk calls

• LDF: remove 1D and 2D cases, keep only 3D ; laplacian and bilaplacian coefficients defined at the same points (T and F) ; time varying coefficients (Smagorinsky, function of growth rate of baroclinic instabilities): better integration rather than configuration dependent cases. On going work, see #1260 and the associated wiki page 1260_CNRS0_NOC1_LDF

• TKE remove (use GLS instead?)

• KPP remove unless if-less KPP is implemented (Lemarié et al 2012). Keeping a validated KPP scheme in the system make sense for comparison purposes.

• Non-penetrative convection : either correct it (using alpha & beta) or remove it • remove the explicit vertical diffusion

Configurations :

• remove all hard coded specific alterations associated with configurations (ORCA,…) while introducing associated input files

• same for the definition of coordinate system (s, mixed z-s): only a simple case hard coded. For more sophisticated cases, the required information should be read in an input file.
  

Obsolescent features : to be suppressed

• remove LIM2 : only LIM3 remains in the system

• remove OBC : only BDY remains in the system (==>> done in v3.6)

• acceleration of convergence (in particular, rdttra function of k ==> unique rdt)

• remove Neptune effect : ORCA1 run shows its inefficiency.

• duplicate isoneutral operator: keep only the Griffies' one

• Smagorinsky (?) : use 3^rd order operator (UBS) instead and remove it ?

• tracer advection schemes: diminish their number. Typically one module for 2^nd /4 ^th order and one for a 3 ^rd order scheme, both associated with an optional flux limiter to ensure positivity.
  

• suppress cross-land advection

• remove no-slip accurate option (key_noslip_accurate). Module divcur.F90 (==>> done in branch 2014/dev_CNRS0_NOC1_LDF​

Outputs :

• remove Dimg format ? (agreement needed from DRAKKAR group)

• remove IOIPSL: the key issue here is do we believe XIOs is able to work on all existing and foreseen platform?