Dear all,
I would like to confirm that the first solution posted by Dr. Gavin Abo
works !! I followed section 11.1.1 of the Users Guide (ifort case) and the
SCF cycle with mBJ is running without problems.
There is only a little misprint in the WIEN2k_12 Users Guide, it is "add
-lfftw2xf_intel"... instead of "add -lfftw2xf"... (at least for
ifort 2011.3.174).
Thank you very much for the help,
Luis Ogando
2012/8/24 Fecher, Gerhard <fecher at uni-mainz.de>
> Gavin is right, COMPLEX(8) is the same as COMPLEX*16
> COMPLEX(8) is also the same as DOUBLE COMPLEX (16 bytes, (128 bits))
> and fits to
> REAL(8) (8 bytes, (64 bits))
> as it consists of two real 8 bytes numbers
>
>
> Ciao
> Gerhard
>
> ====================================
> Dr. Gerhard H. Fecher
> Institut of Inorganic and Analytical Chemistry
> Johannes Gutenberg - University
> 55099 Mainz
> ________________________________________
> Von: wien-bounces at zeus.theochem.tuwien.ac.at [
> wien-bounces at zeus.theochem.tuwien.ac.at]" im Auftrag von "Gavin
> Abo [gsabo at crimson.ua.edu]
> Gesendet: Freitag, 24. August 2012 02:00
> An: A Mailing list for WIEN2k users
> Betreff: Re: [Wien] Problems in the 1st step of the SCF cycle of mBj
>
> I believe "complex(kind=8)" is the same as "complex*16", just a different
> notation for it.
>
> If the suggested possible fix works, an if statement in vresp.F to use the
> lines like "DWORK(:)" for fftw2/3 and "DWORK(*)" for fftpack would be
> needed. Else, probably the original fft_modules.F and vresp.F would have
> to be used with some type of changes in fftpack_helpers.f instead.
>
> On 8/23/2012 5:24 PM, Laurence Marks wrote:
>
> Can you change everything to complex*16 ? It makes sense to do everything
> with double precision, I would be concerned with the accuracy of complex*8
> as well as mixing precisions.
>
> ---------------------------
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu<http://www.numis.northwestern.edu>
> 1-847-491-3996
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought"
> Albert Szent-Gyorgi
>
> On Aug 23, 2012 6:19 PM, "Gavin Abo" <gsabo at crimson.ua.edu<mailto:
> gsabo at crimson.ua.edu>> wrote:
> The situational problem with the fftpack routine might be due to some
> inconsistency in the array usage. Maybe Prof. Blaha can provide or confirm
> whether the fix below works properly.
>
> Lines 392-294 in SRC_lapw0/fft_modules.F:
>
> real(kind=8) :: DWORK(:)
> complex(kind=8) :: CWORK(:)
> complex(kind=8) :: C(LDC1,LDC2,N3,2)
>
> Lines 21-22 in SRC_lapw0/vresp.F:
>
> DOUBLE PRECISION DWORK(:)
> COMPLEX*16 CWORK(:)
>
> It runs without error with the following changes.
>
> Lines 392-293 in SRC_lapw0/fft_modules.F:
>
> real(kind=8) DWORK(*)
> complex(kind=8) CWORK(*)
>
> "complex(kind=8) C(LDC1,LDC2,N3,2)" needed too??
>
> Lines 21-22 in SRC_lapw0/vresp.F:
>
> DOUBLE PRECISION DWORK(*)
> COMPLEX*16 CWORK(*)
>
> as the subroutine in SRC_lapw0/fftpack_helpers.f has "DWORK(*)"
>
> On 8/23/2012 12:58 PM, Gavin Abo wrote:
> I was able to reproduce the error with your files when the fftpack routine
> is used in Wien2k 12.1. Ran a couple cycles, and the error did not appear
> when fftw3 was used instead. So a possible solution may be to use the
> fftw3 library.
>
> The fftw3 may be faster than the fftpack, so you probably want to use it
> anyway. It should be easy to use the fftw3 on Debian. fftw3 might already
> be installed or I believe you can install it with:
>
> apt-get install libfftw3-dev
>
> Open the Makefile in a text editor:
>
> vi $WIENROOT/SRC_lapw0/Makefile
>
> Edit and save settings to use for sequential (non-mpi):
>
> FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -DFFTW3 -traceback
> R_LIBS = -lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread
> -lmkl_core -openmp -lpthread -lfftw3
>
> In $WIENROOT/SRC_lapw0:
>
> make
> cp lapw0 ..
>
> As described in section 11.1.1 of the Wien2k 12.1 userguide, the same can
> be done with lapw2. Instructions for using the possible faster mkl-fftw3
> for sequential (non-mpi) instead of the above described fftw3 from a Debian
> repository is also given.
>
> On 8/23/2012 8:06 AM, Luis Carlos Ogando Dacal wrote:
> Dear Wien2k users and developers,
>
> I would like to report the same problem sent to the list by Dr. Eitel
> Peltzer.
> I am running WIEN2k_12.1 on a DELL Precision workstation with two
> QuadCore Xeon processors and Debian Linux. It was compiled using ifort
> 2011.3.174, icc and MKL. The compilation options were:
>
> O Compiler options: -FR -mp1 -w -prec_div -pc80 -pad -ip
> -DINTEL_VML -traceback
> L Linker Flags: $(FOPT)
> -L/opt/intel/composerxe-2011.3.174/mkl/lib/intel64 -pthread
> P Preprocessor flags '-DParallel'
> R R_LIB (LAPACK+BLAS): -lmkl_lapack95_lp64 -lmkl_intel_lp64
> -lmkl_intel_thread -lmkl_core -openmp -lpthread
>
> I have followed section 4.5.9 of the Users Guide and everything is 0K
> until the change of indxc to 28 in case.in0 and 50 in case.in0_grr. After
> this, the SCF cycle stops in the second lapw0 run with the following error
> message:
>
> hup: Command not found.
> LAPW0 END
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image PC Routine Line Source
> lapw0 000000000040505E c3fft_1_ 119
> fftpack_helpers.f
> lapw0 0000000000412D5B fftpack_mp_c3fft_ 397
> fft_modules.F
> lapw0 000000000047F4EC vresp_ 106 vresp.F
> lapw0 0000000000495769 xcpot3_ 147
> xcpot3.F
> lapw0 000000000045C064 MAIN__ 1935 lapw0.F
> lapw0 0000000000403D6C Unknown Unknown Unknown
> libc.so.6 00002B1096C82C8D Unknown Unknown Unknown
> lapw0 0000000000403C69 Unknown Unknown Unknown
>
> > stop error
>
>
> I am sending the case.struct and case.in0 files as requested by Prof.
> Blaha. I have also saved the previous PBE calculation and I can send it if
> necessary (8.5 MB).
> Thanks in advance,
> Luis Ogando
>
>
>
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at<mailto:Wien at zeus.theochem.tuwien.ac.at>
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
> _______________________________________________
> 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/20120824/7a49cc47/attachment-0001.htm>
