Re: [Wien] ELF
Hello, since I see that VASP results are being discussed here, I'd like to bring your attention to my communication with the VASP developers in April this year: https://www.vasp.at/forum/viewtopic.php?f=3=18484 where they admitted that "the current implementation depends strongly on the choice of the POTCAR. You can test this by using the GW POTCAR and will find contributions from Ni 3d electrons. We believe that with this pseudo-potential dependent ELF is not a good measure for electronic localisation and thus want to replace this (very old) implementation in a future release." which means that ELF calculated in the current version (and all earlier versions, apparently) of VASP can have errors and should not be used as a gold standard. I think they still have not fixed that bug according to https://www.vasp.at/forum/viewtopic.php?f=4=18628=22510=elf#p22510 Best, Kateryna On 2022-11-04 13:11, reyhaneh ebrahimi wrote: [CAUTION: Non-UBC Email] Dear Prof. Blaha Thank you for your valuable answer to my Email. I put my ELF graph, your ELF results, and Jiawang and Olivier' graph for SnSe on one page to have a better comparison, see "https://www.mediafire.com/file/kyfi46ppx6mhtnx/SnSe-final.jpg/file;. I also specified the plane which I did my ELF calculation on it. Therefore, as you mentioned in your Email, the existing differences between my graph, your graph, and Jiawang and Olivier' graph would be due to the choice of different planes in these works. Sincerely yours Reyhaneh Ebrahimi On Fri, Nov 4, 2022 at 8:33 AM Peter Blaha wrote: Sorry: the links should be: SnSe, not SnGe http://www.wien2k.at/Depository/SnSe-f.png http://www.wien2k.at/Depository/SnSe-g.jpg http://www.wien2k.at/Depository/SnSe-t.png Am 04.11.2022 um 15:27 schrieb Peter Blaha: Your picture for SnSe is probably in a different plane as compared to the 4 pictures in the paper. I produced 2 elf pictures, which resembles the planes in Fig. 6f and 6g. They look as expected. In the interstital identical (see eg. the 2 different blue features in 6f), but inside the spheres quite different because of the pseudopotentials. I guess it is a general feature that inside spheres (and for heavier atoms) the PP ELF is nonsense. You can download them at: http://www.wien2k.at/Depository/SnGe-f.png http://www.wien2k.at/Depository/SnGe-g.jpg http://www.wien2k.at/Depository/SnGe-t.png Am 04.11.2022 um 00:13 schrieb reyhaneh ebrahimi: Dear Prof. Blaha I apologize. Let me make my previous Email a little more complete. As you mentioned in your Email, for SnS the sources of differences between the results of ELF using WIEN2k code and VASP code is due to the difference between all-electron and pseudopotentials calculations in these two codes. However, I am still not sure that the differences between my results for the ELF of SnSe and Jiawang and Olivier's paper are normal or not. I would be glad if you let me know your opinion about this subject. Sincerely yours Reyhaneh Ebrahimi On Thu, Nov 3, 2022 at 1:13 PM Peter Blaha <mailto:peter.bl...@tuwien.ac.at>> wrote: Good to hear that this has been resolved. PS: I just did a SnSe calc. and compared with the VASP paper. Similarly, very good agreement in the interstitial, while inside the atomic cores there is the expected difference between all-electron and pseudopotentials. Am 03.11.2022 um 21:06 schrieb Kateryna Foyevtsova: Dear Prof. Blaha, I think I know what's going on with ELF. Wien2k gets it correctly, but Quantum Espresso has a bug which shows up in nspin=1 calculations. In the attached figure I compare the wien2k result with two QE calculations: (1) one with nspin=1 switch and (2) one with nspin=2 switch. In both cases I am looking at the same non-magnetic solution that has the same energy in the two QE calculations. Now you see that the difference between QE nspin=1 and nspin=2 is dramatic whereas there should be none. The wien2k result looks very similar to the QE nspin=2 result in the interstitial region at 0.5,0.5,0.0, marked with a big purple "X". There are differences close to atomic nuclei but this is expected given that we are comparing an all-electron and a pseudo-potenial code. Thank you very much for helping me resolve this issue. Best, Kateryna On 2022-11-02 12:21, Peter Blaha wrote: [CAUTION: Non-UBC Email] My result looks like the attached picture. I do get 0.8 in the core region of Ni, but not larger than that. It is probably similar than yours. I have no idea why it is different from QE, except maybe that these are pseudopotential calc. As I said before, you should compare other compounds, and also compare with literature ELF calculations. Am 01.11.2022 um 21:16 schrieb Kateryna Foyevtsova: Dear Prof. Blaha, thank you for looking into this issue. I've tried the modified create_rho.f and calculated the ELF of NdNiO2 again using create_elf
Re: [Wien] ELF
Dear Prof. Blaha, I think I know what's going on with ELF. Wien2k gets it correctly, but Quantum Espresso has a bug which shows up in nspin=1 calculations. In the attached figure I compare the wien2k result with two QE calculations: (1) one with nspin=1 switch and (2) one with nspin=2 switch. In both cases I am looking at the same non-magnetic solution that has the same energy in the two QE calculations. Now you see that the difference between QE nspin=1 and nspin=2 is dramatic whereas there should be none. The wien2k result looks very similar to the QE nspin=2 result in the interstitial region at 0.5,0.5,0.0, marked with a big purple "X". There are differences close to atomic nuclei but this is expected given that we are comparing an all-electron and a pseudo-potenial code. Thank you very much for helping me resolve this issue. Best, Kateryna On 2022-11-02 12:21, Peter Blaha wrote: [CAUTION: Non-UBC Email] My result looks like the attached picture. I do get 0.8 in the core region of Ni, but not larger than that. It is probably similar than yours. I have no idea why it is different from QE, except maybe that these are pseudopotential calc. As I said before, you should compare other compounds, and also compare with literature ELF calculations. Am 01.11.2022 um 21:16 schrieb Kateryna Foyevtsova: Dear Prof. Blaha, thank you for looking into this issue. I've tried the modified create_rho.f and calculated the ELF of NdNiO2 again using create_elf. I am getting a better agreement with QE, but it is not perfect as you noted it too. My calculation was well converged and I used the same k-grid and RKmax=7. The bandstructures from QE and wien2k agree very well. I attach my comparison as a png file. I wonder whether you have any idea about the possible reasons for the differences in ELF that the two codes give? For example, at 0.5,0.5,0 the wien2k value is ~0.22 and the QE value is ~0.43. Thank you, Kateryna On 2022-10-28 04:43, Peter Blaha wrote: [CAUTION: Non-UBC Email] Dear Kateryna , In fact, I found a big difference between create_elf and x lapw0 (with VX_ELF); x lapw5 -exchange I traced it back to normalization errors in tau_w and tau_tf, which missed a factor of 2. The attached create_rho.f fixes the problem. It should be copied into SRC_trig; make Then you can use create_elf again. PS: I would always compare the ELF created with both methods as indicated above. Depending on the numerics, one or the other method may give smoother plots, but in any case, they should be very similar. PPS: The agreement to QE-ELF seems reasonable (but not perfect), but I've not converged my calculations. Thanks for the report Peter Blaha I attach a pdf showing the differences. Also attached are my wien2k >struct file and quantum espresso input file. Both calculations were done without spin polarization and using PBE. To me, the differences are big enough to question whether it is >meaningful to use ELF at all if it depends on all-electron vs >pseudopotential so strongly. Unless I am missing something or doing >something wrong. Thank you, Kateryna ___ 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 ___ 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] ELF
Dear Prof. Blaha, thank you for looking into this issue. I've tried the modified create_rho.f and calculated the ELF of NdNiO2 again using create_elf. I am getting a better agreement with QE, but it is not perfect as you noted it too. My calculation was well converged and I used the same k-grid and RKmax=7. The bandstructures from QE and wien2k agree very well. I attach my comparison as a png file. I wonder whether you have any idea about the possible reasons for the differences in ELF that the two codes give? For example, at 0.5,0.5,0 the wien2k value is ~0.22 and the QE value is ~0.43. Thank you, Kateryna On 2022-10-28 04:43, Peter Blaha wrote: [CAUTION: Non-UBC Email] Dear Kateryna , In fact, I found a big difference between create_elf and x lapw0 (with VX_ELF); x lapw5 -exchange I traced it back to normalization errors in tau_w and tau_tf, which missed a factor of 2. The attachedcreate_rho.f fixes the problem. It should be copied into SRC_trig; make Then you can usecreate_elf again. PS: I would always compare the ELF created with both methods as indicated above. Depending on the numerics, one or the other method may give smoother plots, but in any case, they should be very similar. PPS: The agreement to QE-ELF seems reasonable (but not perfect), but I've not converged my calculations. Thanks for the report Peter Blaha I attach a pdf showing the differences. Also attached are my wien2k >struct file and quantum espresso input file. Both calculations were done without spin polarization and using PBE. To me, the differences are big enough to question whether it is >meaningful to use ELF at all if it depends on all-electron vs >pseudopotential so strongly. Unless I am missing something or doing >something wrong. Thank you, Kateryna ___ 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 -- Kateryna Foyevtsova, PhD Research Associate Stewart Blusson Quantum Matter Institute The University of British Columbia | Vancouver 261C - 2355 East Mall | Vancouver BC | V6T 1Z4 Canada Phone +1 (604) 822-8545 foyevts...@phas.ubc.ca www.sbqmi.ubc.ca___ 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] ELF
mailto:Wien@zeus.theochem.tuwien.ac.at>> > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien <http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien> > <http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien <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 <http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html> <http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html <http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html>> > > > ___ > 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 <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 <http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html> -- -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 Email: peter.bl...@tuwien.ac.at <mailto:peter.bl...@tuwien.ac.at> WIEN2k: http://www.wien2k.at <http://www.wien2k.at> WWW: http://www.imc.tuwien.ac.at <http://www.imc.tuwien.ac.at> - ___ 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 <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 <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 -- Kateryna Foyevtsova, PhD Research Associate Stewart Blusson Quantum Matter Institute The University of British Columbia | Vancouver 261C - 2355 East Mall | Vancouver BC | V6T 1Z4 Canada Phone +1 (604) 822-8545 foyevts...@phas.ubc.ca www.sbqmi.ubc.ca ___ 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] possible bug in orb
Dear wien2k developers, I think there is a bug in orb which shows up when a Hubbard U is being applied to L=1 (p) electrons. In Vcalc.f, no value is assigned for F(2) for the L=1 case. This will give that, for example, in a case of case.inorb like the one below: 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing 2 1 2 iatom nlorb, lorb 3 1 1 4 1 1 1 nsic 0..AFM, 1..SIC, 2..HFM 0.882 0.074 0.000 0.000 0.000 0.000 the atoms 3 and 4 will contribute non-zero EORB as well as will have some non-zero orbital potential matrices, because for these atoms the code is going to use F(2) taken over from atom 2. Thank you, Kateryna -- Kateryna Foyevtsova Research Associate Stewart Blusson Quantum Matter Institute The University of British Columbia | Vancouver 261C - 2355 East Mall | Vancouver BC | V6T 1Z4 Canada foyevts...@phas.ubc.ca www.sbqmi.ubc.ca ___ 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] LDA+U: around mean field
Dear Wien2k experts, should one use Ueff=U-J, J=0 also in the 'around mean field' DC correction scheme (option 0 in case.inorb)? Thanks! Kateryna Foyevtsova
[Wien] Plotting the .rho file
My personal favourite way of plotting 3D electron isosurfaces is 1) to use the xcrysden interface to calculate the electron density with lapw5 2) to save the result as an xsf file in xcrysden 3) to open the xsf file by VESTA and produce a nice figure there (I find that VESTA offers more freedom than xcrysden in some cases) For this procedure to work you need to make xcrysden generate the electron density data strictly within the unit cell. On 21/08/12 00:03, Joshua Davis wrote: Hey Wien2K Users I just have a general question about the density generated by lapw 5. Do any of you have any recommendations for plotting the .rho data outputted by this program, preferably something other that gnuplot or xcrysden. I have also tried the method shown here at http://www.nims.go.jp/cmsc/staff/arai/wien/venus.html, but it has been unfruitful. other info: Our Wien2K is 11.1 and it was compiled with gfortran 4.6.1on Ubuntu 12.04 Our hardware consists of 24 6-core processors with 48 Gbs of ram and 48 Gbs of scratch. I believe our BLAS library is the one supplied with Wien2K. any suggestions would be appreciated Josh ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] ERROR: negative position
Dear Gavin, I am also getting this message ERROR: negative position in rstruc. Please report for the structure I append below. Could you give a hint what is the problem and what should I fix to get rid of it? I am using version 12.1. Thanks! Kateryna Foyevtsova blebleble CXZ LATTICE,NONEQUIV.ATOMS: 6 12 C2/m MODE OF CALC=RELA unit=bohr 10.299379 11.320134 17.839048 90.00 89.99127.340625 ATOM 1: X=0. Y=0. Z=0.5000 MULT= 1 ISPLIT= 8 Na1NPT= 781 R0=0.0001 RMT=2.0900 Z: 11.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.5002 Y=0.5002 Z=0.6667 MULT= 2 ISPLIT= 8 2: X=0.4998 Y=0.4998 Z=0. Na2NPT= 781 R0=0.0001 RMT=2.0900 Z: 11.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.5002 Y=0.5002 Z=0. MULT= 1 ISPLIT= 8 Na3NPT= 781 R0=0.0001 RMT=2.0900 Z: 11.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. Y=0. Z=0.8333 MULT= 2 ISPLIT= 8 4: X=0. Y=0. Z=0.1667 Ir1NPT= 781 R0=0.0500 RMT=2.0500 Z: 77.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.9734 Y=0.2100 Z=0.3334 MULT= 4 ISPLIT= 8 5: X=0.0266 Y=0.7900 Z=0.3334 5: X=0.0266 Y=0.7900 Z=0. 5: X=0.9734 Y=0.2100 Z=0. O 1NPT= 781 R0=0.0001 RMT=1.8200 Z: 8.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.4733 Y=0.2100 Z=0.5000 MULT= 2 ISPLIT= 8 6: X=0.5267 Y=0.7900 Z=0.5000 O 2NPT= 781 R0=0.0001 RMT=1.8200 Z: 8.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 4 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0. 0 1 0 0. 0 0 1 0. 1 -1 0 0 0. 0-1 0 0. 0 0 1 0. 2 -1 0 0 0. 0-1 0 0. 0 0-1 0. 3 1 0 0 0. 0 1 0 0. 0 0-1 0. 4 On 09/08/12 14:58, Gavin Abo wrote: What version of Wien2k are you using (cat $WIENROOT/VERSION)? Maybe you are not using the latest 12.1 with the fix in SRC_symmetry described at http://www.wien2k.at/reg_user/updates/. On 8/9/2012 2:05 AM, Mojtaba Zareii wrote: Hi dear Prof. Blaha I want to simulate the LaNi4.5Sn0.5H2.5 compound. To do this, first I created the Struct file (case.struct) for LaNi5 compound and then used supercell prog to substitute Ni by Sn (sepercell 1*1*2). Then I wanted to put hydrogen atoms into the lattice structure created from the previous stage. After putting H atoms at proper coordinates, I followed the initialize stage to wien2k program find proper space group. In this stage x nn complains and creates new struct files. Accepted them and repeated this, until nn does not find any error. But in next stage, for X Symmetry stage an error stop the program to be continued as follows: ERROR: negative position in rstruc. Please report 0.004u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w I have before seen such error which is due to rounding errors some positions e.g. 0.50001 Or 0.24 when I used supercell prog, But I could not solve this problem for this compound (I did it for one atomic position as follows: I changed x=0.1360 and Y=0.2720 coordinates to X=0.135 and Y=0.27, but it did not solve the problem). Could you please help me to solve this problem? I have sent the struct files for LaNi4.5Sn0.5H2.5 and LaNi5 compounds which are used during this simulation. Thank you Your Kindness will be appreciated in Advance ___ 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
[Wien] ERROR: negative position
Thanks! eventually, converting the structure to .cif file using Vesta and then back with cif2struct plus running sgroup fixed the problem. Was the error message due to the old way of listing structural data being incompatible with wien2k expectations? What does it mean: negative position in rstruc? Bests, Kateryna On 10/08/12 11:56, Fecher, Gerhard wrote: Check beta check position of ATOM 3 are these correct ? Ciao Gerhard DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy: I think the problem, to be quite honest with you, is that you have never actually known what the question is. Dr. Gerhard H. Fecher Institut of Inorganic and Analytical Chemistry Johannes Gutenberg - University 55099 Mainz Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at]quot; im Auftrag von quot;Kateryna Foyevtsova [foyevtsova at th.physik.uni-frankfurt.de] Gesendet: Freitag, 10. August 2012 10:33 An: A Mailing list for WIEN2k users Betreff: Re: [Wien] ERROR: negative position Dear Gavin, I am also getting this message ERROR: negative position in rstruc. Please report for the structure I append below. Could you give a hint what is the problem and what should I fix to get rid of it? I am using version 12.1. Thanks! Kateryna Foyevtsova blebleble CXZ LATTICE,NONEQUIV.ATOMS: 6 12 C2/m MODE OF CALC=RELA unit=bohr 10.299379 11.320134 17.839048 90.00 89.99127.340625 ATOM 1: X=0. Y=0. Z=0.5000 MULT= 1 ISPLIT= 8 Na1NPT= 781 R0=0.0001 RMT=2.0900 Z: 11.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.5002 Y=0.5002 Z=0.6667 MULT= 2 ISPLIT= 8 2: X=0.4998 Y=0.4998 Z=0. Na2NPT= 781 R0=0.0001 RMT=2.0900 Z: 11.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.5002 Y=0.5002 Z=0. MULT= 1 ISPLIT= 8 Na3NPT= 781 R0=0.0001 RMT=2.0900 Z: 11.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. Y=0. Z=0.8333 MULT= 2 ISPLIT= 8 4: X=0. Y=0. Z=0.1667 Ir1NPT= 781 R0=0.0500 RMT=2.0500 Z: 77.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.9734 Y=0.2100 Z=0.3334 MULT= 4 ISPLIT= 8 5: X=0.0266 Y=0.7900 Z=0.3334 5: X=0.0266 Y=0.7900 Z=0. 5: X=0.9734 Y=0.2100 Z=0. O 1NPT= 781 R0=0.0001 RMT=1.8200 Z: 8.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.4733 Y=0.2100 Z=0.5000 MULT= 2 ISPLIT= 8 6: X=0.5267 Y=0.7900 Z=0.5000 O 2NPT= 781 R0=0.0001 RMT=1.8200 Z: 8.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 4 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0. 0 1 0 0. 0 0 1 0. 1 -1 0 0 0. 0-1 0 0. 0 0 1 0. 2 -1 0 0 0. 0-1 0 0. 0 0-1 0. 3 1 0 0 0. 0 1 0 0. 0 0-1 0. 4 On 09/08/12 14:58, Gavin Abo wrote: What version of Wien2k are you using (cat $WIENROOT/VERSION)? Maybe you are not using the latest 12.1 with the fix in SRC_symmetry described at http://www.wien2k.at/reg_user/updates/. On 8/9/2012 2:05 AM, Mojtaba Zareii wrote: Hi dear Prof. Blaha I want to simulate the LaNi4.5Sn0.5H2.5 compound. To do this, first I created the Struct file (case.struct) for LaNi5 compound and then used supercell prog to substitute Ni by Sn (sepercell 1*1*2). Then I wanted to put hydrogen atoms into the lattice structure created from the previous stage. After putting H atoms at proper coordinates, I followed the initialize stage to wien2k program find proper space group. In this stage x nn complains and creates new struct files. Accepted them and repeated this, until nn does not find any error. But in next stage, for X Symmetry stage an error stop the program to be continued as follows: ERROR: negative position in rstruc. Please
[Wien] wien
Hi, according to the wien2k web page http://www.wien2k.at/reg_user/limitations/ calculation of forces with spin-orbit is not yet implemented. On 07/08/12 16:05, Alexey Korshunov wrote: Prof. Blaha and wien users. I am running wien version 11.1 on a intel core i7 machine with Mandriva 2010 operating system, fortran compiler ifort 11.1 and math libraries mkl 10. The purpose of my calculations is to get forces to perfom surface structure relaxation. I am calculating tungsten slab with the following initial structure W_surface CXY LATTICE,NONEQUIV.ATOMS: 765_Cmmm MODE OF CALC=RELA unit=bohr 5.981401 8.458979 84.589790 90.00 90.00 90.00 ATOM -1: X=0. Y=0. Z=0. MULT= 1 ISPLIT= 8 W 1NPT= 781 R0=0.0500 RMT=2.2000 Z: 74.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.5000 Y=0. Z=0.0500 MULT= 2 ISPLIT= 8 -2: X=0.5000 Y=0. Z=0.9500 W 2NPT= 781 R0=0.0500 RMT=2.2000 Z: 74.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. Y=0. Z=0.1000 MULT= 2 ISPLIT= 8 -3: X=0. Y=0. Z=0.9000 W 3NPT= 781 R0=0.0500 RMT=2.2000 Z: 74.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.5000 Y=0. Z=0.1500 MULT= 2 ISPLIT= 8 -4: X=0.5000 Y=0. Z=0.8500 W 4NPT= 781 R0=0.0500 RMT=2.2000 Z: 74.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. Y=0. Z=0.2000 MULT= 2 ISPLIT= 8 -5: X=0. Y=0. Z=0.8000 W 5NPT= 781 R0=0.0500 RMT=2.2000 Z: 74.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.5000 Y=0. Z=0.2500 MULT= 2 ISPLIT= 8 -6: X=0.5000 Y=0. Z=0.7500 W 6NPT= 781 R0=0.0500 RMT=2.2000 Z: 74.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. Y=0. Z=0.3000 MULT= 2 ISPLIT= 8 -7: X=0. Y=0. Z=0.7000 W 7NPT= 781 R0=0.0500 RMT=2.2000 Z: 74.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 8 NUMBER OF SYMMETRY OPERATIONS using GGA PBE XC potential, spin-orbit interaction without spin polarization, RKmax=7, k-mesh=2000. The commandline is run_lapw -p -so -cc 0.1 -ec 0.0001 -fc 1.0 -i 120 -r 20. There is the force result of last two iterations: :ITE069: 69. ITERATION TOTAL FORCE WITH RESPECT TO THE GLOBAL COORDINATE SYSTEM: :FGL001: 1.ATOM 0.0 0.0 0.0 partial forces :FGL002: 2.ATOM 0.0 0.0 3.03500 partial forces :FGL003: 3.ATOM 0.0 0.0 2.95600 partial forces :FGL004: 4.ATOM 0.0 0.0 16.24700 partial forces :FGL005: 5.ATOM 0.0 0.0 79.30600 partial forces :FGL006: 6.ATOM 0.0 0.0 5.08100 partial forces :FGL007: 7.ATOM 0.0 0.0 828.27700 partial forces :ITE070: 70. ITERATION TOTAL FORCE WITH RESPECT TO THE GLOBAL COORDINATE SYSTEM: :FGL001: 1.ATOM 0.0 0.0 0.0 total forces :FGL002: 2.ATOM 0.0 0.0 289.94700 total forces :FGL003: 3.ATOM 0.0 0.0 123.01500 total forces :FGL004: 4.ATOM 0.0 0.0 72.39700 total forces :FGL005: 5.ATOM 0.0
[Wien] v12: SRC_lapwso: init.f fix
Dear Wien2k developers, v12 of Wien2k has a severe bug fix for LDA+U calculations with complex vorb potential in SRC_lapwso: init.f. How severe was that bug and in which cases did it show up? What is meant by complex vorb potential? Best regards, Kateryna Foyevtsova P.S. For a monoclinic system with orbital degeneracy, LDA+U+SO calculations with version 12 give very different DOS, orbital occupations, orbital moments (this one partially due to a fix in SRC_lapwdm) and electron density isosurfaces, compared to the results obtained with version 11.
[Wien] initso and case.indmc/case.inorb
Dear wien2k developers, while running initso_lapw, the following suggestion appears in the end: Please adapt case.indm(c) manually and copy it to case.indmc Please adapt case.inorb manually Could you please hint what exactly kind of adaptations in case.indm and case.inorb is meant here? Thanks a lot! Best regards, Kateryna Foyevtsova
[Wien] spin and orbital moments
Dear Gavin, thanks a lot for your detailed answer and the very useful links! If ORBxxx and SPIxxx are in CCS, how to explain the fact that for, eg, SPI005 in the first iteration sqrt(0.46560**2 + 0.80642**2 + 0.53749**2) = 1.075 ie, exactly the projection on the M axis. I would not expect that if 0.46560, 0.80642 and 0.53749 were projections on the non-orthogonal axes. That is for me the hardest thing to understand. Best regards, Kateryna On 29/06/12 04:49, Gavin Abo wrote: 1) In which coordinate system are SPI005 and ORB005 given? In Appendix C (http://www.wien2k.at/reg_user/textbooks/) of New notes about Hyperfinefield calculations (ps), it mentions that the subroutine /couplx/ (of lapwdm) now calculates matrices of all components of spin and orbital momentum in the crystal coordinate system (sx,sy,sz,lx,ly,lz). Therefore, *I believe the x, y, and z values of SPIxxx and ORBxxx are also in the crystal coordinate system (CCS), while the M values (PROJECTION ON M values) are parallel to the magnetization. * If your good with reading fortan, you can look into the code. I don't full understand what is going on in the code, but I believe the direction to M (in your case: 1 1 -1) specified in case.inso is read in SRC_lapwdm/lapwdm.f. Then, the angles theta and phi between the direction to M and CCS are calculated in SRC_lapwdm/angle.f. Next, the x, y, and z values of SPIxxx and ORBxxx are calculated in the CCS. The x, y, and z values are written to case.outputdm(up/dn) and case.scfdm(up/dn), while a Cartesian to spherical equation [r = sin(theta)*(cos(phi)*x+sin(phi)y)+cos(theta)*z] is used to calculate the radius (M) using the x, y, and z, theta, and phi values before writing to the same output files as performed by SRC_lapwdm/output.f. 2) Why for the first iteration MMI005 is not even roughly equal to SPI005 + ORB005? SPIxxx is the spin moment calculated from selected electrons only (usually d or f). MMIxxx is the sum from all electrons (s, p, d and f states) inside the atomic sphere xxx. ORBxxx is the orbital magnetic moment. So*MMIxxx = SPIxxx + ORBxxx is not necessarily true.* See the reference links below for more information: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-September/015296.html http://zeus.theochem.tuwien.ac.at/pipermail/wien/2008-April/010820.html http://zeus.theochem.tuwien.ac.at/pipermail/wien/2005-January/004399.html On 6/28/2012 9:18 AM, Kateryna Foyevtsova wrote: Dear Wien2k developers, I use wien2k version 11.1 to run spin-polarized GGA+U calculations with SO coupling for a molibdenum oxide. The symmetry of the system is the following bleblebles-o calc. M|| 1.00 1.00 -1.00 P 15 2 P- RELA 13.669712 13.669712 13.669712 60.00 60.00 60.00 As you see, I set magnetization axis to 1 1 -1, which should be in terms of (non-orthogonal) lattice vectors. With the help of xcrysden and case.outsymso, I can deduce that this direction corresponds to the 0.577350, 0.816497, 0 direction in terms of the cartesian global coordinate system. When I converge the electron density with (without using any previously converged non-relativistic calculation) runsp_lapw -p -orb -so -dm I get the following data for the first and the last iteration on one of the Mo atoms: 1. iteration: :SPI005: SPIN MOMENT: 0.46560 0.80642 -0.53749 PROJECTION ON M 1.07518 :ORB005: ORBITAL MOMENT: -0.08361 -0.01872 0.02851 PROJECTION ON M -0.06454 :MMI005: MAGNETIC MOMENT IN SPHERE 5=1.86180 last iteration (converged solution): :SPI005: SPIN MOMENT: 0.61653 1.06239 -0.70860 PROJECTION ON M 1.41804 :ORB005: ORBITAL MOMENT: -0.08361 -0.01872 0.02851 PROJECTION ON M -0.06454 :MMI005: MAGNETIC MOMENT IN SPHERE 5=1.43149 Now, I am struggling to understand two things: 1) In which coordinate system are SPI005 and ORB005 given? If they were given in the global cartesian coordinate system, they would be parallel to 0.577350, 0.816497, 0, but they are not. 2) Why for the first iteration MMI005 is not even roughly equal to SPI005 + ORB005? Thank you very much! Kateryna Foyevtsova P.S. When I perform relativistic calculations starting with a preconverged electron density of the non-relativistic solution I get the same final result. ___ 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
[Wien] spin and orbital moments
Dear Gavin, that's the point: sqrt(x**2 + y**2 + z**2) works! I indeed get 1.075 when I insert my x, y and z into this equation!
[Wien] spin and orbital moments
Dear Wien2k developers, I use wien2k version 11.1 to run spin-polarized GGA+U calculations with SO coupling for a molibdenum oxide. The symmetry of the system is the following bleblebles-o calc. M|| 1.00 1.00 -1.00 P 15 2 P- RELA 13.669712 13.669712 13.669712 60.00 60.00 60.00 As you see, I set magnetization axis to 1 1 -1, which should be in terms of (non-orthogonal) lattice vectors. With the help of xcrysden and case.outsymso, I can deduce that this direction corresponds to the 0.577350, 0.816497, 0 direction in terms of the cartesian global coordinate system. When I converge the electron density with (without using any previously converged non-relativistic calculation) runsp_lapw -p -orb -so -dm I get the following data for the first and the last iteration on one of the Mo atoms: 1. iteration: :SPI005: SPIN MOMENT: 0.46560 0.80642 -0.53749 PROJECTION ON M 1.07518 :ORB005: ORBITAL MOMENT: -0.08361 -0.01872 0.02851 PROJECTION ON M -0.06454 :MMI005: MAGNETIC MOMENT IN SPHERE 5=1.86180 last iteration (converged solution): :SPI005: SPIN MOMENT: 0.61653 1.06239 -0.70860 PROJECTION ON M 1.41804 :ORB005: ORBITAL MOMENT: -0.08361 -0.01872 0.02851 PROJECTION ON M -0.06454 :MMI005: MAGNETIC MOMENT IN SPHERE 5=1.43149 Now, I am struggling to understand two things: 1) In which coordinate system are SPI005 and ORB005 given? If they were given in the global cartesian coordinate system, they would be parallel to 0.577350, 0.816497, 0, but they are not. 2) Why for the first iteration MMI005 is not even roughly equal to SPI005 + ORB005? Thank you very much! Kateryna Foyevtsova P.S. When I perform relativistic calculations starting with a preconverged electron density of the non-relativistic solution I get the same final result.
