Skip to content

namelist_review

Jump to bottom
jmm edited this page Jul 10, 2018 · 13 revisions

namelist_oce review

namrun

  • automatisation of nn_no, ln_rstart
  • use cn_ocerst_indir and cn_ocerst_outdir individual segments.
  • ln_clobber = .true.

namdom

  • rn_hmin = -3. : means 3 model levels as minimum. With partial cell this may be as small as 0.6 to 0.8 m. When tides will be on, it is likely as this will produce 'drying' of some model cells ( Is it important ? Jerome, Nicolas ?)

namsplit

  • ln_bt_fw : ask information to Jerome ?
  • ln_bt_nn_auto = .true. ! ==> nn_baro will be chosen automatically, no matter the value in the namelist.
  • rn_bt_cmax = 0.7 ! sound reasonable.
  • nn_bt_flt = 2 ! recommended values for vvl ( Julien Jouanno). It seems that the model blows up with other value

namcrs

  • worth to give a try ??

namtsd

  • no damping so far, but might be usefull for buffer zones near the BDY's.
  • Drakkar version allow different files for initial conditions and restoring !

namsbc

  • nn_fsbc =2 ! Camille claims that there are long term differences in LIM3 output for nn_fsbc=1 and greater value
  • ln_apr_dyn = .false. ! Do we want atmospheric pressure gradient effect
  • nn_ice_embd = 1 ! I think it is ok with vvl
  • ln_dm2dc =.true. ! Yes because we have high vertical resolution near the surface ~ 1m. With no diurnal cycle we miss the night convection and ends up with too warm (and buoyant) surface layers.
  • nn_fwb = 2 ! Check in details the impact ... I use to use 0 here

namtra_qsr

  • ln_traqsr = .TRUE. ! I think that we need light penetration. If not, all the solar flux heats the surface layer only and produce a far to warm SST.

  • ln_qsr_2bd : 2 band Jerlov law for light penetration. It assumes a constant (space/time) attenuation depth corresponding to clear water for the first band and and an exponential decay for the second band.

  • ln_qsr_rgb : again a 2 band penetration law. First band is the same than in Jerlov law (penetration depth of 0.35 m, constant) But for the second band, the attenuation is computed differently for Red Green and Blue (RGB) as a function of the surface chlorophyll concentration. (Hence the need for an external file for chlorophyll climatology).

    Although more realistic, this parametrisation tends to give a warm bias on the SST in period of bloom. Mercator proposed a mix of the 2 schemes (2bd and rgb), mainly based on 2bd, but in which the 2nd band attenuation depth is computed from the chlorophyll concentration (Murtugudde , J. Climate, 15, 470–486, 2002.). This is already implemented in some ORCA12 drakkar runs, and gave better results.

namsbc_rnf

  • ln_rnf_mouth = .true. ! In general we add and extra vertical mixing where the runoff is applied (as a precip) on the first layer of the model. ==>
  • rn_hrnf = 15 ! we use to have 10m but 15m is OK.
  • rn_avt_rnf = 1.e-3 ! We use to have 2.e-3 [ I think it is better ! ]

namsbc_apr

  • need to set this block if we choose to use atmospheric pressure forcing
  • ln_apr_obc : not sure this is still valid with BDY ???

namsbc_ssr

  • rn_deds = -100. ! After a lot of discussion with Anne-Marie, the state of the art for setting this piston velocity is not to consider the thickness of the first layer. We use to have -166.67 mm/day, in other words : 0.006 days/mm ==> 300 days/50meter (considered as medium SSS restoring by S. Griffies in his nomenclature 50/(300) m/day ). -100 is 0.01 days/mm, ==> 500 days for 50 meters.

IMPORTANT: in NATL60-CJM165, we do not have SSS restoring ! I think that if we decide to put some, we need to use the DRAKKAR version of SSS restoring where a filtering is node on the model field before computing the model-observation mismatch. Otherwise this will likely reduce the surface variability...

  • rn_sss_bnd = 4.0 : If we are going to use SSS restoring, a toping of the restoring term is needed. 4 mm is rather standard.

namlbc

  • rn_shlat = 2. (no slip) : In NATL60-CJM165 we had rn_shlat=0 ( free slip condition). Despite the fact that with increasing horizontal resolution, one day we will be able to resolve coastal boundary layer and have a true no-slip condition, I am not sure that at 1/60 we can afford to have no-slip everywhere... We know that the effect of no-slip on model solution is to decrease DWBC, and to enhance overshooting of the Gulf Stream, for instance. Further more, using UBS advection scheme, we do not know how this lateral boundary condition is really taken into account. When using vector form advection scheme, the shlat is used in the boundary condition for the vorticity equation in dynvor. Need more investigation ? (Florian ? )

nambdy

  • nb_bdy = 2 . OK Baltic is closed ! *cn_ice_lim : I think that LIM3 bdy are working and they should be used (better representation of fresh water inflow from the Arctic and Hudson Bay). NOTE: I put a ticket for a bug fix for nemo_3.6 with respect to these ice bdy when using LIM2 data at the boundary. Not sure it has been taken into account, but the fix is in DRAKKAR version. *ln_vol =.true. Volume control is desactivated when using time-splitting for the free-surface. There is a piece of code by Claude Talandier and Jerome to fix this, but pragmatically, when using flather bdy condition on SSH, the volume drift is controled by the SSH at the boundary, which is satisfactory.

nambfr

  • ln_bfr2d=.false. Using a localy enhance bottom friction ( eg Gibraltar, some sills...) may help the overflow... But probably requires some testing ...

nambbl

  • nn_bbl_ldf = 1 . So we use diffusive bbl. In the DRAKKAR code, we have a different test for activating bbl when using zps. With the santard code, we probably have too much bottom diffusion, everywhere. NATL60-CJM165 used the DRAKKAR code.

namtra_adv_mle

  • ln_mle = .false. Switch off Fox-Kemper parametrization. YES :(

namtra_ldf

  • ln_traldf_lap = .false.
  • ln_traldf_bilap = .false.

We let UBS doing the diffusion. OK

namtra_dmp

  • tradmp = .false. No TS restoring at all. We might need downstream of Gibraltar if the MSW is really too shalow in the NATL.

namdyn_adv

  • ln_dynadv_ubs = .true. . OK so nn_dynkeg is irrelevant ( not used).
  • ln_dynzad_zts =.false. : This may be important with 300 levels ? No idea how it works, nor if used in UBS scheme.

nam_vvl

  • ln_vvl_zstar = .true. YES !

namdyn_vor

  • ln_dynvor_een_old = .true. YES. With UBS een scheme is only used for the coriolis term. Using the new version (with Ducousso mask correction) leads to a strong overshoot of the GS... in ORCA025 ... But what about NATL60. (In CJM165 we also used the old dynvor scheme).

namdyn_hpg

  • ln_hpg_sco = .true. YES, mandatory with VVL

namdyn_ldf

  • ln_dynldf_lap = .false.
  • ln_dynldf_bilap = .false.

As for tracers, we let UBS do the dissipation of small scale. However, we may consider adding a sponge layer near the boundaries, if necessary. Bernard thinks about having a small background viscosity (bilap) in order to reduce the noise produced by UBS. In NATL60-CJM165, the noise is not that strong ... So what ? In case of adding this background visco, which value ?

namzdf

  • ln_zdfevd = .true. Yes !
  • nn_evdm = 0 ! #LOLO? evd apply on tracer (=0) or on tracer and momentum (=1)
  • rn_avevd = 10. ! #LOLO? evd mixing coefficient [m2/s]

2 last questions are always a point of discussion. Thierry advocates always for nn_evdm=1 but Gurvan, now think it is better not to mix momemtum.... The rn_avevd = 10. is the standard value in DRAKKAR. No clear sensitivity performed around this value. Laurent Debreu once commented that there should be a time-step dependency on this value (in the frame of Amandine Deklerke phd).

namzdf_tke

  • rn_ebb = 60 Why not 67.83 as suggested ?
  • nn_etau = 1 I think that the tke namelist should be reviewed by some experts. Jerome, Gurvan ?

namzdf_ddm

  • We never used this double diffusion parametrization. No ideas if it works at high resolution and no ideas of the effects. NATL60-CJM165 was not using ddm.

namzdt_tmx Do we use this param in the run without explicit tides ?

namzdf_tms_new Or do we use Casimir param ?

namobs Shall we consider to use the OBS operator with enact-ensemble, or jason2 (data are ready). Need to assess cost. Data volume is not bigger that original data set ( resolution independent).

namelist_ice review

  • In this run we work with LIM3 hence we have no references for this ice model at this high resolution. However, we have an EORCA12 run with lim3, whose namelist_ice setting were shared and discussed with Claude and Camille. The analysis below is just a comparison of the 2 namelists, the actual one corresponding to ORCA1 I presume.

  • On the other hand Claude and Camille implemented lateral melting (provided by Clement Rousset) in order to improve (or fix) a weird problem of ice thickness in marginal ice areas. [improvement achieved, but pb not fully resolved].

namicerun

  • no differences

namiceini

  • ln_iceini_file : Drakkar version where the initial ice condition can be specified via a file. May be a good choice to have GLORYS12 initial conditions ?

namiceitd

  • no differences

namicedyn

  • rn_pstar = 3.0e+04 ( instead of 2.0e+04)

namicehdf

  • no differences

namicethd

  • rn_maxfrzb =0. instead of 1. but likely to be irrelevant as ln_frazil=.false.
  • rn_cdsn ? ( This parameter is no more in EORCA12)

namicesal

  • no differences

namiceitdme

  • no differences
Clone this wiki locally