General rules for good programming

Header in every routine

Each routine should start with a header. This header (comments) should contain following information:
  1. brief description of what is done in this routine
  2. parent-routine (which routine calls this function)
  3. information of major changes, the responsible developer and the date of modification
    The header should be formatted as follows:
    subroutine set_tracer_position()
      ! This routine is used to set the initial position of the tracer
      ! Called from celset (setup.F90)
      ! Description                                   Programmer      Date
      ! ------------------------------------------------------------------
      ! Original version..................................DE    2007-10-25

Passing arguments to functions and subroutines

Every argument of a routine must be clearly declared by
  1. using intent statements to declare how the argument is used:
    1. intent(in) : argument is just submitted to the routine; this value will not be modified by the routine
    2. intent(out) : argument is initialized by the routine and submitted to the parent-routine.
    3. indent(inout): combination of both

Furthermore, every argument should be briefly described - if possible in the same line where it is declared, e.g.:

subroutine place_spheroid(mid,rad,objid,prior,num,matc)
  use ptool_interface
  use mod_isale, only : nx,ny,nz
  implicit none
  real*8,  intent(in)    :: mid(1:3)             ! midpoint of spheroid
  real*8,  intent(in)    :: rad(1:3)             ! radius of spheroid
  integer, intent(in)    :: objid                ! object ID assigned to cells
  integer, intent(in)    :: num                  ! upper bound of 'prior'
  integer, intent(in)    :: prior(1:num)         ! priority list
  integer, intent(inout) :: matc(1:nx,1:ny,1:nz) ! array of object ID's

Notation for comments

Use comments whenever possible. If you want to show that a specific comment is made by you, you should add your initials right after the '!', e.g.

!DE we might rearrange this routine later to obtain better performance

Critical comments (mostly used as reminder for developers) should start with 'relic' to ease identification of 'critical' parts in the code, e.g.
!DErelic note that these parameters are hardcoded - move them into asteroid.inp later...

Use interfaces or interface-procedures whenever possible

Avoid antiquated f77-features

  1. equivalence-statements
  2. goto constructs

Advices for platform- and compiler-dependent developments (differences between gfortran-, ifort- and g95-syntax)

General notation convention

Variables are always lower case, constants are always uppercase (this means also variables treated as constants).

Important variables used in both codes

i index in x-direction
j index in y-direction
k index in z-direction (not used in 2D to avoid confusion)
l index of material
m material ID
cc pointer to current cell (cc=>cell(i,j,k))
mm pointer to current material (mm=>mat(m))
oo pointer to current object (e.g. projectile, oo=>obj(1))
ll pointer to current layer-structure (ll=>lay(1))

Mesh indices and domain decomposition parameters

nx,ny,nz number of cells in x/y/z-direction (outdated; better use n(X),n(Y),n(z) instead)
nxp,nyp,nzp number of grid points in each direction (=nx+1,ny+1,nz+1)
is,js,ks start of local grid (domain dependent; =1 for serial jobs)
ie,je,ke end of local grid (domain dependent; =nxp,nyp,nzp for serial jobs)
ipe,jpe,kpe end of local grid including ghostpoints (domain dependent)