[Wien] WIEN2k workshop 2012 and Happy New Year
Dear WIEN2k users, I'm happy to announce the 19th WIEN2k-workshop. It will be held at Waseda University in Tokyo (Japan) 3 - 7 Sept. 2012. and is organized by Tomoyuki Yamamoto. It will provide a perfect opportunity to learn more about WIEN2k with introductory lectures on WIEN2k and well guided hands-on sessions to give beginners a good start, but also to guide more advanced users to learn all the secret possibilities of the code directly from the developers. For more information follow the link at http://www.wien2k.at Happy new year 2012 Peter Blaha and Karlheinz Schwarz -- - 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 -
[Wien] A basic problem about KGEN(shift k-mesh?)
Of course, different k-meshes will give a different total energy, until the mesh is converged, i.e. dense enough so that the integration over the BZ gives identical results. (But your energies are not even well converged within the scf cycle). If you want E-tot with higher precision you need to increase the k-mesh until nothing changes within the desired accuracy. A few remarks: A shifted k-mesh usually converges faster, i.e. needs a less dense k-mesh to converge. Usually it is NOT necessary to increase the k-mesh until E-tot does not change. In particular the electron density in the scf-cycle and the forces (in a structure optimization) converge (for an insulator !!!) quite fast. Only whe you compare E-tot between 2 calculations (2 phases,...) you need to be sure that the numbers are converged. Usually it is a good strategy to start with a more crude k-mesh, save_lapw the results, x kgen creating a denser mesh (more k-points) and continue with another run_lapw (WITHOUT init_lapw or x dstart !!). When the previous mesh was good, only 3 scf-cycles will be done until convergence was reached. Am 23.12.2011 03:20, schrieb W Hx: Dear users, In WIEN2k-FAQ: KGEN: Add inversion ? Shift k-mesh ? # *shiftthe k-mesh ? *(only for some lattice types) * Shifting of k-mesh means that it will add (x,x,x) to all generated k-points, thus shifting them from high symmetry points (lines) to more general points with a higher weight. By this procedure (known also as *special k-point methods*) one generates an equally dense mesh, but with less basis points. * Usually a shift is *recommended *. Only one word of warning: When you are interested in gaps of semiconductors, they are often located at Gamma or X (or at some other BZ-border point). With shifted meshes you will NOT have those high-symmetry points in your mesh, thus the gap may seem to be smaller/larger than expected. * Solution to this problem: Do the scf cycle with the shifted mesh, but for a DOS change to a fine unshifted mesh. From that we know that shifting of k-mesh generates an equally 'dense' mesh. So we should get nearly the same results for the same case whether shift k-mesh or not. I calculated the same case (TiO2 2*2*2 supercell) with shift k-mesh and no shift k-mesh. But the ENE are different. grep :ENE 222.scf_mini (shift k-mesh? Yes) :ENE : ** TOTAL ENERGY IN Ry = -32144.63765571 :ENE : ** TOTAL ENERGY IN Ry = -32144.63322019 :ENE : ** TOTAL ENERGY IN Ry = -32144.63804051 :ENE : ** TOTAL ENERGY IN Ry = -32144.63815033 :ENE : ** TOTAL ENERGY IN Ry = -32144.63855011 grep :ENE 222.scf_mini(shift k-mesh? No) :ENE : ** TOTAL ENERGY IN Ry = -32144.63642529 :ENE : ** TOTAL ENERGY IN Ry = -32144.63182990 :ENE : ** TOTAL ENERGY IN Ry = -32144.63679565 :ENE : ** TOTAL ENERGY IN Ry = -32144.63690506 :ENE : ** TOTAL ENERGY IN Ry = -32144.63730723 The energies are different widely. I can not understand. For other case i minimized the struct with shift k-mesh and then run a cycle with no shift k-mesh, the energy may be larger or smaller. And the forces are not smaller than 2. Can you explain it for me? Thank you for your time and patience. yours sincerely, Hongxia Wang ___ 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 Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at -
[Wien] Happy New Year
*Dear Professor Peter Blaha and all Wien2k Users,* *I wish a Happy New Year for You, all Wien2k developers and users, too.* *With the Best Wishes,* *Ahmad Gharleghi* -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20111230/04db4452/attachment.htm
[Wien] Fwd: RKmax related errors in parallel OPTIC program
Hard to say. I do not see any connection between the error and a parallel/non-parallel calculation, except maybe that your computers are overloaded and run out of memory or some other limits due to the many parallel jobs. Am 22.12.2011 20:08, schrieb wanxiang feng: Dear Prof. Blaha There are some RKmax related errors in parallel OPTIC program(WIEN2k_11.1). My system is monolayer MoS2 with slab model, I just want to calculate the momentum operator elements by using OPTIC program. If I do serial calculation and set RKmax = 7 or 9 in case.in1c, all will be OK. If I do parallel calculation, RKmax = 7 is OK, but RKmax=9 gives me an error. After obtained the converged ground state(k-mesh is 16x16x1), my calculation flow is: 1) serial calculation x lapw0 x lapw1 -c -up x lapw1 -c -dn x lapwso -c -up x optic -c -so -up RKmax = 7 or 9 are all OK! 2) parallel calculation (k-point parallel) x lapw0 x lapw1 -c -up -p x lapw1 -c -dn -p x lapwso -c -up -p x optic -c -so -up -p RKmax = 7 is OK, but RKmax = 9 is ERROR! The error information: --- running OPTIC in parallel mode [1] 24639 [2] 24833 [3] 25027 [4] 25221 [5] 25415 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource opticc 00423937 planew_ 164 planew_tmp.f opticc 0043247F mom_mat_ 588 sph-UP_tmp.f opticc 0041D660 MAIN__447 opmain.f opticc 004035EC Unknown Unknown Unknown libc.so.6 00366FC1D994 Unknown Unknown Unknown opticc 004034F9 Unknown Unknown Unknown --- I attached structure file and all input files, could you kindly help me to test it and find out the exact reason? Thanks in advance! Feng ___ 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 Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at -
[Wien] help
Just 2 additional remakrs to the answers you already had: a) For a dual core Xeon system the mpi-parallel version is useless. Don't worry about mpi-compilation and neglect it. b) The commandline x lapw2 -so -qtlindicates that you included spin-orbit coupling (maybe you accidentally clicked on SO somewhere ??) In any case, SO calculations can only be done after running initso_lapw, which would create TiC.in2c for you (without initso you just have TiC.in2), and is necessary for SO calculations. Am 26.12.2011 07:21, schrieb arqum hashmi: dear users i am new user of wien2k. firstly i run the TiC example, and i find error in calculating DOS i am runing wien2k version10 pentium (R) dual core Xenon processor operating system is linux fortran compiler 11.0.074 math libraries 10.1.0.015 Yes, I have already browsed the archives AND READ THE USERS GUIDE and the FAQ pages Peter provides, but I couldn't solve my problem that way. i have following error during DOS, please guide me about this Commandline: *x lapw2 -so -qtl * Program input is: ** forrtl: severe (24): end-of-file during read, unit 5, file /home/hashumi/WIEN2k/TiC/TiC.in2c Image PCRoutineLineSource lapw2c 0810B1CBUnknown Unknown Unknown lapw2c 0810A7EB Unknown Unknown Unknown lapw2c 080CF1DE Unknown Unknown Unknown lapw2c 0809EAF8 Unknown Unknown Unknown lapw2c 0809E782 Unknown Unknown Unknown lapw2c 080B51E1 Unknown Unknown Unknown lapw2c 080860FE MAIN__199 lapw2_tmp_.F lapw2c 0804A611 Unknown Unknown Unknown libc.so.6 563E8BE5 Unknown Unknown Unknown lapw2c 0804A541 Unknown Unknown Unknown 0.008u 0.000s 0:00.00 0.0%0+0k 0+16io 0pf+0w error: command /home/hashumi/WIEN2k/lapw2c lapw2.def failed thanks and regards ___ 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 Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at -
[Wien] k point parallel mode
To make the file, you use an editor (nothing more or less) and put the file in the directory where you are running the job. I have not looked, but there is probably something in w2web to do this. N.B., the code does not use OMP anywhere (at present) so this will not do anything. 2011/12/30 susanta mohanta susanta.phy at gmail.com: Dear Prof. Blaha and Wien2k Users, ?? I am running wien2k on a intel i7 PC (6core 12 Processors) with Fedora linux. The program is using maximum six processors at a time. I think, I have to do k point parallel configuration to use all the processors for a single program. I have tried with OMP_NUM_THREADS (1 to 12), it did not work. Any suggestion how to make .machine (though example is there but where to make) file and which files needs to be edited (or created) for k point parallel mode will be helpful. I have gone through the user guide and checked in the mailing list, but could not find thing that could help me. ?Wish you all a very happy new year in advance. with sincere regards susanta ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- 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] k point parallel mode
To make the file, you use an editor (nothing more or less) and putthe file in the directory where you are running the job. I have notlooked, but there is probably something in w2web to do this. N.B., the code does not use OMP anywhere (at present) so this will notdo anything. Just a small correction: If you are using the mkl, OMP_NUM_THREADS will have an effect in the diagonalization part of lapw1 (which is often the main part anyway). However, while OMP_NUM_THREADS = 2 is quite effective and speeds up the diagonalization significantly, =4 is far less efficient and = 6 is usually useless. PS: On a 6 core machine you should run ONLY 6 jobs at the same time (or 3 k-parallel jobs with OMP_NUM_THREADS=2) !!! Intels hyperthreading, which mimics 12 processors to you, should even be switched off (BIOS), because it will slow down the jobs. -- - 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 -
[Wien] k point parallel mode
A comment on Peter''s comment. OMP_NUM_THREADS might have an effect, but the parameter is really MKL_NUM_THREADS if you are using Intel's mkl library -- and even then the compiler makes it's own decisions about how many it will use and this varies with version of the compiler (and probably what one has to set). Also...many of these things depend upon exactly what is in your computer, e.g. memory speed, bus speed as well as what else is running. Best is to do your own benchmarks, e.g. see http://www.wien2k.at/reg_user/benchmark/. For instance, while on older computers Intel's hyperthreading was not good much to my surprise when I tried it (by accident) on a recent dual hex-core machine it was quite reasonable. N.B., the same holds for mpi -- very hardware and software dependent in my experience. On Fri, Dec 30, 2011 at 5:44 AM, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: To make the file, you use an editor (nothing more or less) and putthe file in the directory where you are running the job. I have notlooked, but there is probably something in w2web to do this. N.B., the code does not use OMP anywhere (at present) so this will notdo anything. Just a small correction: If you are using the mkl, OMP_NUM_THREADS will have an effect in the diagonalization part of lapw1 (which is often the main part anyway). However, while OMP_NUM_THREADS = 2 is quite effective and speeds up the diagonalization significantly, =4 is far less efficient and = 6 is usually useless. PS: On a 6 core machine you should run ONLY 6 jobs at the same time (or 3 k-parallel jobs with OMP_NUM_THREADS=2) !!! Intels hyperthreading, which mimics 12 processors to you, should even be switched off (BIOS), because it will slow down the jobs. -- - 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 - ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- 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] k point parallel mode
Thanks for this suggestions. I am using ifort (version 12 update 3) and mkl. i am trying to make the .machine file for k point parallel mode and inform you if any problem persists. On Fri, Dec 30, 2011 at 5:32 PM, Laurence Marks L-marks at northwestern.eduwrote: A comment on Peter''s comment. OMP_NUM_THREADS might have an effect, but the parameter is really MKL_NUM_THREADS if you are using Intel's mkl library -- and even then the compiler makes it's own decisions about how many it will use and this varies with version of the compiler (and probably what one has to set). Also...many of these things depend upon exactly what is in your computer, e.g. memory speed, bus speed as well as what else is running. Best is to do your own benchmarks, e.g. see http://www.wien2k.at/reg_user/benchmark/. For instance, while on older computers Intel's hyperthreading was not good much to my surprise when I tried it (by accident) on a recent dual hex-core machine it was quite reasonable. N.B., the same holds for mpi -- very hardware and software dependent in my experience. On Fri, Dec 30, 2011 at 5:44 AM, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: To make the file, you use an editor (nothing more or less) and putthe file in the directory where you are running the job. I have notlooked, but there is probably something in w2web to do this. N.B., the code does not use OMP anywhere (at present) so this will notdo anything. Just a small correction: If you are using the mkl, OMP_NUM_THREADS will have an effect in the diagonalization part of lapw1 (which is often the main part anyway). However, while OMP_NUM_THREADS = 2 is quite effective and speeds up the diagonalization significantly, =4 is far less efficient and = 6 is usually useless. PS: On a 6 core machine you should run ONLY 6 jobs at the same time (or 3 k-parallel jobs with OMP_NUM_THREADS=2) !!! Intels hyperthreading, which mimics 12 processors to you, should even be switched off (BIOS), because it will slow down the jobs. -- - 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 - ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- 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 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/20111230/af7a9246/attachment.htm
[Wien] (no subject)
* Hello ; * I am running wien version?11 on a machine of type?dell N5010?, fortran compiler?pgf and math libraries gcc. * I'm working on a spinel structure CuCrZrSe4 and I have a problem with it lstart m'affiche: Commandline: x lstart-up Program input is: 13 -6.0 ?? SELECT XCPOT: ?? recommended: 13: GGA-PBE (Perdew-Burke-Ernzerhof 96) 5: LSDA ??? 11: WC-GGA (Wu-Cohen 2006) ??? 19: PBEsol-GGA (Perdew et al. 2008) ?? SELECT ENERGY core and valence to Separate states: ?? recommended: -6.0 Ry (check How Much core charge leaks out of MT-sphere) ?? Alternatively: Specify charge localization ?? (between 0.97 and 1.0) to select core state WARNING: R0 for an atom Z = 29.00 too big WARNING: R0 for atom Z = -2 24.00 too big WARNING: R0 for atom Z = 40.00 -3 too big : WARNING: CORE 0667 Zr electrons leak out of MT-sphere!! : WARNING: touch. LCOR and run scf-cycle overlap with core density : WARNING: Gold: rerun lstart with lower E-core separation energy WARNING: R0 for atom Z = -4 34.00 too big lstart ENDS 0.028 0.498u 0:00.60 85.0% 0 +0 k 0 2320 1768 13PF io w even though I changed in the second stage R0 de'initialisation view outputnn as shown. When I run SCF-cycle it stops at uplapw1 it displays: Error in LAPW1 ? SELECT - no energy limits found for L = 0 ? SELECT - E-E-top bottom -10.31100 -200.0 * Please I really need your help and thank you in advance cordially mouna Mesbahi -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20111230/fafcdc88/attachment.htm
[Wien] (no subject)
2011/12/30 susanta mohanta susanta.phy at gmail.com: Dear mauna, 1) You can reduce the R0 values for corresponding atom(s) in the case.struct files to get rid of the R0 problem. Yes 2) You need a lower energy cutoff to reduce the core leakage. Maybe. You should look at the RMT's carefully -- you did not say what these were so nobody can advise you.For Zr you probably want something like 2.2 or perhaps larger (guessing, you need to investigate). You should also look in case.output at what states are valence ( an F in the core-state column for the summary for each atom, which starts with E-up(Ry) E-dn(Ry) . You may be able to use -7 if there are Zr states at (for instance) -6.5 or a number such as 0.995 which will make all states with more than 0.995 occupancy core. Use this later option with care; there is not much documentation in the UG on this so you have to work out how to use it yourself by trial and error (which is what I did). Peter might comment on this option. check also the RMT values, whether your RMT spheres are touching ? touching spheres will not work in APW+lo method. with regards susanta 2011/12/30 Mouna Mesbahi mouna.mesbahi at yahoo.fr Hello ; I am running wien version?11 on a machine of type?dell N5010?, fortran compiler?pgf and math libraries gcc. I'm working on a spinel structure CuCrZrSe4 and I have a problem with it lstart m'affiche: Commandline: x lstart-up Program input is: 13 -6.0 ?? SELECT XCPOT: ?? recommended: 13: GGA-PBE (Perdew-Burke-Ernzerhof 96) 5: LSDA ??? 11: WC-GGA (Wu-Cohen 2006) ??? 19: PBEsol-GGA (Perdew et al. 2008) ?? SELECT ENERGY core and valence to Separate states: ?? recommended: -6.0 Ry (check How Much core charge leaks out of MT-sphere) ?? Alternatively: Specify charge localization ?? (between 0.97 and 1.0) to select core state WARNING: R0 for an atom Z = 29.00 too big WARNING: R0 for atom Z = -2 24.00 too big WARNING: R0 for atom Z = 40.00 -3 too big : WARNING: CORE 0667 Zr electrons leak out of MT-sphere!! : WARNING: touch. LCOR and run scf-cycle overlap with core density : WARNING: Gold: rerun lstart with lower E-core separation energy WARNING: R0 for atom Z = -4 34.00 too big lstart ENDS 0.028 0.498u 0:00.60 85.0% 0 +0 k 0 2320 1768 13PF io w even though I changed in the second stage R0 de'initialisation view outputnn as shown. When I run SCF-cycle it stops at uplapw1 it displays: Error in LAPW1 ? SELECT - no energy limits found for L = 0 ? SELECT - E-E-top bottom -10.31100 -200.0 Please I really need your help and thank you in advance cordially mouna Mesbahi ___ Wien mailing list 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 -- 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] (no subject)
I'm pretty sure you messed up the struct file when changing R0 manually. The numbers in this file are position dependent, so you must REPLACE, but not INSERT/DELETE any character. I'd recommend you use w2web to generate the structures. Am 30.12.2011 15:15, schrieb Mouna Mesbahi: # Hello ; # I am running wien version 11 on a machine of type dell N5010 , fortran compiler pgf and math libraries gcc. # I'm working on a spinel structure CuCrZrSe4 and I have a problem with it lstart m'affiche: Commandline: x lstart-up Program input is: 13 -6.0 *SELECT XCPOT: recommended: 13: GGA-PBE (Perdew-Burke-Ernzerhof 96) 5: LSDA 11: WC-GGA (Wu-Cohen 2006) 19: PBEsol-GGA (Perdew et al. 2008) SELECT ENERGY core and valence to Separate states: recommended: -6.0 Ry (check How Much core charge leaks out of MT-sphere) Alternatively: Specify charge localization (between 0.97 and 1.0) to select core state WARNING: R0 for an atom Z = 29.00 too big WARNING: R0 for atom Z = -2 24.00 too big WARNING: R0 for atom Z = 40.00 -3 too big : WARNING: CORE 0667 Zr electrons leak out of MT-sphere!! : WARNING: touch. LCOR and run scf-cycle overlap with core density : WARNING: Gold: rerun lstart with lower E-core separation energy WARNING: R0 for atom Z = -4 34.00 too big lstart ENDS 0.028 0.498u 0:00.60 85.0% 0 +0 k 0 2320 1768 13PF io w* even though I changed in the second stage R0 de'initialisation view outputnn as shown. When I run SCF-cycle it stops at uplapw1 it displays: *Error in LAPW1 SELECT - no energy limits found for L = 0 SELECT - E-E-top bottom -10.31100 -200.0* # Please I really need your help and thank you in advance cordially mouna Mesbahi ___ 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 Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pblaha at theochem.tuwien.ac.at -
