Changes between Version 9 and Version 10 of 2013WP/2013Stream1/Configuration_Setting
- Timestamp:
- 2013-02-07T16:27:34+01:00 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
2013WP/2013Stream1/Configuration_Setting
v9 v10 10 10 From a user point of view: 11 11 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 values12 • 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 13 13 14 14 From a developer point of view: 15 15 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. 17 17 18 == [[BR]]Proposed SOLUTION1 (Gurvan, 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...).18 == [[BR]]Proposed SOLUTION1 (Gurvan, december 2012): "3 namelists, 1 additional step" == 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...). 20 20 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]] 22 22 23 namelist == namelist_ref + namelist_cfg changes[[BR]] namelist_top == namelist_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 24 25 25 == Discussion (Claire) == … … 35 35 * 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 36 36 37 == Proposed SOLUTION2 (Claire, January 2013) ==37 == Proposed SOLUTION2 (Claire, January 2013) : "1 namelist, more initialisation in the code" == 38 38 Another way to look at the question: 39 39 … … 45 45 * in addition: using IOSTAT and ERR in the READ of the namelist, it is possible to manage properly not having a specific namelist at all in the small namelist file (when all default values are used), and typos in the namelist file 46 46 47 == Proposed SOLUTION3 (Claire, January 2013) ==48 If the idea of losing at least one complete namelist is unbearable, another solution (based on choices of SOLUTION1) could be i dentical to SOLUTION1 for the beginning:47 == Proposed SOLUTION3 (Claire, January 2013) "2 namelist, more READS in the code" == 48 If the idea of losing at least one complete namelist is unbearable, another solution (based on choices of SOLUTION1) could be imagined: 49 49 50 50 * a unique reference namelist (complete, with default values) in CONFIG/SHARED 51 51 * a small configuration-specific namelist in CONFIG/CONFIG_NAME/EXP00 containing only the modified values from the reference namelist 52 52 * no initialisation in the code (since reference namelist contains everything) 53 * reading a namelist now takes 2 steps (in the code): reading the reference namelist and reading afterwards the configuration-specific namelist which will overwrite the default values by the changed one53 * reading a namelist now takes 2 steps (in the code): reading the reference namelist and reading afterwards the configuration-specific namelist which will overwrite the default values by the changed one given in the configuration-specific 54 54 55 This allow having a complete namelist file (the unique reference namelist) but suppresses the additional merge-namelist step needed in SOLUTION155 This allows having a complete namelist file (the unique reference namelist) but suppresses the additional merge-namelist step needed in SOLUTION1 56 56 57 57 === Please add your comments and suggestions below … … 59 59 === Add your vote below 60 60 61 SOLUTION1 :[[BR]]SOLUTION2:[[BR]]SOLUTION3:[[BR]]???61 SOLUTION1 "3 namelists, 1 additional step":[[BR]]SOLUTION2 "1 namelist, more initialisation in the code":[[BR]]SOLUTION3 "2 namelist, more READS in the code"[[BR]]???
