The code deals with computationally intensive many-body perturbation theory for large quantum systems. Therefore, it must be efficient. We have to stick to Fortran (as native language of the project) allowing for best computational performance and offering unique features in dealing with arrays.
Language of the project: Fortran, several OS dependent subroutines are implemented in C.
The code is in development stage, many more features/calculations are to be implemented. Therefore, the solutions developed within the project must be as transparent as possible. The solutions developed within the project must be as reusable as possible. Transparency and Reusability are achieved by using subroutines which work exclusively with variables provided via arguments. The implication of this rule is that the program would use a very limited set of global variables. As a matter of fact, the usage of global variables is diminished with each commit. The exclusive usage of variables passed by arguments leads to a large argument's lists. This unfortunate implication can be alleviated by using custom types, which reduces number of subroutine's arguments. The definition of types is not a trivial problem, but we developed a style of coding involving intensive usage of custom types.
Programming style:
- Only standard intrinsic functions are used. Usage of wide spread but still non-standard functions hampers compilation. Namely, we avoid such non-standard functions as dcmplx, dreal, dimag, dconjg.
- The package consists of a collection of functions or subroutines which use only their arguments
- custom types are carefully defined to reduce number of arguments
- sizes of arrays can be determined at the beginning of subroutine, eliminating dimension arguments. Usage of assumed-shape arrays is preferred because it allows for a compile-time and run-time checks.
- versatility of subroutines can be increased by using BLAS-like argument's set
- intent attributes must be specified for every argument
- global variables are avoided
- usage of subroutines from other modules must be accompanied by "{{only}}" construct
- In case of complex fields, the access to fields is organized through functions which deliver pointer to the field. The name of the function delivering the pointer must end with _ptr suffix. The delivered pointer must be always associated (i.e. you cannot nullify(ptr) and return from the function).
- Unfortunately, no inheritance is allowed because g95 compiler cannot handle it and presumably other compilers have a limited support for this object-programming feature.
Internal units: Usage of atomic units eliminates a lot of conversion constants from the code. Therefore, atomic units must be used in the code $e=m=\hbar$
Parallelization approach: The code is under development, therefore even essential parts are subject to (substantial) change. This hampers MPI parallelization because MPI parallelization typically is invasive and makes a code less comprehensible. In contrast, OpenMP parallelization is much easier to realize, use and normally maintains the code structure. Therefore, OpenMP is current parallelization strategy. However, the package is dealing with computationally intensive calculations and MPI parallelization must be realized once the code is demonstrated to run in serial version and OpenMP.
- OpenMP on development stage
- MPI when the code becomes mature