[Wien] NaN output in lapw3 17.1

[Georg Eickerling]

On 01.06.2018 16:17, Peter Blaha wrote:
> A bit strange, but it seems it can happen for certain cases.

Yes, I agree.

> b) Therefore my expectations are that this is due to a different
> compiler ?? and in the older version all variables were initialized to
> zero, while they are not with the new compilation.
> 

There were definitely different ifort versions involved, as 17.1 was
compiled with intels compiler-suite 2018 and I did not recompile the old
WIEN versions. So that's probably the simple explanation.

> d) I would, however, suggest a different fix, because in case there was
> no jump out (I don't know if it can happen, but anyway), you would miss
> the last contribution (probably very small anyway). Instead, put
> 
> rhouse=0.d0        right after the allocate statement.
> 
That's obviously a better solution than just skipping a term, so I'll
use that.

> Thanks for the report and the analysis.

Thank you for the immediate response!



> 
> 
> On 06/01/2018 03:40 PM, Georg Eickerling wrote:
>> Dear WIEN users,
>>
>> I found a possible issue with lapw3 in WIEN 17.1.
>>
>> The bottom line is, that in some cases lapw3 from 17.1 instead of
>> values for
>> Fs produces this in the output:
> 
>> My debugging results:
>> ======================
>>
>> I found that the problem is triggered when the trimming of the INDMAX
>> values
>> happens in fourir.frc starting from line 170.
>>
>> In my particular case, INDMAX = 36353
>> this gets trimmed down to nuse = 21889
>>
>> However, the last value for rhouse(NUSE) I saw created in line 195
>>
>>   rhouse(NUSE)=RHOK(IIZ)/INST(IIZ)*TAUK(KP)
>>
>> was
>>
>>    NUSE        rhouse(NUSE)
>>   21888 -1.357441708557500E-010
>>
>> so that later
>>
>> DO 35 KP=1,NUSE
>>   F=F+RHOUSE(KP)*U
>> 35    ENDDO
>>
>> yields NaN, because RHOUSE(21889) is missing.
>>
>> On the other hand, in line 175 I see
>>
>> allocate(rhouse(INDMAX))
>>
>> so I assume the array is initialized large enough and lapw3 can read
>> "something" from it for the N+1 element?
>>
>> I.e., for my diamond case, the according numbers are
>> indmax 2229
>> nuse   1105
>>
>> the last rhouse created in 195:
>>
>>    NUSE        rhouse(NUSE)
>>   1104  7.021053333129166E-010
>>
>> so that in this case (by conincidence?):
>>
>> rhouse(nuse) = 0.000000000000000E+000
>>
>> and the case works.
>>
>>
>> The fix for me up to now was a
>>
>> DO 35 KP=1,NUSE-1
>>
>> to make it work for my original case with 17.1.
>>
>> Any thoughts on this from the experts?
>>
>>
>> best regards,
>>
>>
>> Georg Eickerling
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at: 
>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>>
> 

-- 
============================
PD Dr. Georg Eickerling
Universitaet Augsburg
Institut fuer Physik
Lehrstuhl fuer Chemische Physik und Materialwissenschaften
Universitaetsstr. 1
86159 Augsburg

E-Mail:	georg.eickerling at physik.uni-augsburg.de
Phone:	+49-821-598-3362
FAX:	+49-821-598-3227
WWW:	http://www.physik.uni-augsburg.de/cpm/
=====================================================