[Wien] memory managment and ifc 8.0

[Ilya Elfimov]

Dear Wien developers and users,



Did anybody test the code compiled with intel fortran compiler 8.0 on large
unit cells?

By large I mean unit cells which do not fit into default parameters. For
example, in 

my test calculation of Cu 111 surface I need KMAX3START to be large than
~170 and

default value is 50. Of course one can simply change it and recompile the
whole program

but this is not interesting. What interesting is that lapw1 will crash in 

doreallocate_warp_c16_d2x3 when it is called from setwarts. This is a line 

where it happens

hilfsfeld(-n1a:n1a,-n2a:n2a,-n3a:n3a)=tf(-n1a:n1a,-n2a:n2a,-n3a:n3a)

Note that this is ifc 8.0 specific behavior. In 7.1 everything is fine.



Okay, here is my question. Although I like the idea but is this a legal use
of pointers in fortran?

Probably I miss something but hilfsfeld isn't a globally defined pointer
(like one could have in C)

and therefore the result might depend on how compiler interpret this code.

actually, I mean the whole memory manager. Does anyone know an option which
would

make 8.0 to understand this part of code properly? 



If not, does any one have any good idea how to solve this? A quick tweak,  

which works, is something like this

          subroutine doreallocate_warp_c16_d2x3(tf, n1a, n1b, n2a, n2b, n3a,
n3b)

            implicit none

            complex*16, allocatable, target  :: tmp(:,:,:)

            complex*16, pointer :: tf(:,:,:),ptmp(:,:,:)

            integer ndim

            integer min1, n1a, n1b, n2a, n2b, n3a, n3b

            ndim=(2*n1a+1)*(2*n2a+1)*(2*n3a+1)

            allocate(tmp(-n1a:n1a,-n2a:n2a,-n3a:n3a))

            call zcopy(ndim,tf,1,tmp,1)

            deallocate(tf)

            allocate(tf(-n1b:n1b,-n2b:n2b,-n3b:n3b))

            tf(-n1b:n1b, -n2b:n2b, -n3b:n3b)=(0.0D0,0.0D0)

            ptmp=>tf(-n1a:n1a,-n2a:n2a,-n3a:n3a)

            call zcopy(ndim,tmp,1,ptmp,1)

            deallocate(tmp)

          end subroutine

but it requires double copying and therefore inefficient.



Thanks,

Ilya