Suppression of global variables from CERFACS

Contains:

2 main parts:

  • Automatic scripts (with a manual part) are used to transform the SURFEX code to suppress global variables.
  • So that these scripts are able to run on the SURFEX code, some "normalizations" need to be performed.

=> These normalizations constitute the first part of the work, the transformation with the automatic scripts the second one.

The first part contains :

  • Split 5 modules modd_* defining several TYPE to modules defining only one TYPE (109 files)
  • Syntax corrections (4 files)
  • Defined a new TYPE in modd_pack* files (3files)
  • Use of new TYPE from modd_pack* (4 files)
  • Shortened lines to avoid too long lines with prefixvar (3 files)
  • Delete useless lines USE MODD_* (9 files)
  • Delete space for ftagshtml (2 files)
  • Add IMPLICIT NONE (1 file)
  • Delete IMPLICIT NONE and comments in the interface (1 file)
  • Move line USE MODD_ in subroutine INIT_CRODEBUG (1 file)
  • Change locale variable I in JI (1 file)
In order to make easier the work of Gabriel for the merging of the first part of the transformation, some specific recommendations intended for the developers and mergers are released. Please read them carefully before to begin your merging step:
  • If a new module MODD_xxx is created, respect the writing formalism: 1 sole TYPE defined, same comments, same calls to DR_HOOK and keep the test on LKFROM.
  • if a lign USE MODULE is added in a routine: verify it doesn’t exist yet.
  • if a variable is added on a lign: USE MODULE, ONLY : list-variables: verify this variable isn’t in the list-variables yet.
  • don’t name I a local integer variable (JI ou JJ for loop indexes).
  • do not set a blank between CALL routine-name and the opening parenthesis (, because then the call isn’t taken into account by the tool ftagshtml describing the call tree => stick the parenthesis.
  • don’t use the same names for routines in CONTAINS in different files. Bad example: the private subroutine TREAT_SURF exists in 7 different files.
  • Avoid long lines that are almost 132 fateful characters for Fortran90. Be <≈100 characters because the add of prefixes to variables of modules increases the length of lines.

This contribution is very transverse but also automatic in a large extent. So, it will be included at last by G. Jonville.

It’s foreseen to be done around August/September 2014. This due date is already fixed and constitutes a limitation for all the other developments that have to be merged before this one.

However, it’s very important that other mergers respect as far as possible upper recommendations.

Also in this section