3.8 Style guide for VASP.4

  In VASP.4 one must use the module prec in all subroutines, and

      USE prec

must be the first statement in all subroutines. All real and complex variables must be defined as REAL(q) and COMPLEX(q) (NEVER: REAL or COMPLEX). The use of IMPLICIT NONE is strongly recommended, but currently not used in all subroutines. If you do not use IMPLICIT NONE you must use

      IMPLICIT REAL(q) (A-H,O-Z)

to guarantee that all real variables have the correct type. The IMPLICIT statement must be the first statement after the USE statements (some compiler allow IMPLICIT somewhere else, but not all F90 compiler do so): for instance

      SUBROUTINE RHOATO(LFOUR,LPAR,GRIDC,T_INFO,B,P,CSTRF,CHTOT,CHDER)
      USE prec
      USE mgrid
      USE pseudo
      USE constant

      IMPLICIT REAL(q) (A-B,D-H,O-Z)

      TYPE (type_info)   T_INFO
      TYPE (potcar)      P(T_INFO%NTYP)
      TYPE (grid_3d)     GRIDC
      COMPLEX(q)   CHTOT(GRIDC%RC%NP),CHDER(GRIDC%RC%NP)
      COMPLEX(q)   CSTRF(GRIDC%MPLWV,T_INFO%NTYP)
      REAL(q)      B(3,3)
      LOGICAL LFOUR,LPAR

Work arrays SHOULD be allocated on the fly with ALLOCATE and DEALLOCATE. DO NOT USE DYNAMIC F90 arrays (except for small unimportant arrays). The dynamic arrays are allocated from the stack and this can degrade performance by up to 20 In addition it can happen that one runs out of stack memory if large arrays are allocated from the stack, unpredictable crashes are possible (at least on IBM workstations). ALLOCATE and DEALLOCATE uses the heap and not the stack and is therefore much saver.

All file must conform the F90 free format. A small utility called convert can be found in the package to convert F77 style to F90 free format.

All subroutines should be placed in a MODULE so that dummy-parameters can be checked during compilation.

Input/Output (IO) should be done with extreme care, to allow later parallelization. The following rules should be obeyed:

• Six classes of information can be distinguished
  • debugging messages
  • general results
  • Notifications (important results)
  • Warnings (strange behavior, continuation possible)
  • Errors (user error, file can not be opened etc.)
  • internal errors (absolute chaos, internal inconsistency)
• Debugging code and messages might remain within the subroutines, and simply bracketed by

  #ifdef debug
  #endif

  Unit ``*'' should be used to write debugging results.
• For less important output (general results) unit IO%IU6 must be used and before writing it must be checked whether IO%IU6 is >=0. (in the parallel version most nodes will have IO%IU6 set to -1).
• Notification and warnings should be written to unit IO%IU0, and before writing it must be checked whether IO%IU0 is >=0. (in the parallel versino most nodes will have IO%IU0 set to -1). Unit ``*'' must not be used for notifications and warnings.
• If the program comes to a point where continuation is impossible (errors, or internal errors) the program should STOP and write why continuation is impossible. If program logic allows to determine that all nodes will come to the same STOP then, preferably only one node should report to unit IO%IU0. If this is not possible and whenever in doubt all nodes should write an error status to unit ``*''.
• Defensive programming should be used whenever possible (i.e. input parameter checked against each other). If a subroutine finds an internal inconsistency errors might be reported to unit ``*'' (internal error).