[Wien] Calculation of band gap using PBE0 and YS-PBE0
Hi, If the 2nd and 3rd lines of case.inhf are Tscreened (T) or unscreened (F) 0.165lambda then it is the screened YS-PBE0 which is used. For the unscreened PBE0, the 2nd line should be Fscreened (T) or unscreened (F) and the 3rd line absent. The description of case.inhf is on page 97 of the UG. F. Tran On Fri, 24 Aug 2012, yedu kondalu wrote: > Dear all, > > We are trying to calculate the band gaps with hybrid functionals (PBE0 > and YS-PBE0) implemented in Wien2k-12.1. For learing these calculations, > we started with Si using indxc=13 in Si.in0, indxc=52 in Si.in0 grr and > alpha=0.25. We performed the calculations by following the instructions > given in user guide (Sec. 4.5.8) and the calculations were completed > successfully, also, the band gap is improved. Now, I have the following > queries, > > 1) The obtained band gap using above process is whether for PBE0 or YS-PBE0 > ? > > 2) If possible, please give more detail steps for calculations for YS-PBE0 > hybrid functional ( Because user guide having very less information > regarding YS-PBE0) ? > > > Thanks in advance > > Regards > KONDAL >
[Wien] lapw2 aborted during SCF using 3rd structure in force minimization
at everybody else has seen, and to think what > nobody else has thought" > Albert Szent-Gyorgi > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > -- Shamik Chakrabarti Senior Research Fellow Dept. of Physics & Meteorology Material Processing & Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 INDIA -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120823/32d46b68/attachment.htm>
[Wien] Wien Digest, Vol 80, Issue 7
Compilation problem of lapw0_mpi(fftw) Dear Wien2k users, I am tryig to compiple WIEN2k_11.1 (Release 14/6/2011) parallel version in a Rocks Linux cluster, version 5.3. The problem I faced is very similar to that recorded in http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-December/015856.html http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-October/013900.html Specifically, I got the error while compiling parallel SRC_lapw0. This is the only error message. The rest is OK. fftw_para.o: In function `exec_fftw_para_': fftw_para.F:(.text+0x77): undefined reference to `fftwnd_f77_mpi_' fftw_para.F:(.text+0xb2): undefined reference to `fftwnd_f77_mpi_' fftw_para.o: In function `init_fftw_para_': fftw_para.F:(.text+0x101): undefined reference to `fftw3d_f77_mpi_create_plan_' fftw_para.F:(.text+0x129): undefined reference to `fftw3d_f77_mpi_create_plan_' fftw_para.F:(.text+0x14d): undefined reference to `fftwnd_f77_mpi_local_sizes_' make[1]: *** [lapw0_mpi] Error 1 The content of my Makefile is as follows: = .SUFFIXES:.F .SUFFIXES:.F90 SHELL = /bin/sh FC = ifort MPF = /share/apps/mpich2-install/bin/mpif90 CC = cc FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -I/share/apps/intel/Compiler/11.1/072/mkl/include FPOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -DFFTW3 /share/apps/mpich2-install/include -I/share/apps/intel/Compiler/11.1/072/mkl/include -I/share/apps/intel/Compiler/11.1/072/mkl/include/em64t/lp64 -I/share/apps/fftw3/include -I/share/apps/intel/Compiler/11.1/072/mkl/include/fftw DParallel = '-DParallel' FGEN = $(PARALLEL) LDFLAGS = -pthread -L/share/apps/intel/Compiler/11.1/072/mkl/lib/em64t -L/share/apps/intel/Compiler/11.1/072/lib/em64t -L/share/apps/fftw3/lib -L/share/apps/mpich2-install/lib R_LIBS = -lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -pthread -lguide RP_LIBS = $(R_LIBS) -lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64 -lfftw3 -lfftw3_mpi -lmpich -lfftw2xf_intel = I had tried very hard to get the problem solved but all in vain, even following the suggestions as mentioned in the posts http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-December/015856.html, http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-October/013900.html I have tried to install various versions of fftw (fftw-2.1.5, fftw-3-3.2, even intel version of fftw were tried), compiling them using different compilers (mpif90 of mpich2, mpiifort), but the same problem persists, be I use fftw or fftw2 (I also took care of -DFFTW3 and -DFFTW2 accordingly). I can't figure out what's exactly the source of the problem. Your suggestion will be much appreciated. tl -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120823/44139b12/attachment.htm>
[Wien] Problems in the 1st step of the SCF cycle of mBj
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 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" 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 PCRoutineLineSource > > lapw0 0040505E c3fft_1_ 119 > fftpack_helpers.f > lapw0 00412D5B fftpack_mp_c3fft_ 397 > fft_modules.F > lapw0 0047F4EC vresp_106 vresp.F > lapw0 00495769 xcpot3_ 147 > xcpot3.F > lapw0 0045C064 MAIN__ 1935 lapw0.F > lapw0 00403D6C Unknown Unknown Unknown > libc.so.6 2B1096C82C8D Unknown Unknown Unknown > lapw0 00403C69 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 > > > -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120823/0f3ae5f1/attachment.htm>
[Wien] Problems in the 1st step of the SCF cycle of mBj
with the following error message: >>> >>> hup: Command not found. >>> LAPW0 END >>> forrtl: severe (174): SIGSEGV, segmentation fault occurred >>> Image PCRoutine Line >>> Source >>> lapw0 0040505E c3fft_1_119 >>> fftpack_helpers.f >>> lapw0 00412D5B fftpack_mp_c3fft_ >>> 397 fft_modules.F >>> lapw0 0047F4EC vresp_106 >>> vresp.F >>> lapw0 00495769 xcpot3_ 147 >>> xcpot3.F >>> lapw0 0045C064 MAIN__ 1935 >>> lapw0.F >>> lapw0 00403D6C Unknown Unknown >>> Unknown >>> libc.so.6 2B1096C82C8D Unknown Unknown >>> Unknown >>> lapw0 00403C69 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>
[Wien] Problems in the 1st step of the SCF cycle of mBj
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 PCRoutine LineSource >> lapw0 0040505E c3fft_1_119 >> fftpack_helpers.f >> lapw0 00412D5B fftpack_mp_c3fft_ 397 >> fft_modules.F >> lapw0 0047F4EC vresp_106 vresp.F >> lapw0 00495769 xcpot3_ 147 xcpot3.F >> lapw0 0045C064 MAIN__ 1935 lapw0.F >> lapw0 00403D6C Unknown Unknown Unknown >> libc.so.6 2B1096C82C8D Unknown Unknown Unknown >> lapw0 00403C69 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 -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120823/9b7c9185/attachment.htm>
[Wien] Problems in the 1st step of the SCF cycle of mBj
Dear Wien users, I did what Peter Blaha suggest, download the SRC_lapw0.tar and compile again, here appeared an error, in my distribution of ubuntu, the library fftw3xf does not exist, then I followed the suggestions of Gavin Abo, installing the libfftw3-dev and making the changes in the makefile. I compile lapw0 again without any errors. The self consistent cycle is running without problem. Thanks for the help. Eitel This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
[Wien] lapw2 aborted during SCF using 3rd structure in force minimization
Dear wien2k users, I was running force minimization of a 56 atomic cell ( an oxide material) by constraining the coordinates of elements other than oxygen as that is the only variable parameter (other coordinates are fixed obeying space group symmetry) in wien2k 11.1 I was using NEW1 minimization method following user guide -- "In case of constraint calculations one should use NEW1" Two structure files having different atomic coordinates were already created. while when running SCF calculation using the 3rd struct file, SCF was aborted by mentioning the line at the 4th iteration: > lapw2 -c -up (15:01:51) Abort 3.348u 0.320s 0:01.61 227.3% 0+0k 0+20376io 0pf+0w error: command /home/shamik81/WIEN2k/lapw2c uplapw2.def failed > stop error Another unusual thing is that the energy and charge convergence in different iterations of this SCF cycle went on as below: EC: .41 CC: .0007728 EC: .00600493 CC. .0028021 EC: .002993535 CC. .0028017 There was no error file created and I haven't found any error indicated in case.output2 (up/dn) file and case.scf2up file was empty as lapw2 got aborted when it was just started. Charge distance in the above SCF cycle went on as following: :DIS : CHARGE DISTANCE ( 0.0007728 for atom 48 spin 2) 0.0002381 :DIS : CHARGE DISTANCE ( 0.0028021 for atom 29 spin 2) 0.0019903 :DIS : CHARGE DISTANCE ( 0.0028017 for atom 29 spin 2) 0.0019911 We are not able to figure out what the problem is. Any response in this regard will be very helpful for us. with regards, -- Shamik Chakrabarti Senior Research Fellow Dept. of Physics & Meteorology Material Processing & Solid State Ionics Lab IIT Kharagpur Kharagpur 721302 INDIA -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120823/edcdd5f4/attachment.htm>
[Wien] Problems in the 1st step of the SCF cycle of mBj
Most likely the calculation of the mBJ potential on some grid-points in the interstitial has failed. This could come from: i) a bad starting (incorrect/incompatible case.vsp, case.vresp and clmsum files). ii) since you have a structure with huge vacuum region or very heave atoms ??? iii) lousy convergence parameters (too small RKmax, GMAX, FFTW-grid in case.in0),... iv) a problem in our bBJ routines (possible, but now rather unlikely) Can you run mBJ in other cases ? Restore the PBE calc and run a few PBE cycles, rm *.bro*, retry mBJ. increase FFTW-mesh in case.in0 If nothing helps, you need to send me the specific case and I have to test it myself. Am 23.08.2012 15:12, schrieb eitel at iflysib.unlp.edu.ar: > Dear Wien users, > > I have had problems when I try to run the cycle mBJ, on in the first > iteration, the error is: > > LAPW0 END > forrtl: severe (174): SIGSEGV, segmentation fault occurred > Image PCRoutineLineSource > lapw0 00404F58 c3fft_1_ 119 > fftpack_helpers.f > lapw0 00411EC1 fftpack_mp_c3fft_ 397 > fft_modules.F > lapw0 0047B3ED vresp_106 vresp.F > lapw0 004913E8 xcpot3_ 147 > xcpot3.F > lapw0 004582D9 MAIN__ 1935 lapw0.F > lapw0 00403CEC Unknown Unknown Unknown > libc.so.6 2B57EE0B7EFF Unknown Unknown Unknown > lapw0 00403BE9 Unknown Unknown Unknown > >> stop error > > can someone tell me what is the origin for this error? > >Thanking in advance. > >Eitel Peltzer > > > This message was sent using IMP, the Internet Messaging Program. > > -- Peter Blaha Inst.Materials Chemistry TU Vienna Getreidemarkt 9 A-1060 Vienna Austria +43-1-5880115671
[Wien] Wien Digest, Vol 80, Issue 7
> RP_LIBS = $(R_LIBS) -lmkl_scalapack_lp64 -lmkl_solver_lp64 > -lmkl_blacs_lp64 -lfftw3 -lfftw3_mpi -lmpich -lfftw2xf_intel remove -lfftw2xf_intel from the RP_LIBS (also -lfftw3xf_intel should NOT be there for the parallel compilation, since -lfftw3xf_intel and fftw3_mpi are incompatible). Also: when one installs fftw3 (or 2), one needs to specify some options to make sure that i) the mpi-version is created at all; and ii) the libraries are compatible with ifort-binaries (the number of appended "_" characters differ between eg. gfortran and ifort, ). It is probably best to tell the installation that you have ifort (and preferable icc). I've put some notes on that in the UG (installation of fftw), but the exact way how to do this may vary from fftw-versions Am 23.08.2012 12:30, schrieb Tiem Leong Yoon: > Compilation problem of lapw0_mpi(fftw) > > Specifically, I got the error while compiling parallel SRC_lapw0. This > is the only error message. The rest is OK. > > fftw_para.o: In function `exec_fftw_para_': > fftw_para.F:(.text+0x77): undefined reference to `fftwnd_f77_mpi_' > fftw_para.F:(.text+0xb2): undefined reference to `fftwnd_f77_mpi_' > LDFLAGS = -pthread -L/share/apps/intel/Compiler/11.1/072/mkl/lib/em64t > -L/share/apps/intel/Compiler/11.1/072/lib/em64t -L/share/apps/fftw3/lib > -L/share/apps/mpich2-install/lib > R_LIBS = -lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core > -openmp -pthread -lguide > RP_LIBS = $(R_LIBS) -lmkl_scalapack_lp64 -lmkl_solver_lp64 > -lmkl_blacs_lp64 -lfftw3 -lfftw3_mpi -lmpich -lfftw2xf_intel > = > > I had tried very hard to get the problem solved but all in vain, even > following the suggestions as mentioned in the posts > http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-December/015856.html, > http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-October/013900.html > > I have tried to install various versions of fftw (fftw-2.1.5, > fftw-3-3.2, even intel version of fftw were tried), compiling them using > different compilers (mpif90 of mpich2, mpiifort), but the same problem > persists, be I use fftw or fftw2 (I also took care of -DFFTW3 and > -DFFTW2 accordingly). I can't figure out what's exactly the source of > the problem. Your suggestion will be much appreciated. > > tl > > > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > -- Peter Blaha Inst.Materials Chemistry TU Vienna Getreidemarkt 9 A-1060 Vienna Austria +43-1-5880115671
[Wien] Problems in the 1st step of the SCF cycle of mBj
Dear Prof. Blaha, I carefully followed the suggestions, but nothing improved, I ran another material and the result was exactly the same. The problem appears when I run the mBJ cycle and apparently due the the change in case.in0 of the value 13 for 28. I am sending you the struct file. best Eitel PS: I am using the 12.1 version. Peter Blaha ha escrito: > Most likely the calculation of the mBJ potential on some grid-points in > the interstitial has failed. > > This could come from: > i) a bad starting (incorrect/incompatible case.vsp, case.vresp and > clmsum files). > ii) since you have a structure with huge vacuum region or very heave > atoms ??? > iii) lousy convergence parameters (too small RKmax, GMAX, FFTW-grid in > case.in0),... > iv) a problem in our bBJ routines (possible, but now rather unlikely) > > Can you run mBJ in other cases ? > > Restore the PBE calc and run a few PBE cycles, rm *.bro*, retry mBJ. > > increase FFTW-mesh in case.in0 > > If nothing helps, you need to send me the specific case and I have to > test it myself. > > Am 23.08.2012 15:12, schrieb eitel at iflysib.unlp.edu.ar: >> Dear Wien users, >> >> I have had problems when I try to run the cycle mBJ, on in the first >> iteration, the error is: >> >> LAPW0 END >> forrtl: severe (174): SIGSEGV, segmentation fault occurred >> Image PCRoutineLineSource >> lapw0 00404F58 c3fft_1_ 119 >> fftpack_helpers.f >> lapw0 00411EC1 fftpack_mp_c3fft_ 397 >> fft_modules.F >> lapw0 0047B3ED vresp_106 vresp.F >> lapw0 004913E8 xcpot3_ 147 >> xcpot3.F >> lapw0 004582D9 MAIN__ 1935 lapw0.F >> lapw0 00403CEC Unknown Unknown Unknown >> libc.so.6 2B57EE0B7EFF Unknown Unknown Unknown >> lapw0 00403BE9 Unknown Unknown Unknown >> >>> stop error >> >> can someone tell me what is the origin for this error? >> >> Thanking in advance. >> >> Eitel Peltzer >> >> >> This message was sent using IMP, the Internet Messaging Program. >> >> > > -- > Peter Blaha > Inst.Materials Chemistry > TU Vienna > Getreidemarkt 9 > A-1060 Vienna > Austria > +43-1-5880115671 > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
[Wien] Problems in the 1st step of the SCF cycle of mBj
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 PCRoutine LineSource > lapw0 0040505E c3fft_1_ 119 fftpack_helpers.f > lapw0 00412D5B fftpack_mp_c3fft_ 397 > fft_modules.F > lapw0 0047F4EC vresp_ 106 vresp.F > lapw0 00495769 xcpot3_ 147 xcpot3.F > lapw0 0045C064 MAIN__ 1935 lapw0.F > lapw0 00403D6C Unknown Unknown Unknown > libc.so.6 2B1096C82C8D Unknown Unknown Unknown > lapw0 00403C69 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 > > > > > > 2012/8/23 mailto:eitel at iflysib.unlp.edu.ar>> > > Dear Wien users, > > I have had problems when I try to run the cycle mBJ, on in the > first iteration, the error is: > > LAPW0 END > forrtl: severe (174): SIGSEGV, segmentation fault occurred > Image PCRoutineLine > Source > lapw0 00404F58 c3fft_1_119 > fftpack_helpers.f > lapw0 00411EC1 fftpack_mp_c3fft_ 397 > fft_modules.F > lapw0 0047B3ED vresp_106 vresp.F > lapw0 004913E8 xcpot3_ 147 xcpot3.F > lapw0 004582D9 MAIN__ 1935 lapw0.F > lapw0 00403CEC Unknown Unknown Unknown > libc.so.6 2B57EE0B7EFF Unknown Unknown Unknown > lapw0 00403BE9 Unknown Unknown Unknown > > stop error > > > can someone tell me what is the origin for this error? > > Thanking in advance. > > Eitel Peltzer > > > This message was sent using IMP, the Internet Messaging Program. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > ___ > 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] Problems in the 1st step of the SCF cycle of mBj
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 PCRoutineLineSource lapw0 0040505E c3fft_1_ 119 fftpack_helpers.f lapw0 00412D5B fftpack_mp_c3fft_ 397 fft_modules.F lapw0 0047F4EC vresp_106 vresp.F lapw0 00495769 xcpot3_ 147 xcpot3.F lapw0 0045C064 MAIN__ 1935 lapw0.F lapw0 00403D6C Unknown Unknown Unknown libc.so.6 2B1096C82C8D Unknown Unknown Unknown lapw0 00403C69 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 2012/8/23 > Dear Wien users, > > I have had problems when I try to run the cycle mBJ, on in the first > iteration, the error is: > > LAPW0 END > forrtl: severe (174): SIGSEGV, segmentation fault occurred > Image PCRoutineLineSource > lapw0 00404F58 c3fft_1_ 119 > fftpack_helpers.f > lapw0 00411EC1 fftpack_mp_c3fft_ 397 > fft_modules.F > lapw0 0047B3ED vresp_106 vresp.F > lapw0 004913E8 xcpot3_ 147 > xcpot3.F > lapw0 004582D9 MAIN__ 1935 lapw0.F > lapw0 00403CEC Unknown Unknown Unknown > libc.so.6 2B57EE0B7EFF Unknown Unknown Unknown > lapw0 00403BE9 Unknown Unknown Unknown > >stop error >> > > can someone tell me what is the origin for this error? > > Thanking in advance. > > Eitel Peltzer > > --**--** > This message was sent using IMP, the Internet Messaging Program. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > __**_ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.**at > http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien<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/0f05f52c/attachment.htm> -- next part -- A non-text attachment was scrubbed... Name: BandChara.struct Type: application/octet-stream Size: 3927 bytes Desc: not available URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120823/0f05f52c/attachment.dll> -- next part -- A non-text attachment was scrubbed... Name: BandChara.in1c Type: application/octet-stream Size: 1979 bytes Desc: not available URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120823/0f05f52c/attachment-0001.dll>
[Wien] Virtual-crystal
Dear Users, I am trying to perform a calculation using "virtual-crystal" method. I have found the way to do this and it is as below. - run through inil_lapw using default atomic numbers - edit nuclear charges in case.struct - edit corresponding occupancies in case.inst - edit the total number of electrons in case.in2 - run SCF circle But I do not understand a few things. First, I do not know how I should change the occupation number. I have looked up the manual, but still confused. Just say that I want to do x = 0.5 for example, then what should I edit? There are numbers like "1.0, 2.0, 3.0 and so on..." Second, if I want to add one more electron in the unit cell (two f.u., therefore x = 0.5), should I just do the # of electron + one in case.in2? For example, if the current # of electrons is 25, should I put the # of electrons as 26? All my best, Jihoon Park 2012-08-21 ?? 11:09, Jihoon Park ? ?: > Dear Users, > > > I am trying to perform a calculation using "virtual-crystal" method. > I have found the way to do this and it is as below. > > - run through inil_lapw using default atomic numbers > - edit nuclear charges in case.struct > - edit corresponding occupancies in case.inst > - edit the total number of electrons in case.in2 > - run SCF circle > > > But I do not understand a few things. > > First, I do not know how I should change the occupation number. I have looked > up the manual, but still confused. > Just say that I want to do x = 0.5 for example, then what should I edit? > There are numbers like "1.0, 2.0, 3.0 and so on..." > > Second, if I want to add one more electron in the unit cell (two f.u., > therefore x = 0.5), should I just do the # of electron + one in case.in2? > For example, if the current # of electrons is 25, should I put the # of > electrons as 26? > > > All my best, > Jihoon Park > -- Graduate Research Assistant Magnetic Materials and Device Laboratory Department of Electrical and Computer Engineering 101 Houser Hall, Box 870286 The University of Alabama Tuscaloosa, Alabama 35487 Tel (205)348-3759 Fax (205)348-6959
[Wien] Problems in the 1st step of the SCF cycle of mBj
Dear Wien users, I have had problems when I try to run the cycle mBJ, on in the first iteration, the error is: LAPW0 END forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource lapw0 00404F58 c3fft_1_ 119 fftpack_helpers.f lapw0 00411EC1 fftpack_mp_c3fft_ 397 fft_modules.F lapw0 0047B3ED vresp_106 vresp.F lapw0 004913E8 xcpot3_ 147 xcpot3.F lapw0 004582D9 MAIN__ 1935 lapw0.F lapw0 00403CEC Unknown Unknown Unknown libc.so.6 2B57EE0B7EFF Unknown Unknown Unknown lapw0 00403BE9 Unknown Unknown Unknown > stop error can someone tell me what is the origin for this error? Thanking in advance. Eitel Peltzer This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
[Wien] Problems in the 1st step of the SCF cycle of mBj
I have had this problem too, only with mBJ, in the latest (2012) version of WIEN, which I solved by using an earlier (in this case 2010) version of lapw0 in WIENROOT. This is obviously not an ideal solution, however, and I wonder if there is a better way - perhaps a compilation option? - David Parker On 8/23/12 9:12 AM, "eitel at iflysib.unlp.edu.ar" wrote: >Dear Wien users, > >I have had problems when I try to run the cycle mBJ, on in the first >iteration, the error is: > > LAPW0 END >forrtl: severe (174): SIGSEGV, segmentation fault occurred >Image PCRoutineLineSource >lapw0 00404F58 c3fft_1_ 119 >fftpack_helpers.f >lapw0 00411EC1 fftpack_mp_c3fft_ 397 >fft_modules.F >lapw0 0047B3ED vresp_106 >vresp.F >lapw0 004913E8 xcpot3_ 147 >xcpot3.F >lapw0 004582D9 MAIN__ 1935 >lapw0.F >lapw0 00403CEC Unknown Unknown >Unknown >libc.so.6 2B57EE0B7EFF Unknown Unknown >Unknown >lapw0 00403BE9 Unknown Unknown >Unknown > >> stop error > >can someone tell me what is the origin for this error? > > Thanking in advance. > > Eitel Peltzer > > >This message was sent using IMP, the Internet Messaging Program. > > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. > >___ >Wien mailing list >Wien at zeus.theochem.tuwien.ac.at >http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] resolution dependent F(HKL)s from lapw3
Thank you very much for the replies! Here are some more details: Sphere part: st/l = 1.1: 5 -3 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 0.0 -0.01465 3 -1 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 0.0 0.00410 st/l = 1.2: 3 -1 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 0.0 0.00410 5 -3 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 0.0 -0.01465 st/l = 1.3: -3 -5 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 0.0 -0.01465 -1 -3 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 0.0 0.00410 st/l = 1.8 -3 -5 -5 1.0767 -0.7523 -0.7411 0.00244 0.0 0.00107 0.0 -0.01465 -1 -3 -7 1.0767 -0.7386 -0.7411 -0.00127 0.0 -0.00030 0.0 0.00410 PW part: st/l = 1.1: -3 -5 -5 0.0665201058405473 1.0766653378172495 -1 -3 -7 0.0345681054384858 1.0766653378172495 st/l = 1.2: -3 -5 -5 0.0665201058405473 1.0766653378172495 -1 -3 -7 0.0345681054384858 1.0766653378172495 st/l = 1.3: -3 -5 -5 0.0665201058405473 1.0766653378172495 -1 -3 -7 0.0345681054384858 1.0766653378172495 stl/l = 1.8: -3 -5 -5 0.0665201058405473 1.0766653378172495 -1 -3 -7 0.0345681054384858 1.0766653378172495 But then: "Sum": st/l = 1.1: -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 st/l = 1.2: -3 -5 -5 1.0766653 -1.4106390375 -1 -3 -7 1.0766653 -1.4699320085 st/l = 1.3: -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 stl/l = 1.8: -3 -5 -5 1.0766653 -1.4379800081 -1 -3 -7 1.0766653 -1.4425910379 Second example at higher res (data in the order st/l =1.2, 1.3, 1.8): Sphere: 6 0 -6 1.1894 0.8887 0.8902 -0.00212 0.0 0.00068 0.0 0.0 6 0 -6 1.1894 0.8887 0.8902 -0.00212 0.0 0.00068 0.0 0.0 0 -6 -6 1.1894 -0.8887 -0.8902 0.00212 0.0 -0.00068 0.0 0.0 PW: 0 -6 -6 -0.0362599474060042 1.1893809383585805 0 -6 -6 -0.0362599474060042 1.1893809383585805 0 -6 -6 -0.0362599474060042 1.1893809383585805 Sum: 0 -6 -6 1.18938091.7411783356 0 -6 -6 1.1893809 -1.8246688899 0 -6 -6 1.1893809 -1.8136982305 This is a "default" run by the way, so I am using a GMAX of 12 which gives st/l = 1.8. What I see in addition in output3 is this: KVEC0 -8 -8 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -1 -7 -9 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -2 -8 -8 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC0 -6 -10 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -3 -7 -9 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -2 -6 -10 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -4 -8 -8 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -1 -5 -11 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -4 -6 -10 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -5 -7 -9 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -3 -5 -11 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC0 -4 -12 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -6 -8 -8 IN DENSITY LIST NOT FOUND IN GENERATED K LIST KVEC -2 -4 -12 IN DENSITY LIST NOT FOUND IN GENERATED K LIST Am 23.08.2012 07:37, schrieb Peter Blaha: > Thank's for the report. I'll check that. > > But in the meantime you could do some more analysis and compare the > case.output3 files of two different runs. > Are the differences coming from inside the spheres or from the > interstital > region ? (I expect the latter !) > > Am 22.08.2012 18:32, schrieb Georg Eickerling: >> Dear WIEN users, >> >> I noticed a strange behavior of lapw3 which I do not understand: >> >> Take for example a simple diamond case and calculate structure >> factors from clmsum, lets say up to sin theta/lambda = 1.0: >> >> 000 0.000 12.251726 >> -1 -1 -1 0.2427814 -4.6536716863 >> 00 -2 0.28033980.00 >> 0 -2 -2 0.3964603 -3.9459734623 >> -1 -1 -3 0.4648909 -2.3988162763 >> -2 -2 -2 0.48556270.2266152403 >> 00 -4 0.5606796 -3.1297582248 >> -1 -3 -3 0.61098642.2069300710 >> 0 -2 -4 0.62685880.00 >> -2 -2 -4 0.68668942.877760778
[Wien] Wien Digest, Vol 80, Issue 7
It is important to do a bit of background reading to understand what different options mean in a compilation. It is also important to recognize that FFTW3 is not supported in Wien2k 11.1, only in 12.1 Several options are important here: A "-I" (upper case "i") indicates a directory to look for include files. Normally these directories end with "include". You can create problems for yourself by adding too many of these -- only use the ones which matter. In your case you probably need -I/share/apps/mpich2-install/include -I/share/apps/intel/Compiler/11.1/072/mkl/include -I/share/apps/fftw2/include Note that you missed a "-I" in front of the first. If you followed the recommendations and sourced the Intel command first you do not need the second one. I am assuming that fftw2 has been compiled in the relevant directory. A "-L" (upper case "el") indicates directories to look for libraries. To match the above you want only -L/share/apps/fftw2/lib Adding paths for mpich2 should not be needed. Last, a "-l" (lower case "el") indicates which libraries to use, here probably -lfftw -lfftw_mpi However, this may not solve everything. My guess is that either or both mpich2 or fftw were compiled using gcc and g77. This will sometimes work, but often not. You need to ensure that these were compiled using the Intel compiler (icc & ifort) if you are using these for Wien2k. And/or update to 12.1. This will hopefully get you going in the right direction, although it may not be the full answer as there may be other details of your system that I do not know about. On Thu, Aug 23, 2012 at 5:30 AM, Tiem Leong Yoon wrote: > Compilation problem of lapw0_mpi(fftw) > > Dear Wien2k users, > > I am tryig to compiple WIEN2k_11.1 (Release 14/6/2011) parallel version in a > Rocks Linux cluster, version 5.3. The problem I faced is very similar to > that recorded in > > http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-December/015856.html > http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-October/013900.html > > Specifically, I got the error while compiling parallel SRC_lapw0. This is > the only error message. The rest is OK. > > fftw_para.o: In function `exec_fftw_para_': > fftw_para.F:(.text+0x77): undefined reference to `fftwnd_f77_mpi_' > fftw_para.F:(.text+0xb2): undefined reference to `fftwnd_f77_mpi_' > fftw_para.o: In function `init_fftw_para_': > fftw_para.F:(.text+0x101): undefined reference to > `fftw3d_f77_mpi_create_plan_' > fftw_para.F:(.text+0x129): undefined reference to > `fftw3d_f77_mpi_create_plan_' > fftw_para.F:(.text+0x14d): undefined reference to > `fftwnd_f77_mpi_local_sizes_' > make[1]: *** [lapw0_mpi] Error 1 > > > The content of my Makefile is as follows: > > = > .SUFFIXES:.F > .SUFFIXES:.F90 > SHELL = /bin/sh > FC = ifort > MPF = /share/apps/mpich2-install/bin/mpif90 > CC = cc > FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback > -I/share/apps/intel/Compiler/11.1/072/mkl/include > FPOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -DFFTW3 > /share/apps/mpich2-install/include > -I/share/apps/intel/Compiler/11.1/072/mkl/include > -I/share/apps/intel/Compiler/11.1/072/mkl/include/em64t/lp64 > -I/share/apps/fftw3/include > -I/share/apps/intel/Compiler/11.1/072/mkl/include/fftw > DParallel = '-DParallel' > FGEN = $(PARALLEL) > LDFLAGS = -pthread -L/share/apps/intel/Compiler/11.1/072/mkl/lib/em64t > -L/share/apps/intel/Compiler/11.1/072/lib/em64t -L/share/apps/fftw3/lib > -L/share/apps/mpich2-install/lib > R_LIBS = -lmkl_lapack -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core > -openmp -pthread -lguide > RP_LIBS = $(R_LIBS) -lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64 > -lfftw3 -lfftw3_mpi -lmpich -lfftw2xf_intel > = > > I had tried very hard to get the problem solved but all in vain, even > following the suggestions as mentioned in the posts > http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-December/015856.html, > http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-October/013900.html > > I have tried to install various versions of fftw (fftw-2.1.5, fftw-3-3.2, > even intel version of fftw were tried), compiling them using different > compilers (mpif90 of mpich2, mpiifort), but the same problem persists, be I > use fftw or fftw2 (I also took care of -DFFTW3 and -DFFTW2 accordingly). I > can't figure out what's exactly the source of the problem. Your suggestion > will be much appreciated. > > tl -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University 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
[Wien] lapw2 aborted during SCF using 3rd structure in force minimization
You have misunderstood the UG. Wien2k knows about fixed positions due to symmetry and so long as you have entered your positions with precision, e.g. 0. not 0. you should not impose additional constraints yourself. In addition there is no reason to use NEW1 if you do have constraints as both PORT and MSR1a obey them. However, unless you have a very good reason I do not recommend using constraints. As to why your calculation crashed, no idea as you have not provided enough information for anyone to guess. I suspect that you have chosen inappropriate parameters and/or have a mistake in your input. Most oxides are centrosymmetric and a common mistake is to get a lower symmetry by not entering the initial positions with enough accuracy. On Thu, Aug 23, 2012 at 5:39 AM, shamik chakrabarti wrote: > Dear wien2k users, > > I was running force minimization of a 56 atomic cell ( an oxide > material) by constraining the coordinates of elements other than oxygen as > that is the only variable parameter (other coordinates are fixed obeying > space group symmetry) in wien2k 11.1 > > I was using NEW1 minimization method following user guide -- "In case of > constraint calculations one should use NEW1" > > Two structure files having different atomic coordinates were already > created. > > while when running SCF calculation using the 3rd struct file, SCF was > aborted by mentioning the line at the 4th iteration: > > > lapw2 -c -up (15:01:51) Abort > 3.348u 0.320s 0:01.61 227.3% 0+0k 0+20376io 0pf+0w > error: command /home/shamik81/WIEN2k/lapw2c uplapw2.def failed > >> stop error > > Another unusual thing is that the energy and charge convergence in different > iterations of this SCF cycle went on as below: > > EC: .41 CC: .0007728 > EC: .00600493 CC. .0028021 > EC: .002993535 CC. .0028017 > > There was no error file created and I haven't found any error indicated in > case.output2 (up/dn) file and case.scf2up file was empty as lapw2 got > aborted when it was just started. > > Charge distance in the above SCF cycle went on as following: > > :DIS : CHARGE DISTANCE ( 0.0007728 for atom 48 spin 2) > 0.0002381 > :DIS : CHARGE DISTANCE ( 0.0028021 for atom 29 spin 2) > 0.0019903 > :DIS : CHARGE DISTANCE ( 0.0028017 for atom 29 spin 2) > 0.0019911 > > We are not able to figure out what the problem is. Any response in this > regard will be very helpful for us. > > with regards, > > -- > Shamik Chakrabarti > Senior Research Fellow > Dept. of Physics & Meteorology > Material Processing & Solid State Ionics Lab > IIT Kharagpur > Kharagpur 721302 > INDIA -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University 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
[Wien] resolution dependent F(HKL)s from lapw3
Thank's for the report. I'll check that. But in the meantime you could do some more analysis and compare the case.output3 files of two different runs. Are the differences coming from inside the spheres or from the interstital region ? (I expect the latter !) Am 22.08.2012 18:32, schrieb Georg Eickerling: > Dear WIEN users, > > I noticed a strange behavior of lapw3 which I do not understand: > > Take for example a simple diamond case and calculate structure > factors from clmsum, lets say up to sin theta/lambda = 1.0: > > 000 0.000 12.251726 > -1 -1 -1 0.2427814 -4.6536716863 > 00 -2 0.28033980.00 > 0 -2 -2 0.3964603 -3.9459734623 > -1 -1 -3 0.4648909 -2.3988162763 > -2 -2 -2 0.48556270.2266152403 > 00 -4 0.5606796 -3.1297582248 > -1 -3 -3 0.61098642.2069300710 > 0 -2 -4 0.62685880.00 > -2 -2 -4 0.68668942.8777607788 > -3 -3 -3 0.72834411.9393120414 > -1 -1 -5 0.72834411.9663566686 > 0 -4 -4 0.79292062.6458269883 > -1 -3 -5 0.82925621.8056937118 > -2 -4 -4 0.8410193 -0.0171687161 > 00 -6 0.84101930.00 > 0 -2 -6 0.88651222.4363270068 > -3 -3 -5 0.9191554 -1.6841664183 > -2 -2 -6 0.9297818 -0.0087306004 > -4 -4 -4 0.9711255 -2.2589221048 > > Repeating this calculation with sin theta/lambda = 1.1 and a diff > with the old hkl will just show the additional reflections as expected: > > diff hkl.10 hkl.11 > 20a21,26 >> -1 -5 -5 1.00101321.6970975057 >> -1 -1 -7 1.00101321.5391902602 >> 0 -4 -6 1.01077940.00 >> -2 -4 -6 1.0489354 -2.0944311378 >> -3 -5 -5 1.0766653 -1.4379800081 >> -1 -3 -7 1.0766653 -1.4425910379 > > Now again repeat the calculation with sin theta/lambda = 1.2: > > diff hkl.11 hkl.12 > 25,26c25,32 > <-3 -5 -5 1.0766653 -1.4379800081 > <-1 -3 -7 1.0766653 -1.4425910379 > --- >> -3 -5 -5 1.0766653 -1.4106390375 >> -1 -3 -7 1.0766653 -1.4699320085 >> 00 -8 1.12135911.9443586030 >> -3 -3 -7 1.14734001.3618747163 >> -4 -4 -6 1.15587050.0030399053 >> 0 -2 -8 1.15587050.00 >> 0 -6 -6 1.18938091.7411783356 >> -2 -2 -8 1.1893809 -1.8133181764 > > What happens here? Why are reflections which were exactly the same > before suddenly different? Why I worry about this is, that if you go > on increasing the resolution, the differences become more severe > than in the example above, i.e. sin theta/lambda = 1.3: > > diff hkl.12 hkl.13 > 21,22c21,22 > <-1 -5 -5 1.00101321.6970975057 > <-1 -1 -7 1.00101321.5391902602 > --- >> -1 -5 -5 1.0010132 -1.5542465484 >> -1 -1 -7 1.00101321.5480881986 > > On the other hand, the differences "converge" for a given reflection > but more and more become "affected", i.e. sin theta/lambda = 1.8 > vs. 1.2: > > > diff hkl.12 hkl.18 > 21,22c21,22 > <-1 -5 -5 1.00101321.6970975057 > <-1 -1 -7 1.00101321.5391902602 > --- >> -1 -5 -5 1.0010132 -1.5542465484 >> -1 -1 -7 1.00101321.5480881986 > 25,26c25,26 > <-3 -5 -5 1.0766653 -1.4106390375 > <-1 -3 -7 1.0766653 -1.4699320085 > --- >> -3 -5 -5 1.0766653 -1.4379800081 >> -1 -3 -7 1.0766653 -1.4425910379 > 28c28 > <-3 -3 -7 1.14734001.3618747163 > --- >> -3 -3 -7 1.1473400 -1.3370357923 > 31c31 > < 0 -6 -6 1.18938091.7411783356 > --- >> 0 -6 -6 1.1893809 -1.8136982305 > > > Looking at the result of a refinement of a structural model against > the different HKLs, the "high resolution version" seems to be > "wrong" compared to the low-res one. > > Thank you very much in advance for any comments on this. > > regards > > Georg Eickerling > > -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at -
