[Wien] Problems in the 1st step of the SCF cycle of mBj

Luis Carlos Ogando Dacal ogando at ieav.cta.br
Fri Aug 24 14:49:02 CEST 2012 

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]&quot; im Auftrag von &quot;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>

More information about the Wien mailing list