[Wien] problem in l2main.F (parallel version) for large systems

[Wenhui Xie]

I has encountered such a lapw2 crash problem also.
The lapw2 is very sensitive on the fortran compiler.
So we have to choice suitable compiling parameters
for our different machines.

> Dear all,
> 
> I am reporting here something which I call a
> 'problem' in the l2main 
> subroutine,
> since I am not sure whether it happens
> systematically to be named 'bug'.
> I am running a very large system (>12000 APW's), and
> use the mpi
> parallelized version by allocating many (32)
> processors on a
> IBM SP RS/6000Power 4 multiprocessor/multinode
> machine compiling
> with the (mp)xlf90 standard IBM Fortran compiler.
> When the option -O3 is used to compile the lapw2
> program, it happens
> somehow random that in the blocked loop in l2main.F
> routine, some or all
> the ALM and BLM coefficients attain NaNq values.
> This happens for random value of the inequivalent
> atoms.
> Writing NaNq values both in the charge and
> potentials files, i.e. 
> .clmval(up/dn)
> and .vrespval(up/dn) files, the code substitute them
> with zero's when it
> tries to read them later, and loose for some atoms
> the charge, spoiling
> obviously all the self-consistent procedure.
> This problem is avoided by imposing the compiler to
> keep the semantic
> of the program, i.e. by using the option -qstrict in
> addition to the -O3 
> option
> in the compilation step. Probably something goes
> fishy in the blocked
> loop cited above, when the compiler tries to
> optimize it by inverting 
> the order
> of the loops, or maybe there is some variable that
> should be initialized
> (for instance the 'alm' and 'blm' matrices
> themselves?)
> The use of -qstrict does not deteriorate the
> speed-up given
> by the -O3 option to the lapw2 program, so that it
> can be used without any
> loss of performance.
> The use of -qstrict might slow down the the lapw1
> program (I didn't try),
> but since everything goes well for lapw1, I suggest
> to  recompile only 
> the lapw2
> program with the -qstrict option.
> I am wondering whether some of you has encountered
> such a problem already.
> I have to mention here that in a similar
> calculation, on a different 
> system and
> allocating a lower number of CPU's, this problem did
> not show up!
> Best regards,
> Valerio
> 
> -- 
> 
>
*******************************************************************************
>   Valerio Bellini
>   INFM-S3 National Research Center on nanoStructures
> and bioSystems at Surfaces
>   and Department of Physics, University of Modena
> and Reggio Emilia
>   Via Campi 213/A, 41100 Modena, Italy.
>   Phone:   ++39 059 2055301
>   Fax:     ++39 059 374794
>   E-mail:  bellini.valerio at unimore.it
>   WWW:     http://www.s3.infm.it
>
*******************************************************************************
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com