OpenRadioss Coding Recommendations

Coding Style

Use uppercase for all Fortran instructions, variable names

Use lowercase for pre-compiler directives

Comments should be written in English only (uppercase & lowercase accepted)

Tabulations are forbidden (to be replaced by spaces at the beginning of line)

Use meaningful names for variables, in English, keep the same name throughout the code

Systematically indent your blocks (IF/END IF, DO/END DO, ...) in a homogeneous way for clarity of the code

In case of long IF/ELSE/END IF block, it is recommended to add comment like below: 

   IF (A==0) THEN !        my long block !        ...        ELSE ! A/=0 !        my second long block !        ...        END IF

Routine & file organisation

By default, one file contains only one subroutine or function, except when the understanding of the code is facilitated by grouping few procedures

The same rule applies for modules: one module per file, same name

For module several subroutines can be defined under the CONTAINS close

Header definition

Each source file should have the copyright notice

Each procedure needs to have a conforming header, containing by order of appearance:

  • A minimal description of the routine

  • The list of caller subroutines/functions

  • The list of called subroutines/functions

  • The SUBROUTINE/FUNCTION declaration with the list of dummy arguments, 5 per line, matching the call declaration

  • The used modules

  • The implicit_f.inc (IMPLICIT NONE)

  • The optional remaining global parameters and commons if any (for compatibility with the past)

  • The list of dummy arguments, one per line with its type, INTENT attribute, explicit bounds in case of array, a short description of the variable

  • The local variables

  • The source code

Notes:

  1. The list of callers/callees is automatically generated

  2. implicit_f.inc must always be included. It automatically includes IMPLICIT NONE instruction, the definition of my_real (as REAL*8 for double precision or REAL*4 for single precision) and constant.inc which defines numerical constant variables like ZERO here

  3. Explicit bounds of all arrays are mandatory; the use of “*" is now forbidden for clarity

Example:

INTEGER IPARG(60, *)          Forbidden

INTEGER IPARG(NPARG, NGROUP)  Authorized

Comments

It is important to comment algorithms, especially when non straightforward coding is used

Comments are written in English

Comments respect Fortran90 standard. The use of "!" at beginning of line is preferred to "C" or "*"

Except for preprocessor directives, the following characters ',", \, /*, */, # are forbidden, even inside comments. Especially "\" is dangerous as it is interpreted as a continuation line by the preprocessor

 Example:

! this is a legal comment   A = A + B ! this one is also authorized in FORTRAN 90   C = A + C ! next instruction ignored cause of this char \       D = C + D

Modules

Module Format

Generic format of a Fortran90 module is as follows:     

MODULE <module name> USE [other module list] #include "implicit_f.inc"   <declaration section>   CONTAINS   <procedure definitions> END MODULE <module name>

Naming Convention 

Module name is defined as follows: MODULENAME_MOD

With module file name: modulename_mod.F

Module file is placed at the same location as other files used by the option

Restart Variables

All the variables communicated between Starter and Engine are declared in module RESTART_MOD, used by subroutine ARRALLOC for their allocation, by RDRESB for their reading from RESTART file, then by RESOL_HEAD in which they are used as argument for RESOL subroutine. All these argument variables are then passed by argument to procedures called from RESOL, ...)

Interface definition

Fortran90 interface allows the compiler to do additional checks like coherency between argument types, attributes and number between calling and callee routines. It is required in some cases like when a procedure has a dummy argument with attribute ALLOCATABLE, POINTER, TARGET

In practice, it was introduced in few places of the code for routines which were called at several different places

Such coherency is automatically tested by QA static analysis tools (Forcheck).

And for pointer, good practice is to use derived data types instead of pointer directly

Therefore, the remaining use of interface is regarding routine with optional arguments

This feature should be spread in the code instead of adding additional “dummy” arguments

Memory Allocation

 Related articles

OpenRadioss Coding Standards

OpenRadioss Performance Aspects: Vectorization and Optimization

OpenRadioss Reader (Radioss Block Format)

OpenRadioss HMPP Development Insights