Tips for ABINIT users and developers - OBSOLETE!

User Tools

Site Tools

Trace:
developers:coding_rules

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
developers:coding_rules [2021/08/31 18:30] – [7. Exception handling and I/Os] Xavier Gonzedevelopers:coding_rules [2024/09/02 14:20] (current) – Maryam Azizi
Line 1: Line 1:
 +<WRAP important>**IMPORTANT WARNING**\\ **<color #ed1c24>This Page is obsolete.</color>** Please refer to www.abinit.org!</WRAP>
 +
 ~~DISCUSSION~~ ~~DISCUSSION~~
 ====== ABINIT style for Fortran programming ====== ====== ABINIT style for Fortran programming ======
  
 (revised many times from the original draft in 1991, BUT NOT REALLY UP_TO_DATE ... SHOULD BE REVISED ONCE MORE) (revised many times from the original draft in 1991, BUT NOT REALLY UP_TO_DATE ... SHOULD BE REVISED ONCE MORE)
- 
-The following sections are covered: 
- 
-    * Foreword. 
-    * Declarations. 
-    * Variables 
-    * File format 
-    * Constructs for flow control 
-    * Use of arrays 
-    * Coding practice 
-    * Exception handling, I/Os 
-    * To be avoided. 
-    * Use of BLAS and LAPACK subroutines. 
-    * Modules 
-    * Derived datatypes 
-    * Other topics 
-    * Useful links 
- 
 ====== 1. Foreword ====== ====== 1. Foreword ======
  
-The ABINIT code should conform to the ANSI Fortran norm (Fortran 95). +The ABINIT code should conform to the ANSI Fortran norm (Fortran 2003). 
-This norm is abbreviated F95, while the older norm, Fortran 77, is abbreviated F77. +Still, most of the following rules can already used with Fortran95. This norm is abbreviated F95, while the older norm, Fortran 77, is abbreviated F77. 
-The following set of rules complements the F95 standard.+The following set of rules complements the F95 (or Fortran2003) standard.
 The ABINIT code conforms to most of these additional rules already. The ABINIT code conforms to most of these additional rules already.
 Each modification, or new routine is expected to adopt all Each modification, or new routine is expected to adopt all
Line 578: Line 562:
 (enforced) (enforced)
  
-====== 8. To be avoided ======+====== 9. To be avoided ======
  
   * Use   * Use
Line 614: Line 598:
        ! although grammatically incorrect. (usually enforced)        ! although grammatically incorrect. (usually enforced)
                
-====== 9. Use of BLAS and LAPACK subroutines ======+====== 10. Use of BLAS and LAPACK subroutines ======
  
 BLAS and LAPACK subroutines are public domain subroutines, gathered BLAS and LAPACK subroutines are public domain subroutines, gathered
Line 672: Line 656:
 (at present, no other BLAS routines than those called by LAPACK are used in ABINIT, so these rules are indications for the future) (at present, no other BLAS routines than those called by LAPACK are used in ABINIT, so these rules are indications for the future)
  
-====== Modules ======+====== 11. Modules ======
  
 MG: This section should be rewritten from scratch! MG: This section should be rewritten from scratch!
Line 695: Line 679:
 Be cautious when you introduce such a feature, and mention it to the ABINIT coordinator. Be cautious when you introduce such a feature, and mention it to the ABINIT coordinator.
  
-====== Derived datatypes ======+====== 12. Derived datatypes ======
  
-Derived datatypes should be declared in the adequate module (MG: And this rule is not followed in many places, e.g dataset_type, header_type ...)+12.a. Derived datatypes should be declared in the adequate module (MG: And this rule is not followed in many places, e.g dataset_type, header_type ...)
 These are powerful F90 constructs, but the information about them is not local to the subroutine  These are powerful F90 constructs, but the information about them is not local to the subroutine 
 where they are used, so they should be introduced in a controlled way, in order for the programmers to become sufficiently easily familiarized with them: the introduction of a new derived datatype must be made in agreement with the coordinator of ABINIT. where they are used, so they should be introduced in a controlled way, in order for the programmers to become sufficiently easily familiarized with them: the introduction of a new derived datatype must be made in agreement with the coordinator of ABINIT.
 The introduction of appropriate derived datatypes in ABINIT is one of the central issues of v3.2 and later versions. The introduction of appropriate derived datatypes in ABINIT is one of the central issues of v3.2 and later versions.
  
-11.b. Suffix a type identifier with '_type'. (MG: What about ''obj_t'' At present we use both!) For example:+12.b. Suffix a type identifier with '_type'. (MG: What about ''obj_t'' At present we use both!) For example:
  
     TYPE ipe_type              ! information on program execution     TYPE ipe_type              ! information on program execution
Line 713: Line 697:
    TYPE(ipe_type) :: ipe    TYPE(ipe_type) :: ipe
  
-11.c. Pros and cons.+12.c. Pros and cons.
  
 Grouping connected variables into structured types is interesting for readability (it avoids too long Grouping connected variables into structured types is interesting for readability (it avoids too long
Line 723: Line 707:
 However, source code itself may become less readable. Also, remember that the use of structured types is never more efficient for CPU: complex declarations should be avoided. However, source code itself may become less readable. Also, remember that the use of structured types is never more efficient for CPU: complex declarations should be avoided.
  
-====== 12. Other topics ======+====== 13. Other topics ======
  
 For the time being, pointers are only allowed when an array has to be allocated in a subprogram, and For the time being, pointers are only allowed when an array has to be allocated in a subprogram, and
developers/coding_rules.1630434643.txt.gz · Last modified: 2021/08/31 18:30 by Xavier Gonze