Reminder of the general recommendations to mergers

See 3) for special recommendations for the automatic transformation !!

– RULES OF CODING:

  1. The basis recommendations for the names of variables are found in the DOCTOR norm. To be noted that the line PARAMETER concerns local parameters. Parameters defined in modules are driven by the line global or MODULE.
  2. In general terms, rules listed here should be respected.
  3. Some specific advises are linked to the suppression of global variables (see article315). These advises are listed here.
  4. DON’T FORGET TO COMMENT YOUR CHANGES !

– WHAT IS ASKED TO EACH CONTRIBUTOR:

------- 1. To merge, locally, its contribution with the version coming from the previous merger, following coding rules described above. This means that the merger has to download the SURFEX_V9_DEV branch on the GIT repository, and merge its contribution on this branch.
The developments will be first merged locally only. The definitive integration of the developments in the SURFEX_V9_DEV branch will be possible at the end only, when all of the following steps will be done.

------- 2. To run the base of automatic tests (STRATO) between the SURFEX_V9_DEV before your contribution, and the version including your contribution. (Documentation here)

  • 2.1 To analyse outputs of STRATO. This means to be able to explain all differences obtained.
  • 2.2 Consequently to correct the code and your contribution if necessary.
  • 2.3 To provide us the outputs of the last run of STRATO (all files in STRATO/TESTS/PYTHON/results/)
  • 2.4 To provide us a document explaining differences in results observed

------- 3. To update STRATO with test cases associated to new options, new keys, added in SURFEX. If the contribution includes new keys or new values for a key, a new test has to be created, in order to test this new key. In the same way, if a value for a key is removed, please also remove the tests associated to this option. So, the next contributor will run a base of tests, with test including your new keys or options. To update STRATO allows to give a new version of STRATO to the next merger, adapted to your contribution.

------- 4. To provide us with a complete documentation

  • 4.1 A scientific documentation of your contribution (as already done by some contributors example1 or example2)
  • 4.2 A technical documentation, indicating new namelists, new keys, new values for a key, values deleted, keys deleted, default values, changes in default values, etc... An example here

------- 5. To merge the contribution on the SURFEX_V9_DEV branch : When all of the previous steps will have been realised, write permissions will be given on the SURFEX_V9_DEV branch, and the contributor will be able to push its contribution on the GIT repository.

– SPECIAL RECOMMENDATION FOR V8 :

Objective: Limit special cases coding in SURFEX V8 in order to facilitate the removal of global variables by automatic transformation.

  • In case of the development of a new " MODD_xxx " module, observe the same "formalism" of writing: one definition TYPE , same comments , same calls DR_HOOK and keep the test LKFROM .
  • If a " USE MODULE " in a routine online : check that this line does not already exist .
  • If adding a variable on a line " USE MODULE ONLY :: list - variables ’ verify that this variable is not already there
  • do not name an integer local variable "I" (JI or JJ for loop variables ) .
  • Do not put a blank between " CALL routine -name " and the opening parenthesis " ( " because the call is not taken into account by the ftagshtml tool describing the call tree : stick the parenthesis .
  • Do not use the same name for CONTAINS routines in different files. Bad example: private TREAT_SURF subroutine exists in 7 different files.
  • Avoid the long lines that approximate 132 characters limitl for Fortran90 : stay around 100 characters because prefixing variables of modules increases the length of the line.

Also in this section