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

Fri Aug 24 02:00:00 CEST 2012

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
> 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/20120823/b523614f/attachment.htm>