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@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.eickerl...@physik.uni-augsburg.de Phone: +49-821-598-3362 FAX: +49-821-598-3227 WWW: http://www.physik.uni-augsburg.de/cpm/ ===================================================== _______________________________________________ Wien mailing list Wien@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