technical modifications from HIRLAM


Suggested changes for cy40t1
Rimvydas Jasinkas, LHMI, Ulf Andrae SMHI


Updated 2014-03-17 (point 8)

  • Introduction
    The latest version of the code for HARMONIE based on the CY40 version of the IFS/ARPEGE code has gone through a first sanity check on some basic fortran and C standard violations.
    The IFS/ARPEGE code has a well defined coding standard described in Some of the rules there are very specific to this particular project whereas other norms are more generally applicable and considered a
    good coding standard in general. These latter rules are mainly defined in section four of the document but there are examples elsewhere as well. For example it’s stated that the code should be in free format,
    implicit none is mandatory and that tab character is not allowed. It’s clear from the suggested changes below that there are more than enough of examples of deviations from these rules in the code. The
    coding rules does not specify how to define, and undefine CPP flags and several of the changes deals with dangerous preprocessor constructions that may lead to unpredictable and unwanted result on
    different platforms. It’s unclear to us whether the other groups apply similar rules or not to their codes.
    The HARMONIE code is an example of a project where we utilize the knowledge of several groups in Europe, all with their different specialties. We lean on SURFEX for the surface modeling; from the
    MESO-NH group we use several packages for physical parameterization and The IFS/ARPEGE code is
    the backbone of the system with all the different components for e.g. numerics and data assimilation.
    The coordination of these different code bases is a challenge, but we hope that it is a win-win situation
    for everyone in the end. We understand that we should not try to impose coding rules on other projects.
    Still we believe that we all have to same goal; To arrive to a system that is fast, portable and
  1. CPP directives
    This change deals with cpp features. All are quite safe under normal compilation, but on optimized
    builds, that’s quite a different thing (safe programming practices with cpp for c codes). Cpp in fortran is
    not defined by fortran std, thus very unstable and vendor specific without any guarantee to be
    supported or rewritten for fortran semantic syntax (line continuation with ’&’, comments with ’!’). Also
    cpp was intended for case sensitive languages, since fortran is case sensitive just for string comparisons
    and together without implicit none could and already in few places create very hard to detect errors.
    Undefs are required to limit namespace breakouts to other blocks in extreme inlining mode (since cpp
    in fortran is only a vendor extension, cpp expansion step could be performed not in first stages).
  2. SURFEX CPP flags
    Mainly surfex define sanitation. Surfex CPP flags should be changed to
    This allows to have at least nice debug information with 1:1 identical source code and doesn’t conflict
    with fa/lfi structure names. SFX_ prefix was chosen in analogy to SFX_NETCDF define.
  3. SURFEX cleaning
    Feature proposal:
    Mainly replace outdated & very dirty [if/endif]++ and if/[elseif]++/else/endif with more cleaner and
    safer "select case" structures. This is more scalable, with cpp defines it preserves fortran std semantic
    syntax. Also, provides clear default action and error control. Moreover, gives idea how to keep such
    structures in same manner across different units.
    From low level point, this one counts as compile time optimization. Since compiler don’t have to guess
    about the flow. Better inlining and branching. From assembler level, this allows easy and fast creation
    of jump tables even for strings. Later if compiler is clever enough, it can partly fuse these jump tables,
    since they are constant type and put in .rodata data sections(easier code placement)
  4. Ascii and unicode symbols
    This is not fortran standard defined, vendor specific, better to avoid if possible. Lots of time wasted to
    understand what is " \206 " in string hex dumps. Problem with extended ascii symbols is that some
    editors can upconvert them to their utf-8/16 variants. Then not only fortran runtime is forced to work in
    full unicode mode, but can lead to non compatible/portable output files and multibyte encoding could
    be still interpreted as 7bit char stream, creating offsets in records. No cases in actual code (too much
    I/O), but inlined debug information with source code parts have some mangling.
  5. Detab
    Reason: tab character *is not* of fortran std character set. Behavior is not portable, depends on system,
    environment. Error with tabs are very hard to detect, usually creates problems when changing compiler
    vendors or even versions. Some optimization could be disabled just because compiler regex’es where
    not exten
  6. Free format and explicit kind declarations
    Conversion to universal free/fixed form (as long as everything is discarded after 72 column) , should be
    renamed to F90. Remark stabfunc2.h and impnone.h inlined thus can be removed. Manual indentation
    was performed in some places for readability) other packs were prepared in similar way.
    For portability reasons and for easier interfacing to other systems explicit kind declarations or all reals
    and integers is preferable.
  7. New suggestions concerning the use of modules to avoid generating extra interface blocksFree format and explicit kind declarations
    For each subroutine we today generate and extra interface routine module and make use of it all calling routines. If you would put the routines in modules directly the interface would be included implictly. To be consistent with the current "USE MODI_" statements we suggest to rename files from this_sub.F90 to modi_this_sub.F90

module modi_this_sub
subroutine this_sub
end module modi_this_sub

Further we suggest to rename files so that module/subroutine names are consistent. E.g. init_io_surfn.F90 -> modi_init_io_surf_n.F90

These changes would:

  • Cut compilable file list by half.
  • Simplifie makefile logics.
  • Make dependency analysis simpler.
  • Provide better diagnostics.

The suggested change would come with some cost:

  • An increased recompilation cost.
  • All subroutines will lose global visibility which is aimed at anyway in the suggested "remove global state" change but will require explicit use modi_NAME so not to get any undefined reference to NAME.
  • Some current explicit INTERFACE blocks has to be recoded.
  • Various build systems have to adapt to the new convention.

These changes will be included in SURFEX V8 by Rimvydas Jasinskas, in a mainly automatic way.

They could be included in SURFEX V8 at the end of the whole merging, in last-but-one position, just before the CERFACS contribution.

To make this inclusion easier, Rimvydas will test its changes (affecting a large part of the code) before the final inclusion in V8, on a previous version.