Changes between Version 4 and Version 5 of 2016WP/Simplif2-CNRS-simona
- Timestamp:
- 2016-03-11T14:17:17+01:00 (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
2016WP/Simplif2-CNRS-simona
v4 v5 1 1 = Form page for development work = 2 A wiki page associated with a give action should be created in `wiki/${YEAR}WP/${WORKING_GROUP|INSTITUTE}-${ACTION_NUMBER}_${PI}` using this template.[[BR]] From that, you can customize it while editing within the !TracForm container `{{{#!TracForm ... }}}`. If necessary, you can copy the entire form (add a number `_[0-9]` to wiki page name) or the respective area in order to match the number of the (P)Reviewer(s). The best solution is not to extend significantly the length of the page. 2 3 3 A wiki page associated with a give action should be created in `wiki/${YEAR}WP/${WORKING_GROUP|INSTITUTE}-${ACTION_NUMBER}_${PI}` using this template.[[BR]] 4 From that, you can customize it while editing within the !TracForm container `{{{#!TracForm ... }}}`. If necessary, you can copy the entire form (add a number `_[0-9]` to wiki page name) or the respective area in order to match the number of the (P)Reviewer(s). 5 The best solution is not to extend significantly the length of the page. 6 7 This is the color code for the fulfilment of this form: 8 {{{#!td style="background:lightgrey" 9 PI(S) 10 }}} 11 {{{#!td style="background:lightblue" 12 Previewer(s) 13 }}} 14 {{{#!td style="background:lightgreen" 15 Reviewer(s) 16 }}} 4 This is the color code for the fulfilment of this form: {{{#!td style="background:lightgrey" PI(S) }}} {{{#!td style="background:lightblue" Previewer(s) }}} {{{#!td style="background:lightgreen" Reviewer(s) }}} 17 5 18 6 ---- 19 20 7 The PI is responsible to closely follow the progress of the action, and especially to contact NEMO project manager if the delay on preview (or review) are longer than the 2 weeks expected.[[BR]] 21 8 22 9 [[PageOutline(2)]] 10 23 11 == Abstract == 24 This section should be completed before starting to develop the code, in order to find agreement on the method beforehand.[[BR]] 25 '''To enabling the !ticket and the source links in the Trac environment, those have to be hardcoded in the form''' 12 This section should be completed before starting to develop the code, in order to find agreement on the method beforehand.[[BR]] '''To enabling the !ticket and the source links in the Trac environment, those have to be hardcoded in the form''' 13 26 14 {{{ 27 15 #!TracForm … … 34 22 }}} 35 23 || ''[tf.input:pi -id=piform 'Names' 100]'' || 36 |- 37 {{{#!td align=left 38 Ticket 39 }}} 40 {{{#!td style="background:lightgrey" 41 `#XXXX` 42 }}} 43 |- 44 {{{#!td align=left 45 Branch 46 }}} 47 {{{#!td style="background:lightgrey" 48 `[source:/branches/$YEAR/dev_r${FORK_REVISION}_${WORKING_GROUP|INSTITUTE}${ACTION_NUMBER}_${PURPOSE}]`'' 49 }}} 50 |- 51 {{{#!td style="background-color:lightblue" 52 Previewer(s) 53 }}} 24 25 |- {{{#!td align=left Ticket }}} {{{#!td style="background:lightgrey" `#1692` }}} |- {{{#!td align=left Branch }}} {{{#!td style="background:lightgrey" `[source:/branches/$YEAR/dev_r${FORK_REVISION}_${WORKING_GROUP|INSTITUTE}${ACTION_NUMBER}_${PURPOSE}]`'' }}} |- {{{#!td style="background-color:lightblue" Previewer(s) }}}'' 26 54 27 || ''[tf.input:previewers -id=piform 'Names' 100]'' || 55 {{{#!td style="background-color:lightgreen" 56 Reviewer(s) 57 }}} 28 29 {{{#!td style="background-color:lightgreen" Reviewer(s) }}} 30 58 31 || ''[tf.input:reviewers -id=piform 'Names' 100]'' || 32 59 33 === Part 1: Description === 60 34 [tf.textarea:description -id=piform 'Describe the goal of development, and the methodology.\n\nAdd reference documents or publications if relevant.' 200 20] 35 61 36 === Part 2: Implementation === 62 37 [tf.textarea:implementation -id=piform 'Describe flow chart of the changes in the code.\n\nList the .F90 files and modules to be changed.\n\nDetailed list of new variables (including namelists) to be defined.\nGive for each the chosen name (following coding rules) and definition.' 200 20] 38 63 39 === Part 3: Reference manual updates === 64 40 [tf.textarea:manual -id=piform 'Using part 1 and 2, define the summary of changes to be done in the NEMO reference manual (tex files).' 200 20] 41 65 42 ==== ''Updated on [tf.form_updated_on:] by [tf.form_updater:]'' ==== 66 }}} 67 Once the PI has completed this section, he should send a mail to the previewer(s) asking them to preview the work within two weeks. 43 }}} Once the PI has completed this section, he should send a mail to the previewer(s) asking them to preview the work within two weeks. 68 44 69 ---- --------------------------------------------------------------45 ---- 70 46 = Jointly Agreed Plan (in discussion with previewer) = 71 The goal of this action is to continue Simplification started with ticket 1608, and 72 https://forge.ipsl.jussieu.fr/nemo/wiki/ticket/1593_CNRS9_NOC3_LDF. For this action we 73 will re-define interface between NEMO core and configurations and update all reference 74 documentation to reflect the changes made. 47 The goal of this action is to continue Simplification started with ticket 1608, and https://forge.ipsl.jussieu.fr/nemo/wiki/ticket/1593_CNRS9_NOC3_LDF. For this action we will re-define interface between NEMO core and configurations and update all reference documentation to reflect the changes made. 75 48 76 49 Configuration dependent code can be considered in four functional groups: 77 50 78 1. Domain setting79 2. Initial state80 3. Forcing 81 4. Physics51 1. Domain setting 52 1. Initial state 53 1. Forcing 54 1. Physics 82 55 83 56 === Phase 1: === 84 85 86 The first phase is to create a GYRE configuration which has no configuration dependent 87 code in the standard modules. This will be achieved by moving code in each of the 88 functional groups (where appropriate) into 'user defined' modules which can be dropped 89 into a MY_SRC directory and which are called by generic function names. Calls to these 90 generic routines should be placed at appropriate points to be activated by suitable 91 namelist switches. In the GYRE case this will involve relocating the following code 92 segments: 57 The first phase is to create a GYRE configuration which has no configuration dependent code in the standard modules. This will be achieved by moving code in each of the functional groups (where appropriate) into 'user defined' modules which can be dropped into a MY_SRC directory and which are called by generic function names. Calls to these generic routines should be placed at appropriate points to be activated by suitable namelist switches. In the GYRE case this will involve relocating the following code segments: 93 58 94 59 {{{ … … 99 64 (Physics): None 100 65 }}} 101 102 Remove specific calls to *_gyre routines and verify results using the 'user defined' 103 routines 66 Remove specific calls to *_gyre routines and verify results using the 'user defined' routines 104 67 105 68 === Phase 2: === 106 107 The second phase of this task is to introduce a method of reading all domain settings from 108 external files. Currently this is done for horizontal grid information if jphgr_msh=0 but 109 there is no similar mechanism for the vertical grid. For a complete domain description 110 (ignoring the possibility of iceshelves, for now) the following data are required: 111 69 The second phase of this task is to introduce a method of reading all domain settings from external files. Currently this is done for horizontal grid information if jphgr_msh=0 but there is no similar mechanism for the vertical grid. For a complete domain description (ignoring the possibility of iceshelves, for now) the following data are required: 112 70 113 71 {{{ … … 118 76 jperio, ln_zps, ln_zco, ln_sco, ln_isfcav 119 77 }}} 78 Note [u,v,f]masks can be derived from tmask. A configuration-dependent fmask, in particular, should be considered as a physics choice since it can be used to increase lateral friction. 120 79 121 122 Note [u,v,f]masks can be derived from tmask. A configuration-dependent fmask, in 123 particular, should be considered as a physics choice since it can be used to increase 124 lateral friction. 125 126 The phase 2 task is therefore to introduce code to produce a mesh and mask file with all 127 the required content (by changing/adding to nn_msh options). A new namelist parameter can 128 then be added (jpzgr_msh) such that when jpzgr_msh = 0, a new routine, zgr_read, called 129 in domzgr will read the vertical grid information from the mesh and mask file: 80 The phase 2 task is therefore to introduce code to produce a mesh and mask file with all the required content (by changing/adding to nn_msh options). A new namelist parameter can then be added (jpzgr_msh) such that when jpzgr_msh = 0, a new routine, zgr_read, called in domzgr will read the vertical grid information from the mesh and mask file: 130 81 131 82 {{{ … … 161 112 CALL zgr_top_level ! shallowest ocean level for T-, U-, V- points 162 113 }}} 114 Note: The same domain file read in zgr_read is also to be accessed in hgr_read for the horizontal grid information (jphgr_msh=0). 163 115 164 Note: The same domain file read in zgr_read is also to be accessed in hgr_read for the 165 horizontal grid information (jphgr_msh=0). 166 167 The ability to reproduce results from all reference configurations using the external 168 files to define the domain should be verified at this stage. 116 The ability to reproduce results from all reference configurations using the external files to define the domain should be verified at this stage. 169 117 170 118 === Phase 3: === 119 The third phase will be to identify configuration dependent physics code and replicate the functions (or case statement blocks) either by providing user defined functions or reading appropriate fields from external files. The afore-mentioned fmask modifications are one example which could be replaced by reading a modified fmask from an external file. 171 120 172 173 The third phase will be to identify configuration dependent physics code and replicate the 174 functions (or case statement blocks) either by providing user defined functions or reading 175 appropriate fields from external files. The afore-mentioned fmask modifications are one 176 example which could be replaced by reading a modified fmask from an external file. 177 178 After this phase it should be possible to run an ORCA2 configuration with no hardcoded 179 references in the trunk code. 121 After this phase it should be possible to run an ORCA2 configuration with no hardcoded references in the trunk code. 180 122 181 123 === Phase 4: === 182 183 Following success with phases 1-3 the next stage will be to systematically break down the 184 multiple functionality in routines such as domhgr into separate examples of user-defined 185 routines (in this case a set of routines, each of which sets a different vertical grid). 186 Care should be taken to standardise subroutine arguments with inputs and return fields 187 clearly documented. These new routines should be moved into the appropriate MY_SRC 188 directory of a reference configuration or into a new directory under TOOLS or 189 MISCELLANEOUS if they are not actively used in any of the reference configurations. 190 domhgr.F90 and domzgr.F90, in particular, should be greatly simplified by this procedure. 124 Following success with phases 1-3 the next stage will be to systematically break down the multiple functionality in routines such as domhgr into separate examples of user-defined routines (in this case a set of routines, each of which sets a different vertical grid). Care should be taken to standardise subroutine arguments with inputs and return fields clearly documented. These new routines should be moved into the appropriate MY_SRC directory of a reference configuration or into a new directory under TOOLS or MISCELLANEOUS if they are not actively used in any of the reference configurations. domhgr.F90 and domzgr.F90, in particular, should be greatly simplified by this procedure. 191 125 192 126 === Phase 5 === 193 194 Incorporate necessary additions to the domain.nc file to support ISF active configurations 195 (misfdep, risfdep?) and check for possible redundancy in domain.nc (i.e. are all the 196 fields really required?). Not sure _1d arrays are, for example? 127 Incorporate necessary additions to the domain.nc file to support ISF active configurations (misfdep, risfdep?) and check for possible redundancy in domain.nc (i.e. are all the fields really required?). Not sure _1d arrays are, for example? 197 128 198 129 Finally check that documentation has been kept up to date.
