OpenRadioss Coding Recommendations
- Paul Sharp
- Eric Lequiniou
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 declarationThe 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 variableThe local variables
The source code
Notes:
The list of callers/callees is automatically generated
implicit_f.inc
must always be included. It automatically includesIMPLICIT NONE
instruction, the definition ofmy_real
(asREAL*8
for double precision orREAL*4
for single precision) and constant.inc which defines numerical constant variables likeZERO
hereExplicit 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 Performance Aspects: Vectorization and Optimization