Changes between Version 2 and Version 3 of user/gm/Namelist_framework

Timestamp:

2018-04-26T19:51:25+02:00 (6 years ago)

Author:

gm

Comment:

--

user/gm/Namelist_framework

@@ -1 +1 @@
 
-== Namelist framework description ==
+== Namelist framework proposition ==
 
- 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.
+This page is an attempt to provide a proposed general philosophy behind the namelist_ref structure and what should appear in namelist_cfg. It also suggests some improvements to the current namelist.
+
+From a NEMO System Team perspective, the main objectif is to reduce drastically the duplication of sub-namelist in the namelist_cfg file for the standard configurations and test cases, and therefore facilitate namelist changes. 
+
+From a user perspective, the main objective is to have a configuration namelist where : (1) all key choices appear, and (2) on which choices they willingly rely on the default reference namelist. Note that users that want all the namelist choices available in the namelist_cfg can still just copy the reference namelist and modify it.
+
+If adopted, such a description should probably appear in the DOC as well as in the system team and user wiki pages. 
+
+[[BR]]
+
 
 
 === 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 :
+The ocean namelist contains 10 sections :
+{{{
+!! NEMO/OPA  :  1 - Domain & run manager (namrun, namcfg, namdom, namtsd, namcrs, namc1d, namc1d_uvd)
+!! namelists    2 - Surface boundary (namsbc, namsbc_flx, namsbc_blk, namsbc_cpl,
+!!                                    namsbc_sas, namtra_qsr, namsbc_rnf,
+!!                                    namsbc_isf, namsbc_iscpl, namsbc_apr, 
+!!                                    namsbc_ssr, namsbc_wave, namberg)
+!!              3 - lateral boundary (namlbc, namagrif, nambdy, nambdy_tide)
+!!              4 - top/bot boundary (namdrg, namdrg_top, namdrg_bot, nambbc, nambbl)
+!!              5 - Tracer           (nameos, namtra_adv, namtra_ldf, namtra_eiv, namtra_dmp)
+!!              6 - dynamics         (namdyn_adv, namdyn_vor, namdyn_hpg, namdyn_spg, namdyn_ldf)
+!!              7 - Vertical physics (namzdf, namzdf_ric, namzdf_tke, namzdf_gls, namzdf_iwm)
+!!              8 - diagnostics      (namnc4, namtrd, namspr, namflo, namhsb)
+!!              9 - Obs & Assim      (namobs, nam_asminc)
+!!             10 - miscellaneous    (nammpp, namctl, namsto)
+}}}
+
+
+There is three type of namelist :  (1) "manager"  ;  (2) "associate manager"  ;  and (3) "specific".
+     (1) "manager" namelist : it is required in all user configuration. It 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 :
 {{{
 !-----------------------------------------------------------------------
@@ -16 +42 @@
 }}}
     
-     (2)  "associate manager" namelist : are activated 
+     (2)  "associate manager" namelist : It is read only if its associated flag (ln_xxxyyy) appearing in its father "manager" namelist is set to true. It contains reasonable default value that user may overwrite in namelist_cfg.  Such a namelist is characterized by  a " (ln_xxxyyy =T) " comment at the end of their opening line :
+{{{
+!-----------------------------------------------------------------------
+&namXXX     !   sort description                                        (ln_xxxyyy =T)
+!-----------------------------------------------------------------------
+}}}
+
+     (3) "specific" namelist : they are associated with a pure optional feature (ocean parametrization such as namtra_eiv, naltra_mle, etc.) or option that does not change the the model trajectory (diagnostics, print control, etc.).  They contains their own control switch (the first variable given in the namelist) and its default value is always FALSE. Such a type of namelist is characterized by  a " (default: NO) " comment at the end of their opening line :
+{{{
+!-----------------------------------------------------------------------
+&namXXX     !   sort description                                        (default: NO)
+!-----------------------------------------------------------------------
+}}}
+
+[[BR]]
 
 
-     (3) "specific" namlists (i.e. independent namelists).
+Note that two other setting of these 3 types of namelist may be adopted to add a better visual identification :
+{{{
+!! manager namelist
+!-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-=
+&namXXX        !   short description                                    (default: NO selection)
+!-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-=
 
-   - Set all .
+!! assistant manager
+!-=--=--=--=--=--=--=--=--=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+&namXXX        !   short description                                    (ln_xxxyyy =T)
+!-=--=--=--=--=--=--=--=--=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
+
+!! specific namelist 
+!-----------------------------------------------------------------------
+&namXXX        !   short description                                    (default: NO)
+!-----------------------------------------------------------------------
+}}}
+or 
+{{{
+!-== == == == == == == == == == == == == == == == == == == == == == == =
+&namXXX        !   short description                                    (default: NO selection)
+!-== == == == == == == == == == == == == == == == == == == == == == == =
+
+!! assistant manager
+!--= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
+&namXXX        !   short description                                    (ln_xxxyyy =T)
+!--= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
+
+!! specific namelist 
+!-----------------------------------------------------------------------
+&namXXX        !   short description                                    (default: NO)
+!-----------------------------------------------------------------------
+}}}
+
+[[BR]]
+
+   Note also that the I'm not very found of the tags :
+      "default: NO selection" ; "ln_xxxyyy =T" ; and "default: NO"
+   For example, they can be be :
+      "default: REQUIRE selection" ; "used IF ln_xxxyyy =T" ; and "default: NOT used"
+   or any other clever suggestion.
+
+[[BR]]
+
 
 
 === configuration namelist : ===
+This namelist aims to overwrite the reference namelist values. The way its is set in all configurations and test cases provides in the down in the NEMOGCM/CONFIG directory is the following : It have to contain the namelist :
 
+      (0) all the header of 10 sections of the ocean namelist, listing all the section namelist that are relevant for the configuration (e.g. C1D namelist description line will only appears in the C1D_PAPA configuration.
 
+      (1) In addition to namdom and namrun, ALL the "manager" namelist:  By definition all "manager namelist require to switch at least on namelist logical from FALSE to TRUE.
+
+      (2) only the "associate manager" namelist for which  the two conditions are satisfied:  -1- its manager  namelist logical equal TRUE  ; and -2- the default reference values that has been modified.
+
+      (3) only "specific" namelist for which the user have chosen to set to TRUE its control switch. In the case only the other namelist option that has been changed compare to the reference will appear.
+[[BR]]
 
 
@@ -32 +121 @@
 === 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).
+- No more ORCA2 specific choices in namelist_ref.
+- generalize the notion of "manager", "associate manager" and "specific" namelists
+- add the possibility of having (in the solved Primitive Equation) NO trend  in tracer or momentum advection and/or lateral mixing, Coriolis, …  
+- set to false all option in "manager" namelists, switch off all switches that , except in so called "associated manager" namelists  .
+- change to a dummy name all name and/or weight fields that need to be read in a NetCDF file. 
 
   
 
-'''things to be improved :''' 
+=== things to be improved & questions : ===
 - move in  namsbc_wave namelist all the wave related variable that are in namsbc except ln_wave switch, that is: 
 {{{
@@ -55 +147 @@
 - 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)
+- namdyn_vor : add a ln_dynvor_noCOR option (used in some TEST_CASES (overflow and lock exchange)
+- move ln_icebergs from namberg to namsbc namelist (affect the surface ocean boundary condition, should be a "associate manager" namelist 
+- nam_tide should it be an "associate manager" namelist ??
 [[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.:
+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. 
+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. 
+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 
+namelists 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.
 
-Needs quite probably some discussion very soon.
+   Claire.
+
+
+gurvan: Yes indeed, didn't saw that such an action was ongoing. I have contacted Andrew.