Fortran 90 Coding Policy by IGv7Td


									The following rules must be adhered to in making changes in GAMESS.
 These rules are important in maintaining portability and stability. Code
that does not follow these rules will not be permitted in GAMESS. There
will be no exceptions.

Golden Rule: make sure your code not only has no compiler errors (try
as many compilers as possible), but that it also has no FTNCHEK
diagnostics. FTNCHEK and an updated version for Fortran 90 by Robert
Moniot are a fantastic static analyzer, and only code that passes will be
accepted into GAMESS. You will make everyone’s lives easier by
performing these checks BEFORE submittal to GAMESS

Silver Rule: All code submissions and revisions tracking will be done
using the Git repository. Information on how to install and use this
system can be found here:

Rule 1. If there is a way to write code that works on all computers, write
it that way. Putting in preprocessor statements for different types of
computers should be your last resort. If it is necessary to add lines that
are specific to one computer, put in code for all other supported
machines. If you don't have access to all of the types of supported
hardware, you can look at the other machine specific examples found in
GAMESS, or ask for help from someone who does understand the
various architectures. If a module does not already contain some
machine specific statements, be especially reluctant to introduce

Rule 2. Write a double precision program, and let the preprocessor
handle any conversion to single precision, when that is necessary:
       a) Use Implicit none. Using Implicit Double Precision (A-H, O-Z)
specification statements is allowed (temporarily) only for existing code,
but is not allowed for new code. Real*8 should not be used and Integer
is just Integer.
       b) Floating point constants given using scientific notation should
be entered as a number with a decimal point, a number after the
decimal, a "D", and a 2 digit exponent. Example 1.23D+01
       c) Double precision BLAS names are used throughout, for example
DDOT instead of SDOT, and DGEMM instead of SGEMM.

Rule 3. Fortran allows for generic functions. Thus the routine SQRT
should be used in place of DSQRT, as this will automatically be given the
correct precision by the compilers. Use ABS, COS, INT, etc. Your
compiler manual will tell you all the generic names.

Rule 4. Every routine in GAMESS begins with a line containing the name
of the module and the routine. An example is "!*MODULE xxxxxx *DECK
yyyyyyy". Here xxxxxx is the name of the module and yyyyyyy is the
name of the routine. This rule makes it easier to read and maneuver
around the GAMESS code for everyone.

Rule 5. Whenever a change is made to a module, this should be
recorded in the Git change log included with the submitted code. The
change should not be recorded at the top of the file as was previously

Rule 6. Do not use tab to indent. Instead, each new layer of embedding
should be indented with 4 spaces. Free form formatting should be used
but lines should extend no further than the 80th column to maintain

Rule 7. Stick to the Fortran naming convention for integer (I-N) and
floating point variables (A-H,O-Z) whenever possible to maintain

Rule 8. Always ensure that allocated arrays are deallocated properly
and avoid allocations within a loop whenever possible.

Rule 9. GOTO statements are to be replaced with one of the many newer
structures available in Fortran 90, such as DO loops or CASE statements.
 Labels for DO loops can be included, but are not required.
Rule 10. All open, rewind, and close operations on sequential files must
be performed with the subroutines SEQOPN, SEQREW, and SEQCLO
respectively. You can find these routines in IOLIB; they are easy to use.
 SQREAD, SQWRIT, and various integral I/O routines like PREAD are
used to process the contents of such files. The variable DSKWRK tells if
you are processing a distributed file (one split between all compute
processes, DSKWRK=.TRUE.) or a single file on the master process
(DSKWRK=.FALSE., resulting in broadcasts of the data from the master
to all other CPUs).

Rule 11. All READ and WRITE statements for the formatted files 5, 6, 7
(variables IR, IW, IP, or named files INPUT, OUTPUT, PUNCH) must be
performed only by the master task. Therefore, these statements must
be enclosed in "IF (MASWRK) THEN" clauses. The MASWRK variable is
found in the PAR module, and is true on the master process only. This
avoids duplicate output from the other processes.

Rule 12. All error termination is done by "CALL ABRT" rather than a
STOP statement. Since this subroutine never returns, it is ok to follow it
with a STOP statement, as compilers may not be happy without a STOP
as the final executable statement in a routine. The purpose of calling
ABRT is to make sure that all parallel tasks get shut down properly.

Rule 13. Naming: All new subroutines must start with a prefix
indicating the part of the code that they are servicing. The prefix should
be in the form of prefixname_subroutinename. For example, a
subroutine for calculating energy used by a Monte Carlo run would be
named MC_energy while a subroutine for shift FMO atoms would be
named FMO_shift.

Rule 14. Any new subroutines must use the “intent” attribute for all
arguments that are passed to the subroutine. Any arguments that are
not changed in the subroutine should be intent in, while any arguments
that are only output should have intent out. All others can have intent
inout. For example, a subroutine x_sub with one argument to be
changed (real A) and one that should not be changed (integer B) would
include the following lines:
subroutine(A, B)
integer, intent(in) :: B
real, intent(out) :: A

To top