A few reflections about usage of custom (i.e. user defined) types. The usage of custom types seems to be profitable because it diminishes the number of arguments in procedures. Moreover custom types also allow to modify the communicated data with only local-like changes. The latter is possible because it is not required to change every call which uses a given type if this type got another field. This feature makes types as useful as global variables, although the usage of types does not typically provoke uninitialized data. In order to diminish the uninitilized errors, we use a function-based approach to access the fields. The function-based approach of accessing the fields implies that fields would be rarely accessed directly, i.e. via %field construct, but rather field = get_field(structured_variable). If the "field" in the latter discussion happens to be of another custom type, then it is typically convenient to define a pointer get_* function: field => get_field_ptr(structured_variable). This approach does not produce copies of data and yet the functions defined for a type will also work with the pointer of this type. The get_* functions are easy to program because they should only either deliver data or point to a data field. It is typically not computationally demanding to perform some checks before delivering data inside of these get_* functions. Moreover, these checks do not trash the application code (i.e. the code which actually calls these functions).
There are several types that we find rather generally useful.
1. Types that just contain one allocatable array:
type d_array1_t; real(8), allocatable :: array(:); end type ! d_array1_t
type d_array2_t; real(8), allocatable :: array(:,:); end type ! d_array2_t
...
2. Type that stores non empty lines from input file
!! INPUT TYPE
type input_t
!! Parameters for input/output units
character(20) :: io_units = '';
character(20) :: eps_units = '';
integer :: internal_energy_units=-1; ! Probable a temporary solution which soon will become obsolete
character(MAXLEN), allocatable :: lines(:)
! END of This field will 'substitute' all the others
end type ! input_t
!! END of INPUT TYPE
3. The type containing Hamiltonian, description of atomic orbitals (basis functions), coordinates of molecules and other quantities identifying system under study is widely used in the program. However, its content seems to be not yet stable.
4. Types that contain some auxiliary data (which is not changed in the main loops) seems to be useful. These types considerably reduce number of arguments in the computational subroutines called from the loop's bodies.
5. Types that contain some control/input parameters for a particular calculation. These types are also useful because of reduction of number of arguments.
6. Types with thread-private fields malfunction with some compilers. Therefore, we do not use such constructions.