ABINIT Discussion Forums

Hello bazaareers,

I am using ifort 11 on abinit 6 (same things happened with 5.9).
If you activate bounds checking with -C _all_ of the tests fail, because a large number of arrays are passed without being allocated. What we do is:

--------------------------------------------------------
real(dp), allocatable :: truc(:,:)

<we do not allocate truc because it will not be used>

call sub(truc)
--------------------------------------------------------

and then:

--------------------------------------------------------
subroutine sub(truc)
real(dp) :: truc(0,0)
--------------------------------------------------------

In principle this does not create an error because truc should never be accessed, but in practice it is quite ugly, and the ifort -C detects it. I think it has an assertion that, in subroutine sub, truc's dimensions are really the ones declared (whereas actually it is unallocated).

I get errors like:
forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable TRUC when it is not allocated

If I allocate truc to size 0, everything is fine. If I just declare real(dp) :: truc(:,:) in sub, it still fails - ifort is still checking for dimensions of a real array.

Could we think about getting rid of this practice? If an object is not allocated and then passed, it should be in a datastructure someplace. The declaration line in the subroutine is rigorously false, ifort sees that, and this practice is also very error prone. I am not advocating allocating these arrays, as this would take up space, but either use a structure of some type, with an associated module, or eventually a pointer (don't like this much in fortran).

Matthieu

Hi,

I already made this observation with ifort in debug mode.
One day, I decided to change all my unallocated pawxxx by pawxxx(0)...
but after a while, I found that I need several days (weeks) to do that. So, I stopped.

Marc

mverstra wrote:Could we think about getting rid of this practice? If an object is not allocated and then passed, it should be in a datastructure someplace. The declaration line in the subroutine is rigorously false, ifort sees that, and this practice is also very error prone. I am not advocating allocating these arrays, as this would take up space, but either use a structure of some type, with an associated module

The idea sounds good but I don't think it can be used anywhere in the code. Some interfaces
can be rewritten such that we pass objects instead of arrays or scalars (e.g mkffnl, nonlop in which
we might pass Psps%). On the other hand. fixing the problem anywhere in the code
will require huge changes.
Besides ifort with your debugging option will always complain if one compiles and links
against the internal linalg as the "not referenced" trick is commonly used in lapack.

Could you provide a list of the routines causing the error at run-time or is it huge?

The idea sounds good but I don't think it can be used anywhere in the code. Some interfaces
can be rewritten such that we pass objects instead of arrays or scalars (e.g mkffnl, nonlop in which
we might pass Psps%). On the other hand. fixing the problem anywhere in the code
will require huge changes.
Besides ifort with your debugging option will always complain if one compiles and links
against the internal linalg as the "not referenced" trick is commonly used in lapack.

Could you provide a list of the routines causing the error at run-time or is it huge?

It is probably huge, but to make matters worse I only get the first instance: the code exits and tells you which array is guilty (not even which subroutine - ifort sucks for this, and my idb crashes). Then you have to fix that array to make it go on to the next one! That would take forever to identify (I have 3-4 arrays). It would probably be quicker to go top down and look 1) for usepaw, 2) for other similar cases, then trace arrays up to see if they are allocated or not. If I have time I will try to get a more complete list. Is allocation to 0 size acceptable, do you think?

For the lapack thing, I don't think it will be a problem: what one does is not "not allocate" but pass a reference to an array slice or something. I believe that if you pass an unallocated array to lapack it will be an error...

Matthieu