[Wien] Wien2k 12

Dear Prof Blaha, the new upgraded WIEN2k 12 does not have the executable file (expand_lapw). Is it replaced by another name. Yours sincerely Jameson Maibam Assam University -- next part -- An HTML attachment was scrubbed... URL:

[Wien] Wien2k 12

It has an expand_lapw.gz which is unzipped by gunzip *.gz Am 25.07.2012 11:16, schrieb Jameson Maibam: > Dear Prof Blaha, > the new upgraded WIEN2k 12 does not have the executable file (expand_lapw). > Is it replaced by another name. > Yours sincerely > Jameson Maibam > Assam University > >

[Wien] Wien2k 12

It was my mistake that I downloaded the executable tar file. Now I got it in the complete source code. Thank you, Jameson Maibam - Original Message - From: Peter Blaha To: A Mailing list for WIEN2k users Cc: Sent: Wednesday, 25 July 2012 7:14 PM Subject: Re: [Wien] Wien2k 12 It

[Wien] wien2k 12

Dear Prof Blaha I tried to run TiC in the wien2k 12 in my hp proliant ml110 using centos 6. After reading the mail posted by Gavin Abo and your reply I put the three subroutines? (eramps.f, fft_modules.F fftpack_helpers.f) and recompiled. I got the following error: ?LAPW0 END ?LAPW1 END ?LAPW2 EN

[Wien] WIEN2k 12 fft_modules

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 th

[Wien] WIEN2k 12 fft_modules

Thank's for the report. The problem concerns lapw0, when compiled in sequential mode WITHOUT -DFFTW2 or -DFFTW3 in the Makefile (i.e. using the old "fftpack" routines instead of the new and faster fftw library). The fix suggested in the mail below does not work. Instead, you have to replace

[Wien] WIEN2k 12 fft_modules

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 w

[Wien] WIEN2k 12 fft_modules

I have not tested, but it looks like you are probably right. There may be other cases where variables are not explicitly defined to be 8 bytes which are normally hidden by the use of "-r8". Did you use -r8? On Sun, Jul 29, 2012 at 1:57 PM, Gavin Abo wrote: > Dear Prof. Blaha, > > Thanks, the scf

[Wien] WIEN2k 12 fft_modules

I didn't use -r8. However, you are right. The scf cycle works correctly if I use "-O1 -r8". So the higher optimizations -O2 and -O3 must be invoking the use of -r8, whereas -O0 and -O1 should be using the default -r4. On 7/29/2012 1:40 PM, Laurence Marks wrote: > I have not tested, but it loo

[Wien] WIEN2k 12 fft_modules

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

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 sho

[Wien] WIEN2k 12 fft_modules & symmetry

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 m

[Wien] WIEN2k 12 fft_modules & symmetry

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 l

[Wien] WIEN2k 12 fft_modules & symmetry

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 real