Re: [Wien] NMR calculations failed
Hi, I would advice to update the SRC_NMR. Such things like that should be gone in the current version. regards Robert On 27 January 2014 PM 3:50:53 Gavin Abo wrote: It may or may not be related to the problem, but it looks like after it prints the line k-point1 ... done, timings (fopv, cs,ci, tot): 4935.04359.16 111.30 5407.25 in SRC_nmr/make_current.frc of Wien2k 13.1, it has the following two lines (201 and 203) deallocate(weigh,evec,gvec,ene) totmemcon=totmemcon-size(evec)*rcmemfac-size(gvec)*imemfac These lines run just fine (at least on my system) with gfortran and ifort. However, it seems strange to me that evec and gvec are being used after they have just been deallocated. On 1/24/2014 12:02 AM, Bing Zhou wrote: Dear all, I can run x_nmr_lapw successfully, however, after run x_nmr_lapw -noinit -emin -0.45 -emax 0.0033, it crashed and I encountered the following error, could you please help me fix it? Thank you in advance! Bing EXECUTING: /global/software/wien2k-13/bin/nmr -case probertite-opt-DOS -mode current-green-emin -0.45 -emax 0.0033 -nocore -scratch /scratch/ -noco k-point1 ... done, timings (fopv, cs,ci, tot): 4935.04359.16 111.30 5407.25 *** glibc detected *** /global/software/wien2k-13/bin/nmr: double free or corruption (!prev): 0x00cd4e90 *** === Backtrace: = /lib64/libc.so.6[0x3df14760e6] /lib64/libc.so.6[0x3df1478c13] /global/software/wien2k-13/bin/nmr[0x4cab2c] /global/software/wien2k-13/bin/nmr[0x473870] /global/software/wien2k-13/bin/nmr[0x46970b] /global/software/wien2k-13/bin/nmr[0x4454b0] /global/software/wien2k-13/bin/nmr[0x410c7f] /global/software/wien2k-13/bin/nmr[0x403b2c] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3df141ecdd] /global/software/wien2k-13/bin/nmr[0x403a29] === Memory map: 0040-005a3000 r-xp 00:14 72801963 /global/software/wien2k-13/bin/nmr 007a3000-007ba000 rw-p 001a3000 00:14 72801963 /global/software/wien2k-13/bin/nmr 007ba000-007f1000 rw-p 00:00 0 00c9a000-06f33000 rw-p 00:00 0 [heap] 3df0c0-3df0c2 r-xp 08:03 1057202 /lib64/ld-2.12.so 3df0e1f000-3df0e2 r--p 0001f000 08:03 1057202 /lib64/ld-2.12.so 3df0e2-3df0e21000 rw-p 0002 08:03 1057202/lib64/ld-2.12.so 3df0e21000-3df0e22000 rw-p 00:00 0 3df100-3df1083000 r-xp 08:03 1057234 /lib64/libm-2.12.so 3df1083000-3df1282000 ---p 00083000 08:03 1057234 /lib64/libm-2.12.so 3df1282000-3df1283000 r--p 00082000 08:03 1057234/lib64/libm-2.12.so 3df1283000-3df1284000 rw-p 00083000 08:03 1057234 /lib64/libm-2.12.so 3df140-3df158a000 r-xp 08:03 1057203 /lib64/libc-2.12.so 3df158a000-3df1789000 ---p 0018a000 08:03 1057203/lib64/libc-2.12.so 3df1789000-3df178d000 r--p 00189000 08:03 1057203 /lib64/libc-2.12.so 3df178d000-3df178e000 rw-p 0018d000 08:03 1057203 /lib64/libc-2.12.so 3df178e000-3df1793000 rw-p 00:00 0 3df180-3df1802000 r-xp 08:03 1057209 /lib64/libdl-2.12.so 3df1802000-3df1a02000 ---p 2000 08:03 1057209 /lib64/libdl-2.12.so 3df1a02000-3df1a03000 r--p 2000 08:03 1057209/lib64/libdl-2.12.so 3df1a03000-3df1a04000 rw-p 3000 08:03 1057209 /lib64/libdl-2.12.so 3df1c0-3df1c17000 r-xp 08:03 1057204 /lib64/libpthread-2.12.so 3df1c17000-3df1e17000 ---p 00017000 08:03 1057204/lib64/libpthread-2.12.so 3df1e17000-3df1e18000 r--p 00017000 08:03 1057204 /lib64/libpthread-2.12.so 3df1e18000-3df1e19000 rw-p 00018000 08:03 1057204/lib64/libpthread-2.12.so 3df1e19000-3df1e1d000 rw-p 00:00 0 3df2c0-3df2c16000 r-xp 08:03 1057222 /lib64/libgcc_s-4.4.7-20120601.so.1 3df2c16000-3df2e15000 ---p 00016000 08:03 1057222/lib64/libgcc_s-4.4.7-20120601.so.1 3df2e15000-3df2e16000 rw-p 00015000 08:03 1057222 /lib64/libgcc_s-4.4.7-20120601.so.1 2ae753c21000-2ae753c23000 rw-p 00:00 0 2ae753c23000-2ae753db8000 r-xp 00:14 51680799 /global/software/fftw-3.3.3-intel12-mpi/lib/libfftw3.so.3.3.2 2ae753db8000-2ae753fb8000 ---p 00195000 00:14 51680799 /global/software/fftw-3.3.3-intel12-mpi/lib/libfftw3.so.3.3.2 2ae753fb8000-2ae753fc4000 rw-p 00195000 00:14 51680799 /global/software/fftw-3.3.3-intel12-mpi/lib/libfftw3.so.3.3.2 2ae753fc4000-2ae754596000 r-xp 00:14 53747059 /global/software/intel2012/composer_xe_2011_sp1.11.339/mkl/lib/intel64/li bmkl_intel_ lp64.so 2ae754596000-2ae754796000 ---p 005d2000 00:14 53747059
[Wien] Regarding failure of making struct and initial file of Hexagonal structure
I am making struct file for Mg (magnesium) using wien2k_13. I have following information of Mg from mincryst (http://database.iem.ac.ru/mincryst/s_carta.php?MAGNESIUM+2671) structure : Hexagonal Spacegroup: P6(3)/mmc with spacegroup No. 194. lattice parameter a=b= 3.2095, alpha=beta= 90, gama = 120. lattice parameter I am giving of hexagonal structure, where as atomic positions I have given of rhombohedral as suggested in wien2k manual. when I am making struct file by using the spacegroup or spacegroup number i.e. 194. then the struct file is not making properly. and while initialising the struct file its spacegroup no. is changing from 194 to 191 i.e. correspond to spacegroup P6/mmm. If I am using lattice type setting (L) while making struct file i.e. when it ask : would you like to enter Spacegroup or Lattice (S/L)(def=S)? then it make the proper struct file and also give the same spcegroup while initialising the struct file. Therefore I want to know why it is showing problem of changing spacegroup while using the spacegroup setting, where as it gives proper struct file and iitialisation in Lattice type setting. Is it due to Hexagonal structure of system or due to any other problem. If you need any further details please let me know. Thanks Regards Saurabh Singh IIT mandi ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] NMR calculations failed
Dear users, Robert has further developed the NMR module (and it is constantly further improved, eg. to allow Knight shift calculations). For these reasons, the version on the net is still the original (old) WIEN2k_13 version, where we know that they contain certain bugs (anisotropy,...) and inaccuracies (suszeptibilities). I'll try to bring up a temporary version as soon as possible, which has fixed all know problems. Eventually without much documentation I'll announce it in the mailing list once it is updated. On 01/27/2014 08:58 AM, Robert Laskowski wrote: Hi, I would advice to update the SRC_NMR. Such things like that should be gone in the current version. regards Robert On 27 January 2014 PM 3:50:53 Gavin Abo wrote: It may or may not be related to the problem, but it looks like after it prints the line k-point1 ... done, timings (fopv, cs,ci, tot): 4935.04359.16 111.30 5407.25 in SRC_nmr/make_current.frc of Wien2k 13.1, it has the following two lines (201 and 203) deallocate(weigh,evec,gvec,ene) totmemcon=totmemcon-size(evec)*rcmemfac-size(gvec)*imemfac These lines run just fine (at least on my system) with gfortran and ifort. However, it seems strange to me that evec and gvec are being used after they have just been deallocated. On 1/24/2014 12:02 AM, Bing Zhou wrote: Dear all, I can run x_nmr_lapw successfully, however, after run x_nmr_lapw -noinit -emin -0.45 -emax 0.0033, it crashed and I encountered the following error, could you please help me fix it? Thank you in advance! Bing EXECUTING: /global/software/wien2k-13/bin/nmr -case probertite-opt-DOS -mode current-green-emin -0.45 -emax 0.0033 -nocore -scratch /scratch/ -noco k-point1 ... done, timings (fopv, cs,ci, tot): 4935.04359.16 111.30 5407.25 *** glibc detected *** /global/software/wien2k-13/bin/nmr: double free or corruption (!prev): 0x00cd4e90 *** === Backtrace: = /lib64/libc.so.6[0x3df14760e6] /lib64/libc.so.6[0x3df1478c13] /global/software/wien2k-13/bin/nmr[0x4cab2c] /global/software/wien2k-13/bin/nmr[0x473870] /global/software/wien2k-13/bin/nmr[0x46970b] /global/software/wien2k-13/bin/nmr[0x4454b0] /global/software/wien2k-13/bin/nmr[0x410c7f] /global/software/wien2k-13/bin/nmr[0x403b2c] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3df141ecdd] /global/software/wien2k-13/bin/nmr[0x403a29] === Memory map: 0040-005a3000 r-xp 00:14 72801963 /global/software/wien2k-13/bin/nmr 007a3000-007ba000 rw-p 001a3000 00:14 72801963 /global/software/wien2k-13/bin/nmr 007ba000-007f1000 rw-p 00:00 0 00c9a000-06f33000 rw-p 00:00 0 [heap] 3df0c0-3df0c2 r-xp 08:03 1057202 /lib64/ld-2.12.so 3df0e1f000-3df0e2 r--p 0001f000 08:03 1057202 /lib64/ld-2.12.so 3df0e2-3df0e21000 rw-p 0002 08:03 1057202/lib64/ld-2.12.so 3df0e21000-3df0e22000 rw-p 00:00 0 3df100-3df1083000 r-xp 08:03 1057234 /lib64/libm-2.12.so 3df1083000-3df1282000 ---p 00083000 08:03 1057234 /lib64/libm-2.12.so 3df1282000-3df1283000 r--p 00082000 08:03 1057234/lib64/libm-2.12.so 3df1283000-3df1284000 rw-p 00083000 08:03 1057234 /lib64/libm-2.12.so 3df140-3df158a000 r-xp 08:03 1057203 /lib64/libc-2.12.so 3df158a000-3df1789000 ---p 0018a000 08:03 1057203/lib64/libc-2.12.so 3df1789000-3df178d000 r--p 00189000 08:03 1057203 /lib64/libc-2.12.so 3df178d000-3df178e000 rw-p 0018d000 08:03 1057203 /lib64/libc-2.12.so 3df178e000-3df1793000 rw-p 00:00 0 3df180-3df1802000 r-xp 08:03 1057209 /lib64/libdl-2.12.so 3df1802000-3df1a02000 ---p 2000 08:03 1057209 /lib64/libdl-2.12.so 3df1a02000-3df1a03000 r--p 2000 08:03 1057209/lib64/libdl-2.12.so 3df1a03000-3df1a04000 rw-p 3000 08:03 1057209 /lib64/libdl-2.12.so 3df1c0-3df1c17000 r-xp 08:03 1057204 /lib64/libpthread-2.12.so 3df1c17000-3df1e17000 ---p 00017000 08:03 1057204/lib64/libpthread-2.12.so 3df1e17000-3df1e18000 r--p 00017000 08:03 1057204 /lib64/libpthread-2.12.so 3df1e18000-3df1e19000 rw-p 00018000 08:03 1057204/lib64/libpthread-2.12.so 3df1e19000-3df1e1d000 rw-p 00:00 0 3df2c0-3df2c16000 r-xp 08:03 1057222 /lib64/libgcc_s-4.4.7-20120601.so.1 3df2c16000-3df2e15000 ---p 00016000 08:03 1057222/lib64/libgcc_s-4.4.7-20120601.so.1 3df2e15000-3df2e16000 rw-p 00015000 08:03 1057222 /lib64/libgcc_s-4.4.7-20120601.so.1 2ae753c21000-2ae753c23000 rw-p 00:00 0 2ae753c23000-2ae753db8000 r-xp 00:14 51680799 /global/software/fftw-3.3.3-intel12-mpi/lib/libfftw3.so.3.3.2 2ae753db8000-2ae753fb8000 ---p 00195000 00:14 51680799
Re: [Wien] Regarding failure of making struct and initial file of Hexagonal structure
No. P6/mmc is NOT a rhombohedral space group, but a hexagonal one. Thus NO conversion of positions . So just give a,a,c,alpha,beta,gamma (120) and 1/3,2/3,0.25 as position of an atom. The second atom at 2/3,1/3,.75 will be created automatically if you use the spacegroup symbol. PS: make sure you enter 1/3 and not just 0. On 01/27/2014 09:17 AM, saurabh singh wrote: I am making struct file for Mg (magnesium) using wien2k_13. I have following information of Mg from mincryst (http://database.iem.ac.ru/mincryst/s_carta.php?MAGNESIUM+2671) structure : Hexagonal Spacegroup: P6(3)/mmc with spacegroup No. 194. lattice parameter a=b= 3.2095, alpha=beta= 90, gama = 120. lattice parameter I am giving of hexagonal structure, where as atomic positions I have given of rhombohedral as suggested in wien2k manual. when I am making struct file by using the spacegroup or spacegroup number i.e. 194. then the struct file is not making properly. and while initialising the struct file its spacegroup no. is changing from 194 to 191 i.e. correspond to spacegroup P6/mmm. If I am using lattice type setting (L) while making struct file i.e. when it ask : would you like to enter Spacegroup or Lattice (S/L)(def=S)? then it make the proper struct file and also give the same spcegroup while initialising the struct file. Therefore I want to know why it is showing problem of changing spacegroup while using the spacegroup setting, where as it gives proper struct file and iitialisation in Lattice type setting. Is it due to Hexagonal structure of system or due to any other problem. If you need any further details please let me know. Thanks Regards Saurabh Singh IIT mandi ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Problem with x symmetry
Hello everyone, I've been studying a set of similar structures (semiconductor defects) which, each time, I first relax with min_lapw after which I do another static run. Once in a while the relaxation gives me a structure which no longer passes through x symmetry. The error and an example struct are given below. Does anyone have any idea how to consistently fix this? x patchsymm does not fix the problem. Thanks, Michael Sluydts ATOM: 1 no hex-pointgroup found lm: == -- ERROR -- ERROR: (multiplicity of atom 1 )*(number of pointgroup-operations) ERROR: is NOT = (number of spacegroup-operations) ERROR: MULT: 1 ISYM: 0 NSYM 6 ERROR: Check your struct file withx sgroup -- ERROR -- ATOM: 2 no hex-pointgroup found lm: == -- ERROR -- ERROR: (multiplicity of atom 2 )*(number of pointgroup-operations) ERROR: is NOT = (number of spacegroup-operations) ERROR: MULT: 3 ISYM: 0 NSYM 6 ERROR: Check your struct file withx sgroup -- ERROR -- ATOM: 3 no hex-pointgroup found lm: == -- ERROR -- ERROR: (multiplicity of atom 3 )*(number of pointgroup-operations) ERROR: is NOT = (number of spacegroup-operations) ERROR: MULT: 6 ISYM: 0 NSYM 6 ERROR: Check your struct file withx sgroup -- ERROR -- octavetmp R 20 160 R3m RELA 30.796412 30.796412 37.717748 90.00 90.00120.00 ATOM 1: X=0. Y=0. Z=0. MULT= 1 ISPLIT= 4 Ga1NPT= 781 R0=0.5000 RMT=1.5200 Z: 31.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 2: X=0.12462802 Y=0.37401410 Z=0.12462802 MULT= 3 ISPLIT= 8 2: X=0.12462802 Y=0.12462802 Z=0.37401410 2: X=0.37401410 Y=0.12462802 Z=0.12462802 Ge1NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 3: X=0.62493876 Y=0.37487342 Z=0.12467773 MULT= 6 ISPLIT= 8 3: X=0.12467773 Y=0.62493876 Z=0.37487342 3: X=0.37487342 Y=0.12467773 Z=0.62493876 3: X=0.37487342 Y=0.62493876 Z=0.12467773 3: X=0.62493876 Y=0.12467773 Z=0.37487342 3: X=0.12467773 Y=0.37487342 Z=0.62493876 Ge2NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 4: X=0.62492215 Y=0.37475633 Z=0.62492215 MULT= 3 ISPLIT= 8 4: X=0.62492215 Y=0.62492215 Z=0.37475633 4: X=0.37475633 Y=0.62492215 Z=0.62492215 Ge3NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 5: X=0.12201757 Y=0.87800148 Z=0.12201757 MULT= 3 ISPLIT= 8 5: X=0.12201757 Y=0.12201757 Z=0.87800148 5: X=0.87800148 Y=0.12201757 Z=0.12201757 Ge4NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 6: X=0.62573282 Y=0.87502487 Z=0.12480892 MULT= 6 ISPLIT= 8 6: X=0.12480892 Y=0.62573282 Z=0.87502487 6: X=0.87502487 Y=0.12480892 Z=0.62573282 6: X=0.87502487 Y=0.62573282 Z=0.12480892 6: X=0.62573282 Y=0.12480892 Z=0.87502487 6: X=0.12480892 Y=0.87502487 Z=0.62573282 Ge5NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 7: X=0.62500264 Y=0.87521103 Z=0.62500264 MULT= 3 ISPLIT= 8 7: X=0.62500264 Y=0.62500264 Z=0.87521103 7: X=0.87521103 Y=0.62500264 Z=0.62500264 Ge6NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 8: X=0.49974584 Y=0.99967116 Z=0.99967116 MULT= 3 ISPLIT= 8 8: X=0.99967116 Y=0.49974584 Z=0.99967116 8: X=0.99967116
Re: [Wien] Problem with x symmetry
I do not have these problems with my version of symmetry. It does not produce any error and runs fine, finding all symmetries. However, I very much doubt that the struct file you attached is from min_lapw ??? It has POSITIVE atomic numbers and WRONG local rotation matrices ?? Are you using the latest WIEN2k version ? On 01/27/2014 10:44 AM, Michael Sluydts wrote: Hello everyone, I've been studying a set of similar structures (semiconductor defects) which, each time, I first relax with min_lapw after which I do another static run. Once in a while the relaxation gives me a structure which no longer passes through x symmetry. The error and an example struct are given below. Does anyone have any idea how to consistently fix this? x patchsymm does not fix the problem. Thanks, Michael Sluydts ATOM: 1 no hex-pointgroup found lm: == -- ERROR -- ERROR: (multiplicity of atom 1 )*(number of pointgroup-operations) ERROR: is NOT = (number of spacegroup-operations) ERROR: MULT: 1 ISYM: 0 NSYM 6 ERROR: Check your struct file withx sgroup -- ERROR -- ATOM: 2 no hex-pointgroup found lm: == -- ERROR -- ERROR: (multiplicity of atom 2 )*(number of pointgroup-operations) ERROR: is NOT = (number of spacegroup-operations) ERROR: MULT: 3 ISYM: 0 NSYM 6 ERROR: Check your struct file withx sgroup -- ERROR -- ATOM: 3 no hex-pointgroup found lm: == -- ERROR -- ERROR: (multiplicity of atom 3 )*(number of pointgroup-operations) ERROR: is NOT = (number of spacegroup-operations) ERROR: MULT: 6 ISYM: 0 NSYM 6 ERROR: Check your struct file withx sgroup -- ERROR -- octavetmp R 20 160 R3m RELA 30.796412 30.796412 37.717748 90.00 90.00120.00 ATOM 1: X=0. Y=0. Z=0. MULT= 1 ISPLIT= 4 Ga1NPT= 781 R0=0.5000 RMT=1.5200 Z: 31.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 2: X=0.12462802 Y=0.37401410 Z=0.12462802 MULT= 3 ISPLIT= 8 2: X=0.12462802 Y=0.12462802 Z=0.37401410 2: X=0.37401410 Y=0.12462802 Z=0.12462802 Ge1NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 3: X=0.62493876 Y=0.37487342 Z=0.12467773 MULT= 6 ISPLIT= 8 3: X=0.12467773 Y=0.62493876 Z=0.37487342 3: X=0.37487342 Y=0.12467773 Z=0.62493876 3: X=0.37487342 Y=0.62493876 Z=0.12467773 3: X=0.62493876 Y=0.12467773 Z=0.37487342 3: X=0.12467773 Y=0.37487342 Z=0.62493876 Ge2NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 4: X=0.62492215 Y=0.37475633 Z=0.62492215 MULT= 3 ISPLIT= 8 4: X=0.62492215 Y=0.62492215 Z=0.37475633 4: X=0.37475633 Y=0.62492215 Z=0.62492215 Ge3NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 5: X=0.12201757 Y=0.87800148 Z=0.12201757 MULT= 3 ISPLIT= 8 5: X=0.12201757 Y=0.12201757 Z=0.87800148 5: X=0.87800148 Y=0.12201757 Z=0.12201757 Ge4NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 6: X=0.62573282 Y=0.87502487 Z=0.12480892 MULT= 6 ISPLIT= 8 6: X=0.12480892 Y=0.62573282 Z=0.87502487 6: X=0.87502487 Y=0.12480892 Z=0.62573282 6: X=0.87502487 Y=0.62573282 Z=0.12480892 6: X=0.62573282 Y=0.12480892 Z=0.87502487 6: X=0.12480892 Y=0.87502487 Z=0.62573282 Ge5NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 7: X=0.62500264 Y=0.87521103 Z=0.62500264 MULT= 3 ISPLIT= 8 7: X=0.62500264 Y=0.62500264 Z=0.87521103
Re: [Wien] NMR calculations failed
Dear Peter, Many thanks！ Regards, Bing On Mon, 1/27/14, Peter Blaha pbl...@theochem.tuwien.ac.at wrote: Subject: Re: [Wien] NMR calculations failed To: A Mailing list for WIEN2k users wien@zeus.theochem.tuwien.ac.at Received: Monday, January 27, 2014, 4:14 AM Dear users, Robert has further developed the NMR module (and it is constantly further improved, eg. to allow Knight shift calculations). For these reasons, the version on the net is still the original (old) WIEN2k_13 version, where we know that they contain certain bugs (anisotropy,...) and inaccuracies (suszeptibilities). I'll try to bring up a temporary version as soon as possible, which has fixed all know problems. Eventually without much documentation I'll announce it in the mailing list once it is updated. On 01/27/2014 08:58 AM, Robert Laskowski wrote: Hi, I would advice to update the SRC_NMR. Such things like that should be gone in the current version. regards Robert On 27 January 2014 PM 3:50:53 Gavin Abo wrote: It may or may not be related to the problem, but it looks like after it prints the line k-point 1 ... done, timings (fopv, cs,ci, tot): 4935.04 359.16 111.30 5407.25 in SRC_nmr/make_current.frc of Wien2k 13.1, it has the following two lines (201 and 203) deallocate(weigh,evec,gvec,ene) totmemcon=totmemcon-size(evec)*rcmemfac-size(gvec)*imemfac These lines run just fine (at least on my system) with gfortran and ifort. However, it seems strange to me that evec and gvec are being used after they have just been deallocated. On 1/24/2014 12:02 AM, Bing Zhou wrote: Dear all, I can run x_nmr_lapw successfully, however, after run x_nmr_lapw -noinit -emin -0.45 -emax 0.0033, it crashed and I encountered the following error, could you please help me fix it? Thank you in advance! Bing EXECUTING: /global/software/wien2k-13/bin/nmr -case probertite-opt-DOS -mode current -green -emin -0.45 -emax 0.0033 -nocore -scratch /scratch/ -noco k-point 1 ... done, timings (fopv, cs,ci, tot): 4935.04 359.16 111.30 5407.25 *** glibc detected *** /global/software/wien2k-13/bin/nmr: double free or corruption (!prev): 0x00cd4e90 *** === Backtrace: = /lib64/libc.so.6[0x3df14760e6] /lib64/libc.so.6[0x3df1478c13] /global/software/wien2k-13/bin/nmr[0x4cab2c] /global/software/wien2k-13/bin/nmr[0x473870] /global/software/wien2k-13/bin/nmr[0x46970b] /global/software/wien2k-13/bin/nmr[0x4454b0] /global/software/wien2k-13/bin/nmr[0x410c7f] /global/software/wien2k-13/bin/nmr[0x403b2c] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3df141ecdd] /global/software/wien2k-13/bin/nmr[0x403a29] === Memory map: 0040-005a3000 r-xp 00:14 72801963 /global/software/wien2k-13/bin/nmr 007a3000-007ba000 rw-p 001a3000 00:14 72801963 /global/software/wien2k-13/bin/nmr 007ba000-007f1000 rw-p 00:00 0 00c9a000-06f33000 rw-p 00:00 0 [heap] 3df0c0-3df0c2 r-xp 08:03 1057202 /lib64/ld-2.12.so 3df0e1f000-3df0e2 r--p 0001f000 08:03 1057202 /lib64/ld-2.12.so 3df0e2-3df0e21000 rw-p 0002 08:03 1057202 /lib64/ld-2.12.so 3df0e21000-3df0e22000 rw-p 00:00 0 3df100-3df1083000 r-xp 08:03 1057234 /lib64/libm-2.12.so 3df1083000-3df1282000 ---p 00083000 08:03 1057234 /lib64/libm-2.12.so 3df1282000-3df1283000 r--p 00082000 08:03 1057234 /lib64/libm-2.12.so 3df1283000-3df1284000 rw-p 00083000 08:03 1057234 /lib64/libm-2.12.so 3df140-3df158a000 r-xp 08:03 1057203 /lib64/libc-2.12.so 3df158a000-3df1789000 ---p 0018a000 08:03 1057203 /lib64/libc-2.12.so 3df1789000-3df178d000 r--p 00189000 08:03 1057203 /lib64/libc-2.12.so 3df178d000-3df178e000 rw-p 0018d000 08:03 1057203 /lib64/libc-2.12.so 3df178e000-3df1793000 rw-p 00:00 0 3df180-3df1802000 r-xp 08:03 1057209 /lib64/libdl-2.12.so 3df1802000-3df1a02000 ---p 2000 08:03 1057209 /lib64/libdl-2.12.so 3df1a02000-3df1a03000 r--p 2000 08:03 1057209 /lib64/libdl-2.12.so 3df1a03000-3df1a04000 rw-p 3000 08:03 1057209 /lib64/libdl-2.12.so 3df1c0-3df1c17000 r-xp 08:03 1057204 /lib64/libpthread-2.12.so 3df1c17000-3df1e17000 ---p 00017000 08:03 1057204 /lib64/libpthread-2.12.so 3df1e17000-3df1e18000 r--p 00017000 08:03 1057204 /lib64/libpthread-2.12.so 3df1e18000-3df1e19000 rw-p 00018000 08:03 1057204
Re: [Wien] Problem with x symmetry
The original calculation was done with a patched 12.1 for consistency reasons. I *thought* I used 13's x symmetry when testing this morning. However, it would seem that the module did not swap properly. Having retested with 13 it seems to work now. I've also looked into the positive atom numbers, that specific struct had gone through 12's sgroup which seems to have changed those from negative to positive and messed with the rotational matrices i assume. Thanks, Michael Sluydts Peter Blaha schreef op 27/01/2014 11:28: I do not have these problems with my version of symmetry. It does not produce any error and runs fine, finding all symmetries. However, I very much doubt that the struct file you attached is from min_lapw ??? It has POSITIVE atomic numbers and WRONG local rotation matrices ?? Are you using the latest WIEN2k version ? On 01/27/2014 10:44 AM, Michael Sluydts wrote: Hello everyone, I've been studying a set of similar structures (semiconductor defects) which, each time, I first relax with min_lapw after which I do another static run. Once in a while the relaxation gives me a structure which no longer passes through x symmetry. The error and an example struct are given below. Does anyone have any idea how to consistently fix this? x patchsymm does not fix the problem. Thanks, Michael Sluydts ATOM: 1 no hex-pointgroup found lm: == -- ERROR -- ERROR: (multiplicity of atom 1 )*(number of pointgroup-operations) ERROR: is NOT = (number of spacegroup-operations) ERROR: MULT: 1 ISYM: 0 NSYM 6 ERROR: Check your struct file withx sgroup -- ERROR -- ATOM: 2 no hex-pointgroup found lm: == -- ERROR -- ERROR: (multiplicity of atom 2 )*(number of pointgroup-operations) ERROR: is NOT = (number of spacegroup-operations) ERROR: MULT: 3 ISYM: 0 NSYM 6 ERROR: Check your struct file withx sgroup -- ERROR -- ATOM: 3 no hex-pointgroup found lm: == -- ERROR -- ERROR: (multiplicity of atom 3 )*(number of pointgroup-operations) ERROR: is NOT = (number of spacegroup-operations) ERROR: MULT: 6 ISYM: 0 NSYM 6 ERROR: Check your struct file withx sgroup -- ERROR -- octavetmp R 20 160 R3m RELA 30.796412 30.796412 37.717748 90.00 90.00120.00 ATOM 1: X=0. Y=0. Z=0. MULT= 1 ISPLIT= 4 Ga1NPT= 781 R0=0.5000 RMT=1.5200 Z: 31.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 2: X=0.12462802 Y=0.37401410 Z=0.12462802 MULT= 3 ISPLIT= 8 2: X=0.12462802 Y=0.12462802 Z=0.37401410 2: X=0.37401410 Y=0.12462802 Z=0.12462802 Ge1NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 3: X=0.62493876 Y=0.37487342 Z=0.12467773 MULT= 6 ISPLIT= 8 3: X=0.12467773 Y=0.62493876 Z=0.37487342 3: X=0.37487342 Y=0.12467773 Z=0.62493876 3: X=0.37487342 Y=0.62493876 Z=0.12467773 3: X=0.62493876 Y=0.12467773 Z=0.37487342 3: X=0.12467773 Y=0.37487342 Z=0.62493876 Ge2NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 4: X=0.62492215 Y=0.37475633 Z=0.62492215 MULT= 3 ISPLIT= 8 4: X=0.62492215 Y=0.62492215 Z=0.37475633 4: X=0.37475633 Y=0.62492215 Z=0.62492215 Ge3NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 5: X=0.12201757 Y=0.87800148 Z=0.12201757 MULT= 3 ISPLIT= 8 5: X=0.12201757 Y=0.12201757 Z=0.87800148 5: X=0.87800148 Y=0.12201757 Z=0.12201757 Ge4NPT= 781 R0=0.5000 RMT=2. Z: 32.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 6: X=0.62573282 Y=0.87502487 Z=0.12480892 MULT= 6 ISPLIT= 8 6: X=0.12480892 Y=0.62573282 Z=0.87502487 6: X=0.87502487
Re: [Wien] Error in LAPW2
Dear Vishal Jain, I believe that this link may be useful : http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09836.html All the best, Luis 2014-01-26 vishal jain vjain...@gmail.com Dear All We are getting following error after 15 scf cycle. 'LAPW2' semicore band ranges too large, ghostband? Structure file attached with mail and initialization done with these parameters (VXC =13 PBE, RKMAX 7.0, K-point in full BZ 100) Thanks and Regards Vishal Jain Research Scholar Department of Physics MLSU, Udaipur ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Error in LAPW2
Are you sure that your struct file is correct ?? You have quite small RMTs for Fe, Co (1.7 and 1.62), but in particular for Al only 1.35 ??? Did you, by chance, mix bohr and ang units for the lattice parameters ?? On 01/27/2014 02:13 PM, Luis Ogando wrote: Dear Vishal Jain, I believe that this link may be useful : http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09836.html All the best, Luis 2014-01-26 vishal jain vjain...@gmail.com mailto:vjain...@gmail.com Dear All We are getting following error after 15 scf cycle. 'LAPW2' semicore band ranges too large, ghostband? Structure file attached with mail and initialization done with these parameters (VXC =13 PBE, RKMAX 7.0, K-point in full BZ 100) Thanks and Regards Vishal Jain Research Scholar Department of Physics MLSU, Udaipur ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Regarding failure of making struct and initial file of Hexagonal structure
thanks Peter for your kind help. I use the atomic positions as you suggested like 1/3 2/3 0.25. it works properly and generated second atom as expected. Thanks and regards Saurabh Singh IIT Mandi On Monday, January 27, 2014 2:49 PM, Peter Blaha pbl...@theochem.tuwien.ac.at wrote: No. P6/mmc is NOT a rhombohedral space group, but a hexagonal one. Thus NO conversion of positions . So just give a,a,c,alpha,beta,gamma (120) and 1/3,2/3,0.25 as position of an atom. The second atom at 2/3,1/3,.75 will be created automatically if you use the spacegroup symbol. PS: make sure you enter 1/3 and not just 0. On 01/27/2014 09:17 AM, saurabh singh wrote: I am making struct file for Mg (magnesium) using wien2k_13. I have following information of Mg from mincryst (http://database.iem.ac.ru/mincryst/s_carta.php?MAGNESIUM+2671) structure : Hexagonal Spacegroup: P6(3)/mmc with spacegroup No. 194. lattice parameter a=b= 3.2095, alpha=beta= 90, gama = 120. lattice parameter I am giving of hexagonal structure, where as atomic positions I have given of rhombohedral as suggested in wien2k manual. when I am making struct file by using the spacegroup or spacegroup number i.e. 194. then the struct file is not making properly. and while initialising the struct file its spacegroup no. is changing from 194 to 191 i.e. correspond to spacegroup P6/mmm. If I am using lattice type setting (L) while making struct file i.e. when it ask : would you like to enter Spacegroup or Lattice (S/L)(def=S)? then it make the proper struct file and also give the same spcegroup while initialising the struct file. Therefore I want to know why it is showing problem of changing spacegroup while using the spacegroup setting, where as it gives proper struct file and iitialisation in Lattice type setting. Is it due to Hexagonal structure of system or due to any other problem. If you need any further details please let me know. Thanks Regards Saurabh Singh IIT mandi ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.at WWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Problem with qtl program in wien2k-13
Thank you, now it works fine Best regards, Bambang On Sat, Jan 25, 2014 at 5:38 AM, Chuck-Hou Yee c...@kitp.ucsb.edu wrote: Dear list, I can confirm the problem---parallel qtl broken in 13.1, works fine in 12.1. The bugfix which Elias alluded to: Change line 20 in qtlmain.f from CHARACTER*80 VECFN to CHARACTER*180 VECFN and recompile with siteconfig_lapw. Best, Chuck ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- Prijamboedi ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Hi
Greetings from Prof Rajagopalan I installed BoltzTraP code without any problem. I like to run for Al I generated the data using Wien When I gave the command ./x_trans BoltzTraP I got an error COULD NOT OPEN FILE 5 ERROR IN OPENING FILE Will some one help me how to overcome Thanking you in advance Regards Rajagopalan -- * Dr M.RajagopalanConsultant (DRDO Project)Crystal Growth Center 20 6th Main RoadAnna University ChromepetChennai 600 025 Chennai 600 044Phone # 22213023 (R) 22359208 (O)Mobile 9445125709*Believe Me, though I pass away, My bones in My tomb will be speaking, moving and discussing your welfare. Go where ever you like, around the wide world, over the seven seas, I am always with you. My abode is in your heart. Always worship Me who is seated in your heart as well as the heart of all other beings. Blessed and fortunate indeed is he, who knows Me thus -- Shirdi Sai Baba. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
