[Wien] install wien2k on netbook
Dear Carmen, I don't understand what you mean when you say that it doesn't set WIEN2k. Are you able to successfully compile or is your problem in the compile stage? If you are having trouble in the compile stage, may I recommend the following website for details: http://hi.baidu.com/fengzhenjie/blog/item/a46aa952bd854f0f0df3e322.html Regards, Richard On Tue, 20 Apr 2010, CARMEN wrote: Dear Richard: I was trying to install in another netbook HP with the same features (Intel?? Atom???, 2 GB ram, 250 GB SSD), first I installed Ubuntu remix 9.10, after that, install the compilers fortran 11.1 , but when I try to install wien2k , it doesn't set the WIEN2k ?? Would you please help me? I really appreciate it Thanks in advance Carmen Chung
[Wien] parallel under sge environment
Still the analysis is not complete: In your job you requested 4 slots. In your job.error I can see 3 attempts to connect to remote hosts (r105-n15,r108-n84 and r103-n2), but not 4. Furthermore I see 2 times: lapw0 END ??? how does the corresponding .machines file look ? When you request 4-8 slots, do you get them on the same node, or are they allocated on different nodes (as suggested in your errorlog. ? If they are on the same node, you can follow the advise given before and disable ssh for k-point parallel. This can be done eg. by reinstalling WIEWN2k and saying shared memory machines in siteconfig. --- However, your error log still did not convince me that ssh is impossible. On your login node say: hostname (which returns the name of your frontend). Then ssh host (substitute host by the actual name obtained before. Can you login WITHOUT specifying a password ??? If not, your ssh-keygen installation was not succesful, but this is a prerequisite. Am 20.04.2010 21:29, schrieb zhaoyh: Hello Prof. Blaha and Marks, The submitting script and the error message have been attached. The host and hosts pe are not usable right now. The only one I can use is mpi. Thanks for your help. Regards, yonghong On Tue, 2010-04-20 at 16:33 +0200, Peter Blaha wrote: Still not clear: I cannot use ssh means that this supercomputer doesn't allow users to log in to the compute node directly. I have consulted the admin already. He just ask me to use sge script to submit job. The attachment is the It is normal that you cannot ssh to the compute node FROM the login node. So you will never be able to type in ssh nodexxx but this is NOT necessary anyway! Have you tried to adapt one of the job scripts at the faq-page of www.wien2k.at and after creation of the machines file, putrun_lapw -p into the sge script ?? It is not helpful to show the PWSCF script, show the WIEN2k script you have tried. Anyway from your script I can see: #$ -pe mpi 160 # 4 slots (allocated among the available hosts) ##$ -pe host 6 # 6 slots (allocated on a single host max=8) ##$ -pe hosts 16 # 8 slots per host. (numbers of cores should be a multiple of 8) Most likely you need to uncomment the last line (and comment the first one), if you do not want to use mpi. At least it indicates that you have different pe environments available. Then you need some lines, which generates .machines from the nodes assigned to you. (See templates mentioned above, or you said, that you already have that) mpirun -np 160 pwscf -npool 16 input out Instead of that line, you put run_lapw -p My experience says, that users who cannot handle k-parallelism, will not be able to run mpi-parallel, because this is much more difficult. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Peter Blaha Inst.Materialchemie, TU Wien Getreidemarkt 9 A-1060 Vienna Austria
[Wien] struct file of Fe
Hi shamik, Your structure file is wrong because no of symmetry operation is zero. You have to do init_lapw properly. If not works,?i will send you the structure file. swati --- On Wed, 21/4/10, shamik chakrabarti shamikphy at gmail.com wrote: From: shamik chakrabarti shamik...@gmail.com Subject: struct file of Fe To: swati chaudhury swati at rcais.res.in Date: Wednesday, 21 April, 2010, 10:27 AM Dear Swati Madam, ?? ? ? ? ? ? ? ? ? ? ? ? ? ?Can you please send me the Fe struct file by which you have performed volume optimization. I am still not able to performe the ?volume optimization for both fcc Ni and bcc Fe with spin polarization. Without spin polarization it is performing well!..looking forward to you. with regards, Shamik Chakrabarti?
[Wien] struct file of Fe
Hi Shamik, Swaty, I met this problem some time ago. As it turned out, it's enough to run 'x symmetry' to add correct symmetry operations to case.struct file. You don't need to perform full init operation for it. Best regards, Maxim Rakitin Postgraduate student South Ural State University, 76 Lenin av., Chelyabinsk, Russia, 454080 Email: rms85 at physics.susu.ac.ru Web: http://www.susu.ac.ru 21.04.2010 12:06, swati chaudhury ?: Hi shamik, Your structure file is wrong because no of symmetry operation is zero. You have to do init_lapw properly. If not works, i will send you the structure file. swati --- On Wed, 21/4/10, shamik chakrabartishamikphy at gmail.com wrote: From: shamik chakrabartishamikphy at gmail.com Subject: struct file of Fe To: swati chaudhuryswati at rcais.res.in Date: Wednesday, 21 April, 2010, 10:27 AM Dear Swati Madam, Can you please send me the Fe struct file by which you have performed volume optimization. I am still not able to performe the volume optimization for both fcc Ni and bcc Fe with spin polarization. Without spin polarization it is performing well!..looking forward to you. with regards, Shamik Chakrabarti ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] [Wien2k Users] Internal Coordinates Minimization of Supercells: Correlation of forces in Supercell and actual cell
Dear Wien2k users, I seek the following clarification on the minimization of forces for supercells alone. We think of a compound with some doping or with some alloying elements. It is for the user to decide what positions these dopants or alloying elements are occupying. So we construct the supercell for this case and make some suitable changes (only changing the atomic positions of elements) and run through the initialization. In this process, the space group changes, for example it changes from P63/mmm_191 to Pmma_51. We run through run_lapw Then do a structure optimization. Then we run through internal coordinates minimization. The forces are minimized in Pmma_51 and not in P63/mmm using NEW1 and 0.50 as TOLF. Our choice of atomic positions was respect to P63/mmm and with respect to Pmma. So, how do justify that in this case, we minimize the forces in the actual lattice P63/mmm. Has anybody given it a thought or my logic is not at all considering? Any suggestions -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100421/c720111e/attachment.htm
[Wien] struct file of Fe
Of course, an experienced user can play many tricks and shortcuts, but your advise is incomplete. x symmetry produces a file case.struct_st which contains the updated symmetry operations. Thus, without init_lapw you have to copy this file to case.struct, otherwise the symmetry operations will not be present. One more warning: x optimize uses case_initial.struct (if it exists) and not case.struct. Thus, changing case.struct (most likely it also has wrong lattice parameters because you attempted to run optimize.job) does not help, but you have to update (or remove) case_initial.struct Maxim Rakitin schrieb: Hi Shamik, Swaty, I met this problem some time ago. As it turned out, it's enough to run 'x symmetry' to add correct symmetry operations to case.struct file. You don't need to perform full init operation for it. Best regards,Maxim RakitinPostgraduate studentSouth Ural State University,76 Lenin av., Chelyabinsk, Russia, 454080Email: rms85 at physics.susu.ac.ruWeb: http://www.susu.ac.ru 21.04.2010 12:06, swati chaudhury ?: Hi shamik, Your structure file is wrong because no of symmetry operation is zero. You have to do init_lapw properly. If not works, i will send you the structure file. swati --- On Wed, 21/4/10, shamik chakrabartishamikphy at gmail.com wrote: From: shamik chakrabartishamikphy at gmail.com Subject: struct file of Fe To: swati chaudhuryswati at rcais.res.in Date: Wednesday, 21 April, 2010, 10:27 AM Dear Swati Madam, Can you please send me the Fe struct file by which you have performed volume optimization. I am still not able to performe the volume optimization for both fcc Ni and bcc Fe with spin polarization. Without spin polarization it is performing well!..looking forward to you. with regards, Shamik Chakrabarti ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___Wien mailing listWien at zeus.theochem.tuwien.ac.athttp://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] Fermi contact chemical shift
Dear Wien2K users, now I am going to calculate the NMR-Fermi contact chemical shift of Li ions in the material (with magnetic Ni ions). In the spin-polarization calculation of Wien2K. we can only obtain the hyperfine field (HFF) near the Li nucleus. In order to get the chemical shift, we need to get the hyperfine coupling constant A between Li and Ni. The equation for A is A=u0(magnetic permability)*h(planck constant)*r(nucleus gyromag ration)*g(electron g factor)*uB(Bohr magneton)*?(spin density at the nucleus)/(3S)(S is the spin quantum number of Ni)?If we obtained A, the we can get the Fermi contact chemical shift?=A*g*uB*S*(S+1)/(3*h*r*KT), where K is Boltzmann constant and T is temperature. Then the key question is to obtain the spin density at or near the neclues Li. So can we directly use the the spin density from the item spindensities at the nucleuse(Thomson) or the difference between spin up and spin down electron density (RUP**-RDN**)in the scf file?(I have tested this, but the calculated chemical shift seems several orders of magnitude smaller than the experiment value) Furthermore, If there are two kinds of Ni ions near the Li, the situatioin is complex. There should be two coupling constant A1 and A2 between Li and different Ni ions. Then how to get these two coupling constantn , respectively? Can we first to let one magnetic ion(for example, Ni1) to be magnetic, and force other magnetic ion to be nonmagnetic(Ni2), and get the corresponding spin density near the Li nucleus to calculate the corresponding A1 for Ni1, and do the similar process for Ni2 to obtain its coupling constant A2? I have browsed the mailing list archives and the userguide, but cannot find the answer. So I will much appreciate that if someone can help me. Best regards Zhang _ http://cn.bing.com/search?q=%E5%A4%A9%E6%B0%94%E9%A2%84%E6%8A%A5form=MICHJ2 -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100421/a066ef6b/attachment.htm
[Wien] Electron density at the nucleus (Electron capture nuclear decay rate work)
There is no physics involved in constraining the 1s wavefuction to zero at an arbitrary radius RMT. It is anyway constrained to be zero at r=infinity and only this is meaningful. It seems pretty clear that the results are as they are, whether you like it or not. If you want to cheat the results, you could do a frozen core, i.e. after init_lapw you do: x lapw0-- creates a potential from superposed atomic densities x lcore-- create the core density rm case.inc -- remove the input file to prevent recalculation of core states run_lapw Of course, for consistency you should never change sphere sized when you compare densities. Amlan Ray schrieb: Dear Prof. Marks, I am writing in reply to your suggestion dated April 19, 2010 on the above subject. The RMT(Be) was always larger than RMT(O). I used RMT(Be)=1.45 BU and RMT(O)=1.23 BU. Later on, I used up to RMT(Be)=1.58 BU and RMT(O)= 1.1 BU. As RMT(Be) is increased from 1.45 to 1.58 for BeO(Normal case), the 1s electron density at Be nucleus increases very slightly by 0.0158% and the total electron density at the Be nucleus increases by 0.014%. However when the calculation is repeated for the compressed BeO, keeping RMT(Be)=1.58 or less, the 1s electron density at the Be nucleus always decreases and 2s electron density at Be nucleus always increases, the net result is about 0.1% increase of the total electron density at the nucleus due to about 9% volume compression of BeO lattice, against the experimental number of 0.6%. My problem is regarding the reduction of 1s electron density at Be nucleus due to the compression. As per your suggestion, I have checked out the leakage of 1s electron charge from the Be muffintin sphere. I subtracted out the total 2s valence charge in Be sphere (CHA001) from the total charge (CTO001) in Be sphere to obtain the 1s charge in Be sphere. So CTO001-CHA001 = 1s charge in Be sphere. I kept RMT(Be)=1.45 BU fixed for both the uncompressed and compressed cases and studied the 1s charge leakage from Be sphere. I find 1) for 9% volume compression of BeO, leakage of 1s charge from Be sphere = 0.01%; reduction of 1s electron density at Be nucleus due to compression = 0.148%. 2) for 16.6% volume compression of BeO, leakage of 1s charge from Be sphere=0.018%; reduction of 1s electron density at Be nucleus due to compression = 0.265%. 3) for 28.4% volume compression of BeO, leakage of 1s charge from Be sphere = 0.033%; reduction of 1s electron density at Be nucleus due to compression = 0.466%. If I fix RMT(Be)=1.58 BU for all the calculations, then 1) for 9% volume compression of BeO, leakage of 1s charge from Be sphere = 0.004%; reduction of 1s electron density at Be nucleus due to compression = 0.15%. 2) for 16.6% volume compression of BeO, 1s charge leakage from Be sphere =0.011%; reduction of 1s electron density at Be nucleus due to compression = 0.265%. So as the compression on BeO lattice is increased, Hartree potential increases and the character of the 1s electron wave function of Be changes. The 1s wave function becomes more defused and spread out and so the leakage from the Be sphere increases with the compression. Since the free atom 1s wave function becomes more defused and spread out due to the compression, the 1s electron density at Be nucleus decreases. Now if a boundary condition such as 1s wave function must be zero at RMT(Be) is put on, then the compression will not cause the spread out of the wave function. WIEN2K suggests that we should use a smaller value of RMT(Be) when BeO lattice is compressed. This should increase the 1s electron density at the nucleus, if the wave function is constrained to be zero at RMT(Be). The absolute percentage of the 1s charge leakage from Be sphere might be small, but it tends to increase very quickly with the compression. I think if the 1s wave function is constrained to be zero at RMT=1.45 or 1.58, then that can influence the change of 1s electron density at Be nucleus under compression by the fraction of a percent. In the case of 2s valence electrons of Be, I find that when RMT(Be) is kept fixed at 1.45 BU, then 2s valence charge in Be sphere increases from 0.1943 to 0.2213 for 16.6% volume compression of BeO. The 2s electron density at Be nucleus also increases due to the compression. 2s electron wave function satisfies an appropriate boundary condition at RMT and that may be the part of the reason for the increase of 2s electron density under compression. So my suggestion is to kindly consider putting a boundary condition such as 1s Be wave function = 0 at RMT(Be). Such a boundary condition should affect the character of the wave function and hence the change of 1s electron density at the nucleus due to the compression. With best regards Amlan Ray
[Wien] Electron density at the nucleus (Electron capture nuclear decay rate work)
A few comments, and perhaps a clarification on what Peter said. Remember that while Wien2k is more accurate than most other DFT codes, it still has approximations with the form of the exchange-correllation potential and in how the core wavefunctions are calculated. Hacking by applying unphysical constraints so it will match experiments is wrong. (Remember the story of the graduate student who matched all properties of silicon by tuning the parameters of the DFT calculation for each one so it was right.) I would instead suggest that you look at better functionals for the core wavefunctions, see Novak et al, Phys. Rev. B 67, 140403(R) (2003) as well as the papers that cite it and the earlier paper by U. Lundin and O. Eriksson, Int. J. Quantum Chem. 81, 247 (2001) and papers that cite this. If you ask Peter or Pavel really nicely they may be able to provide the code that uses this functional but you will almost certainly have to do some coding work. This might not explain your experimental results, and if it does not either the experiments are wrong or we just don't have good enough theory yet for what you are measuring, probably the latter. On Wed, Apr 21, 2010 at 6:48 AM, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: There is no physics involved in constraining the 1s wavefuction to zero at an arbitrary radius RMT. It is anyway constrained to be zero at r=infinity and only this is meaningful. It seems pretty clear that the results are as they are, whether you like it or not. If you want to cheat the results, you could do a frozen core, i.e. after init_lapw you do: x lapw0 ? ?-- creates a potential from superposed atomic densities x lcore ? ?-- create the core density rm case.inc -- remove the input file to prevent recalculation of core states run_lapw Of course, for consistency you should never change sphere sized when you compare densities. Amlan Ray schrieb: Dear Prof. Marks, I am writing in reply to your suggestion dated April 19, 2010 on the above subject. The RMT(Be) was always larger than RMT(O). I used RMT(Be)=1.45 BU and RMT(O)=1.23 BU. Later on, I used up to RMT(Be)=1.58 BU and RMT(O)= 1.1 BU. As RMT(Be) is increased from 1.45 to 1.58 for BeO(Normal case), the 1s electron density at Be nucleus increases very slightly by 0.0158% and the total electron density at the Be nucleus increases by 0.014%. However when the calculation is repeated for the compressed BeO, keeping RMT(Be)=1.58 or less, the 1s electron density at the Be nucleus always decreases and 2s electron density at Be nucleus always increases, the net result is about 0.1% increase of the total electron density at the nucleus due to about 9% volume compression of BeO lattice, against the experimental number of 0.6%. ?My problem is regarding the reduction of 1s electron density at Be nucleus due to the compression. As per your suggestion, I have checked out the leakage of 1s electron charge from the Be muffintin sphere. I subtracted out the total 2s valence charge in Be sphere (CHA001) from the total charge (CTO001) in Be sphere to obtain the 1s charge in Be sphere. So CTO001-CHA001 = 1s charge in Be sphere. I kept RMT(Be)=1.45 BU fixed for both the uncompressed and compressed cases and studied the 1s charge leakage from Be sphere. I find 1) for 9% volume compression of BeO, leakage of 1s charge from Be sphere = 0.01%; reduction of 1s electron density at Be nucleus due to compression = 0.148%. 2) for 16.6% volume compression of BeO, leakage of 1s charge from Be sphere=0.018%; reduction of 1s electron density at Be nucleus due to compression = 0.265%. 3) for 28.4% volume compression of BeO, leakage of 1s charge from Be sphere = 0.033%; reduction of 1s electron density at Be nucleus due to compression = 0.466%. ?If I fix RMT(Be)=1.58 BU for all the calculations, then 1) for 9% volume compression of BeO, leakage of 1s charge from Be sphere = 0.004%; reduction of 1s electron density at Be nucleus due to compression = 0.15%. 2) for 16.6% volume compression of BeO, 1s charge leakage from Be sphere =0.011%; reduction of 1s electron density at Be nucleus due to compression = 0.265%. ?So as the compression on BeO lattice is increased, Hartree potential increases and the character of the 1s electron wave function of Be changes. The 1s wave function becomes more defused and spread out and so the leakage from the Be sphere increases with the compression. Since the free atom 1s wave function becomes more defused and spread out due to the compression, the 1s electron density at Be nucleus decreases. Now if a boundary condition such as 1s wave function must be zero at RMT(Be) is put on, then the compression will not cause the spread out of the wave function. WIEN2K suggests that we should use a smaller value of RMT(Be) when BeO lattice is compressed. This should increase the 1s electron density at the nucleus, if the wave function is constrained to be zero at RMT(Be). The
[Wien] Electron density at the nucleus (Electron capture nuclear decay rate work)
let me comment. I do not recommend to use the Lundin-Eriksson functional. While the contact hyperfine field for 3d atoms is improved, we realized that it violates important sum rule for the exchange-correlation hole, which is imposed by the density functional theory. This brings several shortcomings e.g. incorrect energy of the core states. I doubt that any local or semilocal Vxc can provide reliable value of the core density at the nucleus. For bcc Fe Akai and Kotani (Hyperfine Interactions, 120/121, 3, 1999 obtained good contact field using the optimised effective potential method, but this is computationally expensive. Regards Pavel Novak On Wed, 21 Apr 2010, Laurence Marks wrote: A few comments, and perhaps a clarification on what Peter said. Remember that while Wien2k is more accurate than most other DFT codes, it still has approximations with the form of the exchange-correllation potential and in how the core wavefunctions are calculated. Hacking by applying unphysical constraints so it will match experiments is wrong. (Remember the story of the graduate student who matched all properties of silicon by tuning the parameters of the DFT calculation for each one so it was right.) I would instead suggest that you look at better functionals for the core wavefunctions, see Novak et al, Phys. Rev. B 67, 140403(R) (2003) as well as the papers that cite it and the earlier paper by U. Lundin and O. Eriksson, Int. J. Quantum Chem. 81, 247 (2001) and papers that cite this. If you ask Peter or Pavel really nicely they may be able to provide the code that uses this functional but you will almost certainly have to do some coding work. This might not explain your experimental results, and if it does not either the experiments are wrong or we just don't have good enough theory yet for what you are measuring, probably the latter. --
