[Wien] WIEN2k 12 fft_modules

2012-07-30 Thread محمد ارشد فرحان
Dear Prof. Lawrance Gavin-Abo, i've not tested the latest version of Wien2k but, let me mention one more place where real*4 are used that is in the creation of case.klist_band. for any complicated coordinate in the k-path (mainly in monoclinic systems) by using Xcrysden, the multiplier goes

[Wien] WIEN2k 12 fft_modules symmetry

2012-07-30 Thread Peter Blaha
Yes, I can confirm that the missing real*8 in pimach is a bug, even when it does not show up in optimized compilations. One should insert IMPLICIT REAL*8 (A-H,O-Z) in function pimach (bottom of SRC_lapw0/fftpack_helpers.f file). As L.Marks already pointed out, the kurki.f problem is not really

[Wien] WIEN2k 12 fft_modules

2012-07-29 Thread Gavin Abo
Dear Prof. Blaha, Thanks, the scf cycle runs correctly using -O2 or -O3 with the new files for the fftpack routines. However, the scf cycle of the TiC example does not converge with -O1 (in the lapw0 makefile) with wrong values in TiC.output0 such as the plane wave contribution. I don't know

[Wien] WIEN2k 12 fft_modules

2012-07-29 Thread Laurence Marks
Almost certainly it is trickier than this. I expect that -O1 is truncating relevant variables to real*4 which is leading to problems. With -O2 the compiler may well be not bothering to truncate and, at the end of the space allocated for the variable, by luck the correct values are present. This is

[Wien] WIEN2k 12 fft_modules symmetry

2012-07-29 Thread Gavin Abo
Thanks, Prof. Marks. Your explanation is better than mine. Yes, almost certainly the default -r4 is used for -O2, but by luck it is not truncating the variable. By the way, do you think it is also by luck that the ifort compiler produces an x symmetry executable that does not crash with a

[Wien] WIEN2k 12 fft_modules symmetry

2012-07-29 Thread Laurence Marks
If the first declaration is lm(2,49) then in later ones it does not matter (in standard fortran) if it is declared lm(2,1), lm(2,*) or lm(2,48) -- although lm(2,50) could be problematic. The reason is that the size of the array is 2*49 and so long as this is not exceeded everything is fine -- the

[Wien] WIEN2k 12 fft_modules

2012-07-25 Thread Gavin Abo
Dear Prof. Blaha, When I run the TiC example with WIEN2k 12 without k-point or mpi parallelization, the program stops in lapw2 with the error shown below. Here lapw2 cannot read the TiC.energy file, because it is missing data in it as lapw0 gives bad output such as a Density Integral with the