New URL for NEMO forge!   http://forge.nemo-ocean.eu

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.
2013WP/2013Stream1/Configuration_Setting (diff) – NEMO

Changes between Version 5 and Version 6 of 2013WP/2013Stream1/Configuration_Setting


Ignore:
Timestamp:
2013-01-25T16:56:38+01:00 (11 years ago)
Author:
clevy
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 2013WP/2013Stream1/Configuration_Setting

    v5 v6  
    1010From a user point of view: 
    1111 
    12   • global domain sizes are FORTRAN parameters, not namelist parameters[[BR]]     • a namelist file in each configuration with all the variables (i.e. all the sub-namelist), not only the sub-namelist that depart from the default values 
     12  • global domain sizes are FORTRAN parameters, not namelist parameters[[BR]]      • a namelist file in each configuration with all the variables (i.e. all the sub-namelist), not only the sub-namelist that depart from the default values 
    1313 
    1414From a developer point of view: 
    1515 
    16   • the number of copies of the whole namelist (2 by configuration and an increasing number of reference configuration) make the change in namelist a nightmare[[BR]]     • default values of the namelist appear twice: 1) in the namelist itself and 2) in the code, distributed in the declaration phase of numerous modules[[BR]]     • global domain sizes (jpiglo, jpjglo, jpidta, jpjdta, jpkdta) are FORTRAN parameters, except in AGRIF case ==> almost as many par_XXX.h90 as the number of reference configurations ! [[BR]]     • in the code old namelist variables (i.e. with a non-doctor name) still survive ==> suppression is needed. 
     16  • the number of copies of the whole namelist (2 by configuration and an increasing number of reference configuration) make the change in namelist a nightmare[[BR]]      • default values of the namelist appear twice: 1) in the namelist itself and 2) in the code, distributed in the declaration phase of numerous modules[[BR]]      • global domain sizes (jpiglo, jpjglo, jpidta, jpjdta, jpkdta) are FORTRAN parameters, except in AGRIF case ==> almost as many par_XXX.h90 as the number of reference configurations ! [[BR]]      • in the code old namelist variables (i.e. with a non-doctor name) still survive ==> suppression is needed. 
    1717 
    18 == [[BR]]Proposed solution == 
    19   '''          I -'''           global domain sizes, configuration names, etc... (all the PARAMETER in par_oce.F90) defined in the namelist. Impact: suppression of all par_XXX.h90 files. Also suppression of all key_XXX associated to configurations (key_ORCA_RXXX, key_EEL_RXXX, key_GYRE, etc...). 
     18== [[BR]]Proposed SOLUTION1 (december 2012) == 
     19  '''           I -'''            global domain sizes, configuration names, etc... (all the PARAMETER in par_oce.F90) defined in the namelist. Impact: suppression of all par_XXX.h90 files. Also suppression of all key_XXX associated to configurations (key_ORCA_RXXX, key_EEL_RXXX, key_GYRE, etc...). 
    2020 
    21   '''          II -'''           namelist:[[BR]]                          • One single whole by medium (ocean, ice, top, ...: '''   namelist_ref'''   , namelist_ice_ref, name list_top_ref, ...) put at CONFIG/ level in read-only mode. This namelist contains the default values. The hard coded default values spread in the modules are suppressed (together with the surviving old non-doctor variables). [[BR]]                          • In each configuration the namelists of each medium contain only the changes associated with the configuration (the name may be '''   namelist_cfg'''   , namelist_cfg_top, etc...). A pearl script will be used to build the all the namelists that are required to run NEMO:   [[BR]] 
     21  '''           II -'''            namelist:[[BR]]                           • One single whole by medium (ocean, ice, top, ...: '''    namelist_ref'''    , namelist_ice_ref, name list_top_ref, ...) put at CONFIG/ level in read-only mode. This namelist contains the default values. The hard coded default values spread in the modules are suppressed (together with the surviving old non-doctor variables). [[BR]]                           • In each configuration the namelists of each medium contain only the changes associated with the configuration (the name may be '''    namelist_cfg'''    , namelist_cfg_top, etc...). A pearl script will be used to build the all the namelists that are required to run NEMO:   [[BR]] 
    2222 
    23     namelist == namlist_ref       + namelist_cfg        changes[[BR]]namelist_top == namlist_top_ref + namelist_top_cfg changes[[BR]]etc ... 
     23  namelist == namelist_ref       + namelist_cfg        changes[[BR]] namelist_top == namelist_top_ref + namelist_top_cfg changes[[BR]] etc ... 
     24 
     25== Discussion == 
     26Initialization of the variables 
     27 
     28  Up to now, these namelist variables are initialized twice: hard coded default values spread in the modules, and in the namelist file. Suppressing the hard coded initialisation opens possibility for no initialisation at all (if something is mispelled in the namelist for example). In that sense, removing the hard coded initialisation may be questionnable. 
     29 
     30SOLUTION1: some critics 
     31 
     32  The option is to have a unique complete reference namelist, and a smaller "configuration specific" on containing only the values changed from the reference namelist. This implies and additional step before execution: a merge of the 2 namelists (reference overwritten by specific) to build the third namelist, the one to be used at execution time. The perl script to do that is already written (sent by Marcello Vichi) I see to major defaults  with this solution: 
     33 * adding a new step in the execution process is an additional burden. We should look at it carefully before making such a choice. On a technical level, is it obvious that perl will be available on each computing platform? At a user level, it is one thing more not to forget, which cannot be automated neither at compilation (not the right place since namelist can be changed a number of time without changing executable) nor at execution (not an appropriate risk to take if crashes in a batch job) time 
     34 * once the new namelist is created (the first time), my guess is that users will change this "execution namelist" if needed, and not the "configuration" one, in order not to have to do ther merge namelist step again. Mainly this choice means that in order to be sure of what is done, user will have to check 3 namelists (rahter than 1): the reference, the configuration, and the execution one. This seems to be too much 
     35 
     36 
     37== Proposed SOLUTION2 == 
     38  Another way to look at the question: 
     39 * a default initialisation is left in the fortran code, in the module where the namelist variables are declared, used, with all the comments... 
     40 * a configuration namelist containing only the values departing from this default, is available in the CONFIG/CONFIG_NAME/EXP00 directory (like now, but a smaller one) 
     41 * no reference unique default namelist anymore, BUT 
     42 * a complete print of all namelist values is created at the first time step in a separate "output_namelist_xxx" file, aside from ocean.output, in order for the user to know exactly what is done in the run, and what are the values for all these namelist variables 
     43 * this suppresses the reference namelist, and above all the additionnal "merge namelist" step