== Namelist framework description == This is an attempt to given the general philosophy behind the namelist_ref structure an what should appear in namelist_cfg. Such a description should probably appears in the DOC as well as in the system team and user wiki pages. === Reference namelist : === There is three type of namelist : (1) "manager" namelist ; (2) "associate manager" namelists ; and (3) "specific" namlists. (1) "manager" namelist : defines key parameters and activate through a logical the reading of the "associate manager" namelists. By default, all choices are deactivated, while choices is required (the model will stop at the initialization phase if no choice is made) . Such a namelist is characterized by a " (default: NO selection) " comment at the end of their opening line : {{{ !----------------------------------------------------------------------- &namXXX ! sort description (default: NO selection) !----------------------------------------------------------------------- }}} (2) "associate manager" namelist : are activated (3) "specific" namlists (i.e. independent namelists). - Set all . === configuration namelist : === === Key changes compare to v3.6 === - No more ORCA2 specific choices - deactivate all option and set to false all switches, except in so called "associated manager" namelists (see below their definition). '''things to be improved :''' - move in namsbc_wave namelist all the wave related variable that are in namsbc except ln_wave switch, that is: {{{ ln_cdgw = .false. ! Neutral drag coefficient read from wave model (T => ln_wave=.true. & fill namsbc_wave) ln_sdw = .false. ! Read 2D Surf Stokes Drift & Computation of 3D stokes drift (T => ln_wave=.true. & fill namsbc_wave) nn_sdrift = 0 ! Parameterization for the calculation of 3D-Stokes drift from the surface Stokes drift ! ! = 0 Breivik 2015 parameterization: v_z=v_0*[exp(2*k*z)/(1-8*k*z)] ! ! = 1 Phillips: v_z=v_o*[exp(2*k*z)-beta*sqrt(-2*k*pi*z)*erfc(sqrt(-2*k*z))] ! ! = 2 Phillips as (1) but using the wave frequency from a wave model ln_tauwoc = .false. ! Activate ocean stress modified by external wave induced stress (T => ln_wave=.true. & fill namsbc_wave) ln_tauw = .false. ! Activate ocean stress components from wave model ln_stcor = .false. ! Activate Stokes Coriolis term (T => ln_wave=.true. & ln_sdw=.true. & fill namsbc_wave) nn_lsm = 0 ! =0 land/sea mask for input fields is not applied (keep empty land/sea mask filename field) , ! =1:n number of iterations of land/sea mask application for input fields (fill land/sea mask filename field) }}} - create namisf, a "master" namelist for under-ice-shelf cavities. This namelist will regroup all ISF related control instead of the current spread of ISF control parameter throughout many namelists. - rename namtra_adv_mle ==>> namtra_mle to be consistent with eve name: namtra_eiv which are both associated with an extra advection for tracers. - namlbc : the current default is no slip, should it be a required choice (set by default a negative value: -9999 or, a probably better case, set it by default to free slip ? - namdyn_vor : add a ln_dynvor_noCOR option (user in TEST_CASES (overflow and lock exchange) [[BR]] '''All suggestions for improvements are welcome !''' These options are very interesting and seem to be contradictory with the work done by Andrew Coward, as decided during a previous System Tean VC see his message: {{{ Dear all, The changes at change set 9490 have introduced a lot of name list changes that have undone all the work I did at change set 9356 to align all the reference and configuration name lists; I.e.: r9356 | acc | 2018-02-23 17:32:30 +0000 (Fri, 23 Feb 2018) | 1 line Branch: 2017/dev_merge_2017. Cosmetic (hopefully) changes to namelist files to enforce more consistency between reference and configuration name lists. See new file: NEMOGCM/CONFIG/SHARED/README.namelists for the conventions used. For a brief period it was possible to do a simple side by side comparison of the reference and configuration name lists and have all the blocks line up. If no one else thinks this is useful then I'll give up the idea because it is too tedious to keep repeating that process if changes to name lists are not made incrementally with reference to the current head. Something to discuss at the next VC perhaps. -Andrew }}} Needs quite probably some discussion very soon.