<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="+1">Dear all,<br>
<br>
I am reporting here something which I call a 'problem' in the l2main
subroutine,<br>
since I am not sure whether it happens systematically to be named 'bug'.<br>
I am running a very large system (>12000 APW's), and use the mpi<br>
parallelized version by allocating many (32) processors on a<br>
IBM SP RS/6000Power 4 multiprocessor/multinode machine</font><font
size="+1"> compiling<br>
with the (mp)xlf90 standard IBM Fortran compiler.<br>
When the option -O3 is used to compile the lapw2 program, it happens<br>
somehow random that in the blocked loop in l2main.F routine, some or
all <br>
the ALM and BLM coefficients attain NaNq values.<br>
This happens for random value of the inequivalent atoms.<br>
Writing NaNq values both in the charge and potentials files, i.e.
.clmval(up/dn)<br>
and .vrespval(up/dn) files, the code substitute them with zero's when it<br>
tries to read them later, and loose for some atoms the charge, spoiling<br>
obviously all the self-consistent procedure. <br>
This problem is avoided by imposing the compiler to keep the semantic<br>
of the program, i.e. by using the option -qstrict in addition to the
-O3 option<br>
in the compilation step. Probably something goes fishy in the blocked<br>
loop cited above, when the compiler tries to optimize it by inverting
the order<br>
of the loops, or maybe there is some variable that should be initialized<br>
(for instance the 'alm' and 'blm' matrices themselves?)<br>
The use of -qstrict does not deteriorate the speed-up given<br>
by the -O3 option to the lapw2 program, so that it can be used without
any<br>
loss of performance.<br>
The use of -qstrict might slow down the the lapw1 program (I didn't
try),<br>
but since everything goes well for lapw1, I suggest to recompile only
the lapw2<br>
program with the -qstrict option.<br>
I am wondering whether some of you has encountered such a problem
already.<br>
I have to mention here that in a similar calculation, on a different
system and<br>
allocating a lower number of CPU's, this problem did not show up!<br>
Best regards,<br>
Valerio<br>
<br>
</font>
<pre class="moz-signature" cols="80">--
*******************************************************************************
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: <a class="moz-txt-link-abbreviated" href="mailto:bellini.valerio@unimore.it">bellini.valerio@unimore.it</a>
WWW: <a class="moz-txt-link-freetext" href="http://www.s3.infm.it">http://www.s3.infm.it</a>
*******************************************************************************
</pre>
</body>
</html>