Dear Sirs, I did some calculations with GaN (struct file in attachment) to compare the difference in energy and electric field gradient between the use of spin-polarization or not.
The calculations were done using the commands init_lapw -b -ecut -8 -numk 480 -rkmax 7 (-sp) run(sp)_lapw -p -ec 0.00001 -cc 0.0001 -fc 0.5 and the results were the following :ENE = -7995.60614872 (no spin-polarization) :ENE = -7995.60614871 (spin-polarization) :EFG001 = 0.57937 (no sp) :EFG001 = 0.57931 (sp) so they basically give the same. Then, I relaxed the structure using run(sp)_lapw -p -ec 0.00001 -cc 0.0001 -fc 0.5 -min and the results were :POS001 = 0.66667 0.33333 0.00002 (no sp) :POS001 = 0.66667 0.33333 0.00000 (sp) :POS002 = 0.66667 0.33333 0.37662 (no sp) :POS002 = 0.66667 0.33333 0.37701 (sp) :ENE = -7995.60615476 (no sp) :ENE = -7995.60615035 (sp) :EFG001 = 0.45038 (no sp) :EFG001 = 0.58801 (sp) so they gave different final positions and very different :EFG, as a consequence. However, if I use the final structure from the minimization without spin-polarization and do a calculation with spin-polarization (both from the beginning, using the previous commands), I get equal values :ENE = -7995.60615467 (no sp) :ENE = -7995.60615466 (sp) :EFG001 = 0.45036 (no sp) :EFG001 = 0.45034 (sp) and if I use the final structure from the minimization with spin-polarization and do a calculation without spin-polarization, I also get equal values :ENE = -7995.60614842 (no sp) :ENE = -7995.60614842 (sp) :EFG001 = 0.58272 (no sp) :EFG001 = 0.58271 (sp) This means that the only thing that I am getting different between them is the atomic positions during the minimization, since I always get the same :ENE and :EFG if both calculations are done with the same struct file. Is there any reason for this to happen? Which values for :ENE, :EFG and :POS should I consider the best, the spin-polarized ones or the ones without spin-polarization? Best regards, Marcelo
GaN.structDescription: Binary data
08.04.2016 14:41, Marcelo Barbosa wrote:
You do not write about magnetic moments that you received in sp calculation. I guess that they are zero, and both calculations (sp and non-sp) are, thus, the same. If so, some differences that you see later are due to a not full convergence.I did some calculations with GaN (struct file in attachment) to compare the difference in energy and electric field gradient between the use of spin-polarization or not. :ENE = -7995.60614872 (no spin-polarization) :ENE = -7995.60614871 (spin-polarization)
Best wishes Lyudmila Dobysheva ------------------------------------------------------------------ Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci. 426001 Izhevsk, ul.Kirova 132 RUSSIA
What you did not show was that the minimization will give different forces too. The minimization will stop once the forces are for a couple of times below 2.0 mRy (case.inM) and the movement is small enough. Even very small differences between the sp and non-sp calculation will lead to a different minimization-path and thus mixer will stop by chance at different positions leading to different EFGs (and E-tot). In other words: If you would really want to get out the same results in both runs you need to put the cut-off in case.inM very small, so that mixer will optimize the positions until the forces are really small in all cases.Thank you for both your emails. Answering to the first one, yes, I forgot to write about the magnetic moments but they are zero in both calculations.Answering to the second one, the forces were a little bit different (less than 1.0 mRy in difference) but I wasn’t expecting such a big difference in the EFG due to it, so I didn’t think that it was important to send them. My mistake, I was wrong. They were all in fact below 2 mRy, so the minimization stopped, but it stopped in different positions for each method. I did a another minimization with both methods until the forces were all below 0.10 mRy (tried first with 1.0 mRy but it was not enough) and in this situation the results are much more similar: :POS001 = 0.66667 0.33333 -0.00012 (no sp) :POS001 = 0.66667 0.33333 -0.00022 (sp) :POS002 = 0.66667 0.33333 0.37638 (no sp) :POS002 = 0.66667 0.33333 0.37627 (sp) :EFG001 = 0.41661 (no sp) :EFG001 = 0.41404 (sp) :EFG002 = 0.10461 (no sp) :EFG002 = 0.10472 (sp) I was doing these tests to see if I should use spin-polarization or not in calculations of GaN, specially for the calculation of the EFGs. That’s why I was worried about the different EFGs that I was obtaining. However, since they give the “same" results after all, am I right to assume that for this material I don’t need to consider spin-polarization? Thank you both very much for your help, Marcelo > On 08/04/2016, at 13:58, Peter Blaha <pbl...@theochem.tuwien.ac.at> wrote: > > What you did not show was that the minimization will give different forces > too. > > The minimization will stop once the forces are for a couple of times below > 2.0 mRy (case.inM) and the movement is small enough. > > Even very small differences between the sp and non-sp calculation will lead > to a different minimization-path and thus mixer will stop by chance at > different positions leading to different EFGs (and E-tot). > > In other words: If you would really want to get out the same results in both > runs you need to put the cut-off in case.inM very small, so that mixer will > optimize the positions until the forces are really small in all cases. > > > On 04/08/2016 12:41 PM, Marcelo Barbosa wrote: >> Dear Sirs, >> >> I did some calculations with GaN (struct file in attachment) to compare the >> difference in energy and electric field gradient between the use of >> spin-polarization or not. >> >> The calculations were done using the commands >> >> init_lapw -b -ecut -8 -numk 480 -rkmax 7 (-sp) >> run(sp)_lapw -p -ec 0.00001 -cc 0.0001 -fc 0.5 >> >> and the results were the following >> >> :ENE = -7995.60614872 (no spin-polarization) >> :ENE = -7995.60614871 (spin-polarization) >> >> :EFG001 = 0.57937 (no sp) >> :EFG001 = 0.57931 (sp) >> >> so they basically give the same. >> >> Then, I relaxed the structure using >> >> run(sp)_lapw -p -ec 0.00001 -cc 0.0001 -fc 0.5 -min >> >> and the results were >> >> :POS001 = 0.66667 0.33333 0.00002 (no sp) >> :POS001 = 0.66667 0.33333 0.00000 (sp) >> >> :POS002 = 0.66667 0.33333 0.37662 (no sp) >> :POS002 = 0.66667 0.33333 0.37701 (sp) >> >> :ENE = -7995.60615476 (no sp) >> :ENE = -7995.60615035 (sp) >> >> :EFG001 = 0.45038 (no sp) >> :EFG001 = 0.58801 (sp) >> >> so they gave different final positions and very different :EFG, as a >> consequence. >> >> However, if I use the final structure from the minimization without >> spin-polarization and do a calculation with spin-polarization (both from the >> beginning, using the previous commands), I get equal values >> >> :ENE = -7995.60615467 (no sp) >> :ENE = -7995.60615466 (sp) >> >> :EFG001 = 0.45036 (no sp) >> :EFG001 = 0.45034 (sp) >> >> and if I use the final structure from the minimization with >> spin-polarization and do a calculation without spin-polarization, I also get >> equal values >> >> :ENE = -7995.60614842 (no sp) >> :ENE = -7995.60614842 (sp) >> >> :EFG001 = 0.58272 (no sp) >> :EFG001 = 0.58271 (sp) >> >> >> This means that the only thing that I am getting different between them is >> the atomic positions during the minimization, since I always get the same >> :ENE and :EFG if both calculations are done with the same struct file. >> >> Is there any reason for this to happen? >> Which values for :ENE, :EFG and :POS should I consider the best, the >> spin-polarized ones or the ones without spin-polarization? >> >> Best regards, >> Marcelo >>ٌReference: https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14101.html
My name is Dr Abderrahmane Reggad. I'm a 54 year old and I am a researcher in materials' sciences. 
![[Wien] Regarding adding BoltzTraP to WIEN2k in graphical interface w2web](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1M91B6_CqBNxJKG1IFDyZWzehLgccLqaOep7Mq0-46VZR1TSAd3RfPVnA5LTr7I9eDsCzP6sqYEyjFyyzSV88Ljps7lf2KU2MrJFmnKZL7Fp3rs8XyS98CdfwLTGdgsWv6aV0w3XV354n/w100/boltztrap.png)
0 Comments