Use subroutine DENMAT dirac/dirden.F.
Perhaps 98% of the input reading is done using tables and gotos.
Please do not introduce new keyword sections like that for at least three reasons:
Rather have a look in dirac/input_reader.F90. This is the modern way to do it.
Use subroutine REACMO_NO_WORK in dirac/dirgp.F.
They are blocked according to NBBAS and IBBAS.
Large parts of the DIRAC code use MEMGET/MEMREL. Please do not allocate memory using MEMGET/MEMREL. We are trying to get rid of MEMGET/MEMREL.
Memory allocation should be done either using Andre’s alloc/dealloc or using the native allocate/deallocate routines. Alloc/dealloc are frontends to the native allocate/deallocate. The advantage of alloc/dealloc is that the memory allocation gets tracked and shows up in the high water mark. Do not use other home-cooked memory allocation schemes unless you have absolutely no other choice.
Here is an example for alloc/dealloc:
use memory_allocator real(8), allocatable :: one_dim_array(:) integer, allocatable :: two_dim_array(:, :) call alloc(one_dim_array, 1000) call alloc(two_dim_array, 1000, 500) ... call dealloc(one_dim_array) call dealloc(two_dim_array)
Here is an example for allocate/deallocate:
real(8), allocatable :: one_dim_array(:) integer, allocatable :: two_dim_array(:, :) allocate(one_dim_array(1000)) allocate(two_dim_array(1000, 500)) ... deallocate(one_dim_array) deallocate(two_dim_array)
Most of the routines end with:
subroutine foo() ... return end
The “return” is redundant. Simply write “end” without “return”. To make it better, we recommend programmers to stick to the Fortran90/95 coding standards. So the structure of the routine shall be as:
subroutine foo() ... end subroutine
Historical reasons. They have no meaning today.
There is nothing wrong with zgemm. You can use either one - whichever you prefer.
If you want to be 100% independent of the DIRAC infrastructure then you cannot use such routines.
The “implicit.h” is bad programing practice and I strongly recommend to always use implicit none.
Reasons: 1. With “implicit.h” it is easy to use variables that are undefined.
call daxpy(size(array1), D1, array1, 1, array2, 2)
if one forgets to define the parameter D1, the code will compile and D1 can be any number so the result is undefined. With “implicit none” this will not compile.
Another example is a typo: istead of
NDIM = 12 ! correct code
you could type
NDIN = 12 ! typo
With implicit none such mistake won’t compile, with “implicit.h” the code will compile and behave unexpectedly. In this case also the compiler flag “-Wuninitialized” won’t help!
In the code we had (and unfortunatelly still have( many bugs like this and some of us have spent several long afternoons chasing them. The insertions of “implicit.h” is too dangerous and also experienced programmers make typos.
2. The insertion of “implicit none” is nice for other people reading your code. They can see which variables are local, which are global (from common blocks). Without implicit none you have no idea whether this is a local or a global variable if you don’t know the common blocks by heart.
3. The command “implicit none” makes it easier to identify include statements that are really used and includes that are just included but not used. With “implicit.h” you can comment out includes and the code may still compile. Contraty, “implicit none” will warn you. If you remove an include file using “implicit none” and the code compiles, then this include was useless.
This is because we need flexibility for integer variables: compilation of the DIRAC suite goes also with predefined integer*8 variables (through -i8 Fortranflag), for what all integer variables in the code must be declared without KIND restriction.