The attached two patches were tested with a TiC calculation, and the results were the same, but it was not tested thoroughly on other cases. The previously reported error for a MBJ calculation also went away. If you want to use the fftpack library instead of FFTW2 or 3, you can try to use them. Just place them in $WIENROOT/SRC_lapw0. Enter in a terminal:
patch -b fft_modules.F fft_modules.patch patch -b vresp.F vresp.patch The -b should create fft_modules.F.orig, a backup of the fft_modules.F before the patch. Then, recompile. The patch is for the files in WIEN2k_12.tar currently on the website. It is noted that TiC.output0 gave for the fftpack and fftw 2.1.5: v-mean, v0,u0 (4.569481054390656E-002,-4.067822355071745E-018) (5.894205821050297E-003,-4.067822355071745E-018) (69.7518919071863,0.000000000000000E+000) (-3.980060472285626E-002,0.000000000000000E+000) fftw 3.3.2: v-mean, v0,u0 (4.569481047410750E-002,-1.113100404819184E-034) (5.894205805621243E-003,-1.113100404819184E-034) (69.7518919071863,0.000000000000000E+000) (-3.980060466848626E-002,0.000000000000000E+000) The mkl fftw2 and mkl fftw3 both had the same result, but the imaginary part was also different than the above cases. I don't know why they are different or if they could significantly impact any of the calculations. On 10/2/2012 1:27 AM, Peter Blaha wrote: > So you find NANs for the WARPING lines, which hints where the > problems come from. > > I suspect that case.vns will NOT contain readable numbers for the > fourier coefficients > (search for "PW" in this file and check). > > In essence, lapw0 seems to have failed, and probably this is due to > problems with the fft-library. > > There were postings on the mailing list about the problem with the > fftwpack library (i.e. in > case you are not using FFTW2 or FFTW3) and also a fix. > > Am 02.10.2012 09:11, schrieb yedu kondalu: >> Dear Prof. Blaha, >> >> I have checked case.scf1 and case.output1 and observed that no >> eigen values printed in case.scf1 after LAPW1 END and WARPING = NaN >> instead of a finite value in case.output1, >> which leads to fail the job without performing LAPW2 step in the >> first iteration. How to rectify this problem ? >> >> I didn't face this problem very few cases but most of the cases >> (about 15 compounds) I come across this problem. >> >> In the previous mail the matrix size is same in two versions of the >> WIEN2k, its a typo error when I copied from the terminal (sorry for >> the typo error). >> >> Thanking you sir, >> >> >> Regards >> Yedukondalu >> >> >> >> >> _______________________________________________ >> Wien mailing list >> Wien at zeus.theochem.tuwien.ac.at >> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121002/774a236f/attachment.htm> -------------- next part -------------- 392,394c392,394 < real(kind=8) :: DWORK(:) < complex(kind=8) :: CWORK(:) < complex(kind=8) :: C(LDC1,LDC2,N3,2) --- > real(kind=8) DWORK(*) > complex(kind=8) CWORK(*) > complex(kind=8) C(LDC1,LDC2,N3,2) -------------- next part -------------- 20a21,24 > #if defined (fftpack) > DOUBLE PRECISION DWORK(*) > COMPLEX*16 CWORK(*) > #else 22a27 > #endif