Re: [Wien] DOS calculation for GGA+U+SO is still incorrect.
Dear Peter, Thank you very much for your help! (Upon your request, I post this to the mailing list.) Your suggestion (when running DOS for +U calculation I have to use x lapw2 -qtl -p -up/dn -orb -so, followed by x tera -up/dn) solved my problem. I have two followup questions. (1) Are GGA+U+SO results in Wien2k_13 trustworth? Or just the calculation for DOS is incorrect, not the actual results such as spin moment, optical properties, total energies? I noticed that although Wien2k_13 (I am using) and Wien2k_16 give the same peak position (energy) for 4F states, the shapes of DOS differ. 5D states are not affected by this since U is affed to 4F only, as expected. (2) I did notice a strange behavior with +U calculation. Using Wien2k_13, after the second iteration, the output on the terminal looks like this (suppose that I have three nodes) ORB END ORB END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END LAPW1 END ... ... But with Wien2k_16, I have ORB END ORB END ORB END
Re: [Wien] Laves C15 symmetry reduction
Thank you very much, Dr. Blaha! I will follow your suggestions to see how far I can go. Guoping On Mon, 27 Feb 2017, Peter Blaha wrote: The F cell is the correct cell !!! A "P" cell of an actually FCC cell is automatically a "supercell". However, with wien2k you cannot run (super)cells with the same symmetry as the original cell, as wien2k has implemented on 48 symmetry operations. Suppose you create a 10x10x10 cell and want to keep symmetry: it means that now 1000 atoms would be "equivalent" and there must be 1000 symm.ops which transforms the equivalent atoms into each other, So if you want to use a cell which has by construction 4 times more atoms, you have to break the symmetry. Depending on how you do that, you can end up in various subsymmetries, either a R cell (the R cell is the primitive cell of every F-centered cell anyway), or, eventually in P1. If you are clever, you can probably keep the simple cubic lattice and some of the symmetry operations, but you have to work this out and split/group equivalent atoms yourself. On 02/27/2017 03:08 PM, Guo-ping Zhang wrote: Dear Wien2k users and developers, I encounter a problem with Wien symmetry operation that I could not find an answer from mailing list. I have an intermetallic rare-earth compound, CeFe2, which has C15 cubic Laves phase of MgCu2, with group symmetry No. 227, and with Z=8 in the conventional cell. But I need to contruct a simple cubic cell (P) instead of fcc (F) one given by Wien2k. So I use x supercell to generate P structure and then rename one Ce by Ce1 and one Fe by Fe1 or any combination of them or increasing lattice constant along one direction. If I allow Wien to use its generated structure, I ended up with Rhombohedral structure, or even worse without symmetry. I have no trouble with simple fcc structure, but have no experience with Laves phase. Here is my structure F2 27_F RELA 13.800670 13.800670 13.800670 90.00 90.00 90.00 ATOM -1: X=0.1250 Y=0.1250 Z=0.1250 MULT= 2 ISPLIT=-2 -1: X=0.8750 Y=0.8750 Z=0.8750 Ce NPT= 781 R0=.1 RMT= 2.5 Z: 58.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.5000 Z=0.5000 MULT= 4 ISPLIT= 8 -2: X=0.5000 Y=0.7500 Z=0.7500 -2: X=0.7500 Y=0.7500 Z=0.5000 -2: X=0.7500 Y=0.5000 Z=0.7500 Fe NPT= 781 R0=.5 RMT= 2.42000 Z: 26.0 LOCAL ROT MATRIX:0.000-0.7071068-0.7071068 0.000-0.7071068 0.7071068 -1.000 0.000 0.000 I would appreciate it if anyone can give me some hints on this as what is the correct procedure to generate a correct structure. Thank you very much! Best regards, Guoping ___ 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.atWIEN2k: http://www.wien2k.at WWW: http://www.imc.tuwien.ac.at/TC_Blaha -- ___ 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] Laves C15 symmetry reduction
Dear Wien2k users and developers, I encounter a problem with Wien symmetry operation that I could not find an answer from mailing list. I have an intermetallic rare-earth compound, CeFe2, which has C15 cubic Laves phase of MgCu2, with group symmetry No. 227, and with Z=8 in the conventional cell. But I need to contruct a simple cubic cell (P) instead of fcc (F) one given by Wien2k. So I use x supercell to generate P structure and then rename one Ce by Ce1 and one Fe by Fe1 or any combination of them or increasing lattice constant along one direction. If I allow Wien to use its generated structure, I ended up with Rhombohedral structure, or even worse without symmetry. I have no trouble with simple fcc structure, but have no experience with Laves phase. Here is my structure F2 27_F RELA 13.800670 13.800670 13.800670 90.00 90.00 90.00 ATOM -1: X=0.1250 Y=0.1250 Z=0.1250 MULT= 2 ISPLIT=-2 -1: X=0.8750 Y=0.8750 Z=0.8750 Ce NPT= 781 R0=.1 RMT= 2.5 Z: 58.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.5000 Z=0.5000 MULT= 4 ISPLIT= 8 -2: X=0.5000 Y=0.7500 Z=0.7500 -2: X=0.7500 Y=0.7500 Z=0.5000 -2: X=0.7500 Y=0.5000 Z=0.7500 Fe NPT= 781 R0=.5 RMT= 2.42000 Z: 26.0 LOCAL ROT MATRIX:0.000-0.7071068-0.7071068 0.000-0.7071068 0.7071068 -1.000 0.000 0.000 I would appreciate it if anyone can give me some hints on this as what is the correct procedure to generate a correct structure. Thank you very much! Best regards, Guoping ___ 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] Tb metal
Dear Prof. Blaba and Wien2k developers, Thank you very much for your prior help. Recently, I was testing whether Wien2k can compute Tb metal's spin and orbital moments correctly, but unsuccessful. I follow the paper by Dobrich et al. PRB 76, 035123 (2007). The correct spin moment should be around 6 uB and orbital 3 uB, but Wien gave spin moment of 11.72562 uB/2 which is close to 6 uB (which is OK), and the orbital moment of 1.43494 uB (:ORB001), which is too small. My RKmax is 9.52. I include 4f in the valence, (case.in1: 30.30 0.005 CONT 1 ). I also checked my case.inst. It looks also fine. Tb Xe 4 4, 3,3.0 N 4, 3,1.0 N 4,-4,4.0 N 4,-4,0.0 N 5, 2,1.0 N 5, 2,0.0 N 6,-1,1.0 N 6,-1,1.0 N END of input (instgen_lapw) In case.scf the number of electrons (:NOE) is consistently 38. This is also correct. What is even strange is that the results do not change by adding +U option or not. +U results :ORB001: ORBITAL MOMENT: 0.72713 -1.25942 0.0 PROJECTION ON M 1.45428 :MMTOT: SPIN MAGNETIC MOMENT IN CELL = 11.65626 U=0 results :ORB001: ORBITAL MOMENT: 0.71746 -1.24270 0.0 PROJECTION ON M 1.43494 :MMTOT: SPIN MAGNETIC MOMENT IN CELL = 11.72562 I have attached my structure file in case you want to test it youself. I can not figure out why wien did this all incorrect. Any help is greatly appreciated. Best regards, Guoping Titles-o calc. M|| 1.00 -1.00 0.00 H1 194 RELA 6.803014 6.803014 10.755565 90.00 90.00120.00 ATOM -1: X=0. Y=0.6667 Z=0.7500 MULT= 2 ISPLIT= 8 -1: X=0.6667 Y=0. Z=0.2500 Tb1NPT= 781 R0=.1 RMT= 2.8 Z: 65.0 LOCAL ROT MATRIX:0.000 0.8660254 0.500 0.000 0.500-0.8660254 -1.000 0.000 0.000 8 NUMBER OF SYMMETRY OPERATIONS -1 0 0 0.000 0-1 0 0.000 0 0-1 0.000 1 A 3 so. oper. type orig. index 1 0 0 0.000 0 1 0 0.000 0 0 1 0.000 2 A 10 0 1 0 0.000 1 0 0 0.000 0 0 1 0.500 3 A 17 0-1 0 0.000 -1 0 0 0.000 0 0-1 0.500 4 A 18 0-1 0 0.000 -1 0 0 0.000 0 0 1 0.000 5 B 5 0 1 0 0.000 1 0 0 0.000 0 0-1 0.000 6 B 8 1 0 0 0.000 0 1 0 0.000 0 0-1 0.500 7 B 20 -1 0 0 0.000 0-1 0 0.000 0 0 1 0.500 8 B 22 ___ 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] Efield in case.in0
Dear Wien users and developers and Prof. Blaha, I am interested to use Efield in case.in0. I do not know whether anyone has used this option recently. I would appreciate it if you could share some experience with me. I followed Prof. Blaha's PRB paper Here is my case.in0. TOT 131.00 (5:LDA, 13:PBE, 11:WC, 19:PBEsol, 28:mBJ, 29:revTPSS, 46:HTBS) NR2V IFFT (R2V) 27 27 1602.00 1min IFFT-parameters, enhancement factor, iprint 900 0.001 1 (1) I tested it on a slab with vacuum along the z axis When I change efield, my spin moment does not change. 900 0.1 1 spin moment 10.66455 uB 900 0.001 1 spin moment 10.66455 uB (2) Efield should be a vector, but when I looked at the code, and I found that the efield in wien has no direction. I understand the wien wants to expand the field in G space and then adds it to the total potential. I look at epot1.f in both Wien2k_14 and Wien2k_13; there is no difference that the efield only has an amplitude. Thank you very much for your help in advance! Best regards, Guoping ___ 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 k-parallel
Dear Maciej,
I think Peter's suggestion is correct.
I encountered the same problem last year and it took me several days to
figure it out. The problem is that the wien script deletes those temp
files after each run. If you have two or more jobs running on the same
node, you will have one job killing another job's tmp files. You can see
at the end of lapw2para ... that the script removes those tmp files which
are still needed by other jobs. My solution is let tmp_dir point to your
local working directory, not /tmp.
Best regards,
Guoping
On Thu, 10 Mar 2016, Maciej Polak wrote:
Dear Prof. Blaha,
Thank you very much for your support. I changed the code according to your
suggestions and it seems to work better now. I will be testing it though and
let you know if any other issues arise.
Thanks again,
Best regards,
Maciej Polak
On 03/09/2016 05:06 PM, Peter Blaha wrote:
Just put it to /tmp.
(There was a suggestion in the mailing list that someone wanted to change
/tmp to some other directory, which is tedious in the old versions. With a
variable $tmp_dir this is "easy" to change and will be active in the next
release.
On 03/09/2016 04:27 PM, Maciej Polak wrote:
Dear Prof. Blaha,
Thank you for your answer. I found the appropriate part of my lapw2para
and substituted it with what you suggested.
However, one of the changes that I notice here is that you changed tmp for
$tmp_dir. This $tmp_dir is a new variable which is not recognized by my
script (tmp_dir: Undefined variable.). What is the meaning of this
variable?
Thank you again for finding the time to reply to my email.
Best regards,
Maciej Polak
P.S In case you need it, I post the unmodified part of my code:
set i = 1
while ($i <= $maxproc)
# if ($debug > 0) echo -n "$i "
cp $def.def /tmp/.tmp.$user.$$
#subsituting in files:
cat /tmp/.tmp1.$user.$$
sed "s/vector_${i}dn_$i/vectordn_$i/"
/tmp/.tmp1.$user.$$>/tmp/.tmp2.$user.$$
sed "s/vector_${i}up_$i/vectorup_$i/"
/tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$$
sed "s/vector_${i}so_$i/vectorso_$i/"
/tmp/.tmp1.$user.$$>/tmp/.tmp2.$user.$$
sed "s/energy_${i}up_$i/energyup_$i/"
/tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$$
sed "s/energy_${i}dn_$i/energydn_$i/"
/tmp/.tmp1.$user.$$>/tmp/.tmp2.$user.$$
sed "s/energy_${i}so_$i/energyso_$i/"
/tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$$
sed "s/energyso_${i}dn_$i/energysodn_${i}/"
/tmp/.tmp1.$user.$$>/tmp/.tmp2.$u$
sed "s/energy_${i}dum_$i/energydum_$i/"
/tmp/.tmp2.$user.$$>/tmp/.tmp1.$user.$
sed "s/vector_${i}so_${i}dn_$i/vectorsodn_$i/"
/tmp/.tmp1.$user.$$>/tmp/.tmp2$
sed "s/vector_${i}dum_${i}dn_$i/vectordumdn_$i/"
/tmp/.tmp2.$user.$$>"$def"_$$
@ i ++
end
W dniu 09/03/16 13:45 Peter Blaha napisał:
Hi,
Yes, we had have recently also such a problem. It comes from slow disk
I/O.
A fie like /tmp/.tmp2.mpolak.50255
is a temporary file created by lapw2para and is used when we modify the
lapw2_xx.def files by a couple of sed commands.
Because of this I've reduced the sed commands in my version of lapw2para.
Unfortunately, I cannot post the script because it will not be compatible
with your WIEN2k version, but I can tell you what we did and since then
these errors did not show up anymore.
Please identify the following lines in your lapw2para and modify it like
shown below:
...
#creating def files
set i = 1
while ($i <= $maxproc)
# if ($debug > 0) echo -n "$i "
cp $def.def $tmp_dir/.tmp.$user.$$
#subsituting in files:
cat <$tmp_dir/.script.$user.$$
s/vectorso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/vectorso$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/vectordum$dnup/&_$i/w $tmp_dir/.mist.$user.$$
s/vectordum$updn/&_$i/w $tmp_dir/.mist.$user.$$
s/vector$dnup'/vector${dnup}_$i'/w $tmp_dir/.mist.$user.$$
s/vector$updn'/vector${updn}_$i'/w $tmp_dir/.mist.$user.$$
s/energyso$dnup/&_$i/w $tmp_dir/.mist.$user.$$
[Wien] Postdoctoral Researcher Position available
Dear WIEN2K Colleagues, My group at Indiana State University has a postdoctoral opening, which is supported by U. S. Department of Energy. The deadline for application is Jan. 31, 2016. See the attached job adv. for details. If you or someone in your group are interested, I strongly encourage you or her/him to apply. If you have any questions, please contact me at my private email address. Thank you very much for your attention. Happy New Year! Guo-ping Zhang, Ph. D. Professor of Physics, Department Physics Indiana State University, Terre Haute, IN 47809 USA E-mail: gpzh...@femto.indstate.edu Phone: (812)-237-2044 adv.pdf Description: Adobe PDF document ___ 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] Molecular dynamics using Wien2k
Dear Gavin, Laurence and Peter, Thank you very much for your helpful comments! I will keep my goal as moderate as possible. For my problem, I have to include SOC. I just found a way to compute the force using wien with SOC (it seems Gerhard is also interested in this), though it takes time and nothing is perfect. All I need is to alter Laurence's structure writing routine, so the code runs with a new configuration. I have one more question about the symmetry initialization, if I may. If my system has an inversion symmetry, should I start with a super cell with a symmetric displacement of some atoms to initialize the calculation (init_lapw)? If so, I worry whether the symmetry step would restrict to some symmetry operations but miss some others. Any suggestions are greatly appreciated. Thanks a lot in advance! Guoping ___ 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] Molecular dynamics using Wien2k
Dear Wien2k users, I am interested in using Mini to run MD. After reading the manual and old mailing list, I could not find a workable example. For instance, the manual has an example for NOSE (case.inM) not for MOLD. In the structure optimization section, all the examples are used for minimization (which works well for my problem using MSR1a option in case.inm though the mixer is very slow). I tried to use min_lapw -p -so (after a prior successful SCF) but failed, since it needs case.finM (but the manual does not say how to get case.finM). I already looked at haupt_cad.f, which seems to work. Has anyone succeeded using Wien2k to run MD? If so, is it possible to share with me some details how this is done? I would appreciate any hints. Thanks a lot in advance! Guoping ___ 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] possible bugs in kgen after SOC
Thank you so much, Dr. Tran! Yes, my test case is fcc. I also verified that this does not happen for orthorhombic structures. However, do you know whether the wien code internally uses the cubic lattice vectors instead of primitive lattice vectors? It worries me since the klist's division is read into the code many times. Any comments on this? Thanks! Guoping On Fri, 16 Aug 2013, t...@theochem.tuwien.ac.at wrote: If your solid has a bcc or fcc unit cell, then it is normal, since the k points are expressed in terms of the cubic lattice vectors which are not the primitive ones. F. Tran On Thu, 15 Aug 2013, Guo-ping Zhang wrote: Dear Peter and wien users, I got a very strange list of k point with kgen after initso (with noaxial magnetization say, along (1,1,1) direction. Here is an example. My initization was done as usual (without using 0 division) and I also made true three divs are exactly same. | is larger than the div | v 1757 655 -3 36 4.0 1790 653 -1 36 4.0 1858 65 -13 36 4.0 1891 65 -35 36 4.0 2968 655 -1 36 4.0 3064 65 -15 36 4.0 1791 664 -2 36 4.0 1824 6620 36 2.0 1892 66 -24 36 4.0 3000 6640 36 2.0 1825 673 -1 36 4.0 1893 67 -13 36 4.0 1859 6820 36 2.0 This can not be right. When I checked the new structure file, I found symmetso did not produce a correct structure file. Instead, it reduces the number of symmetry operations. I would appreciare it if you could give me some hints how to resolve this issue. Thanks a lot! Best regards, Guoping ___ 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] possible bugs in kgen after SOC
Dear Peter and wien users, I got a very strange list of k point with kgen after initso (with noaxial magnetization say, along (1,1,1) direction. Here is an example. My initization was done as usual (without using 0 division) and I also made true three divs are exactly same. | is larger than the div | v 1757 655 -3 36 4.0 1790 653 -1 36 4.0 1858 65 -13 36 4.0 1891 65 -35 36 4.0 2968 655 -1 36 4.0 3064 65 -15 36 4.0 1791 664 -2 36 4.0 1824 6620 36 2.0 1892 66 -24 36 4.0 3000 6640 36 2.0 1825 673 -1 36 4.0 1893 67 -13 36 4.0 1859 6820 36 2.0 This can not be right. When I checked the new structure file, I found symmetso did not produce a correct structure file. Instead, it reduces the number of symmetry operations. I would appreciare it if you could give me some hints how to resolve this issue. Thanks a lot! Best regards, Guoping ___ 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] Supercell calculation dilemma with WIEN2k_12
Thank you very much, Laurence, for your help! What puzzles me most is why the new version even does not allow me to run lapw0 or at least give me the option to modify the dimension, which is disappointing. BTW, congratulations on your Nature paper. Best regards, Guoping On Wed, 29 May 2013, Laurence Marks wrote: For a system like this you need to be using mpi. Depending upon how patient you are and the cores available to you somewhere in the range of 16-64 cores. You will never get anywhere otherwise. On Wed, May 29, 2013 at 6:00 PM, Guo-ping Zhang gpzh...@femto.indstate.edu wrote: Dear Peter and Wien2k users, (Many thanks for your help for my previous questions!) I was trying to do a supercell calculation (60 atoms) within 28x28x28 (Angstrom^3), half of which is vacuum. Here are some of the questions that I have. (To be sure, I have searched all the previous 110 emails on this topic, but failed to notice any solutions to this, except a nice comment on the formation energy by Dr. Stefaan Cottenier.) (1) Problems with the new WIEN2k. x lapw0 complains the insufficient memory like this, forrtl: severe (41): insufficient virtual memory This does not happen in the old wien. So my question is whether I can change some parameters in SRC_lapw0, so at least x lapw0 runs. (2) Problems with the old WIEN2k. Since the new version does not work, I tried to use the older version, which worked well, but there is a problem with RKM. Due to the limit set by NMATMAX (=1), the RKM is now truncated to 3.24. To test the vacuum thickness effect, I have to increase the thickness, but this further reduces RKM to an even smaller value. Since I am mostly interested in unoccupied states several eV above Ef, this casts doubts on the wien results. (After I compared it with Gaussian results, I found that APW calculation gives wrong symmetry splitting in those unoccupied states, but LAPW is ok). I really appreciate it if you could give me some suggestions how to get the results accurately for such a big system. If you need additional information, Many thanks in advance! Best regards, Guoping ___ 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 -- 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@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] Supercell calculation dilemma with WIEN2k_12
Dear Peter and Wien2k users, (Many thanks for your help for my previous questions!) I was trying to do a supercell calculation (60 atoms) within 28x28x28 (Angstrom^3), half of which is vacuum. Here are some of the questions that I have. (To be sure, I have searched all the previous 110 emails on this topic, but failed to notice any solutions to this, except a nice comment on the formation energy by Dr. Stefaan Cottenier.) (1) Problems with the new WIEN2k. x lapw0 complains the insufficient memory like this, forrtl: severe (41): insufficient virtual memory This does not happen in the old wien. So my question is whether I can change some parameters in SRC_lapw0, so at least x lapw0 runs. (2) Problems with the old WIEN2k. Since the new version does not work, I tried to use the older version, which worked well, but there is a problem with RKM. Due to the limit set by NMATMAX (=1), the RKM is now truncated to 3.24. To test the vacuum thickness effect, I have to increase the thickness, but this further reduces RKM to an even smaller value. Since I am mostly interested in unoccupied states several eV above Ef, this casts doubts on the wien results. (After I compared it with Gaussian results, I found that APW calculation gives wrong symmetry splitting in those unoccupied states, but LAPW is ok). I really appreciate it if you could give me some suggestions how to get the results accurately for such a big system. If you need additional information, Many thanks in advance! Best regards, Guoping ___ 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] a possible bug in hamilt.F (local-local part)
Dear Peter and Wien users, I noticed a potential bug in hamilt.F. The matrix misses one row. In _06 version, (same with _12 version (Line 901-904) DO 278 J = NV + NNLO - (MO1+L) - (2*L+1)*(JEQO-1) - (jlo-jlop)*(2*l+1)*mult(jneq), NV + NNLO -(jlo-jlop)*(MO1+L+1)-(jlo-jlop)*(JEQO-1)*(2*l+1) the low limit jumps incorrectly. Here is an example of case.output1 of _06 version. 642 644 4 1 -.1874358827D-03 0.00D+00 J,I,IHELP,JNEQ sphere-local Line 891 642 644 4 1 -.1874358827D-03 -.5997948246D-02 J,I,IHELP,JNEQ sphere-local Line 955 644 644 4 1 0.00D+00 0.00D+00 J,I,IHELP,JNEQ, local-local 1 644 644 4 1 0.2341672678D+00 0.00D+00 J,I,IHELP,JNEQ, local-local 2 644 644 4 1 0.2341672678D+00 0.00D+00 J,I,IHELP,JNEQ, local-local 3 See J index just runs from 642 to 644, without 643. In this case, from 1 to 642 is planewave, from 643 on is local orbital. This is the _12 results. Here is correct. 641 643 3 1 -.1200259258D-01 0.00D+00 J_g,I_g,IHELP,JNEQ, sphere-local 642 643 3 1 -.1200259258D-01 0.00D+00 J_g,I_g,IHELP,JNEQ, sphere-local 643 643 3 1 0.2560228649D+00 0.00D+00 J_g,I_g,IHELP,JNEQ, local-local 2 Then, wrong ( 643 is missing ). 641 644 4 1 -.1867862609D-03 -.5977160350D-02 J_g,I_g,IHELP,JNEQ, sphere-local 642 644 4 1 -.1867862609D-03 -.5977160350D-02 J_g,I_g,IHELP,JNEQ, sphere-local 644 644 4 1 0.2341672678D+00 -.1179069863D-17 J_g,I_g,IHELP,JNEQ, local-local 2 Would you please look into this? I can send you my debug code and case.struct file, if necessary. Thanks a lot! Best regards, Guoping ___ 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] A possible bug in abclm.f (of LAPWSO)
Thanks a lot, Peter! It is true that they are same for several years, but it is different from WIEN97 version. I also printed out k+G vectors and found the current abclm.f and hamilt.F produce different results. When k+G vectors are input into hamilt.F, they are already multiplied by b vectors, but when k+G is input into abclm.f they are not. Since alm and blm must be same in lapwso and lapw1, then one of the above treatments must be incorrect. Best regards, Guopig On Mon, 19 Dec 2011, Peter Blaha wrote: Hi, I checked my sources. This subroutine has not changed for several years and furthermore it looks exactly as you showed in your mail, which I believe is correct. Regards Am 14.12.2011 16:19, schrieb Guo-ping Zhang: Dear Peter, I noticed a possible error in abclm.f. The old wien is correct, but the new one is not. See below. The rotation matrix should be applied only after G vectors multiplied by unit vectors b1,b2,b3. I compared this with hamilt.F where my code can reproduce your results with accuracy up to 10^-13. BK(1)=BKX(I) BK(2)=BKY(I) BK(3)=BKZ(I) CALL ROTATE (BK,ROTIJ(1,1,indj),BKROT) BK(1)=BKROT(1)*BR1(1,1)+BKROT(2)*BR1(1,2)+BKROT(3)*BR1(1,3) BK(2)=BKROT(1)*BR1(2,1)+BKROT(2)*BR1(2,2)+BKROT(3)*BR1(2,3) BK(3)=BKROT(1)*BR1(3,1)+BKROT(2)*BR1(3,2)+BKROT(3)*BR1(3,3) CALL ROTATE (BK,ROTLOC(1,1,JA),BKRLOC) CALL YLM(BKRLOC,LABC,YL) Thanks a lot! Guoping ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] A possible bug in abclm.f (of LAPWSO)
Dear Peter, I noticed a possible error in abclm.f. The old wien is correct, but the new one is not. See below. The rotation matrix should be applied only after G vectors multiplied by unit vectors b1,b2,b3. I compared this with hamilt.F where my code can reproduce your results with accuracy up to 10^-13. BK(1)=BKX(I) BK(2)=BKY(I) BK(3)=BKZ(I) CALL ROTATE (BK,ROTIJ(1,1,indj),BKROT) BK(1)=BKROT(1)*BR1(1,1)+BKROT(2)*BR1(1,2)+BKROT(3)*BR1(1,3) BK(2)=BKROT(1)*BR1(2,1)+BKROT(2)*BR1(2,2)+BKROT(3)*BR1(2,3) BK(3)=BKROT(1)*BR1(3,1)+BKROT(2)*BR1(3,2)+BKROT(3)*BR1(3,3) CALL ROTATE (BK,ROTLOC(1,1,JA),BKRLOC) CALL YLM(BKRLOC,LABC,YL) Thanks a lot! Guoping
