Re: [Wien] RMTs changing on their own?
On 11/03/2015 02:47 PM, Laurence Marks wrote: > a) :FCHECK (bottom of case.scf) was large. This is the sum of all > the forces, and should be small. Particularly for cells without > inversion one can get bad, highly asymmetric densities in which case > MSR1a can have problems. True, I had not notice this before. :FCHECK was already quite large (hundreds for x and y, even >1000 for z) before ‘clminter’ and “jumped” to even larger values afterwards. > b) The greed is small. Too small a value can be as bad as too large. > I have struggled with this for years and failed to find a strong > ansatz for this, although I believe the next release of the mixer > will be better. AFAIK, the greed in MSR1(a) is set internally by the mixer (the corresponding value in case.inm being ignored), so there is nothing I can do directly to influence this, is there? > I am not sure what the calculation is, perhaps an oxide surface > where you have made a guess at the initial structure and want to > minimize to something more reasonable. Quite a good guess, it is an oxide heterostructure including a slab of vacuum, but the initial structure is derived (cut out) from a converged one from an older calculation, so I would have expected only relatively minor adjustments. As such, the large forces also come as something of a surprise. > I strongly suggest trying to use cells with inversion, they behave > much, much better. In this case, inversion symmetry could only be achieved by adding an additional “film” on the back side of the “substrate”. > I also strongly suggest that you look at the Bond Valence Sums (BVS) > and tweak the initial positions until they are reasonable. (x nn ; > grep Bond *tnn). If, for instance, you have highly underbonded O > (e.g. 0.8) it can take forever and the calculations can be unstable > -- convergence is faster the more physical are the atomic positions. I guess the expectation is that the BVS should be close to the “formal valence” of the ion, right? In this case, it seems okay: The first BVS value is between 1.4 and 2.2 for O, deviations for other species are rather smaller). > Good luck. Thanks, and thank you for your tips. Elias -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ 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] RMTs changing on their own?
I am not sure exactly what the problem(s) were, but from you case.scf it was "right" that there were Warnings a) :FCHECK (bottom of case.scf) was large. This is the sum of all the forces, and should be small. Particularly for cells without inversion one can get bad, highly asymmetric densities in which case MSR1a can have problems. b) The greed is small. Too small a value can be as bad as too large. I have struggled with this for years and failed to find a strong ansatz for this, although I believe the next release of the mixer will be better. I am not sure what the calculation is, perhaps an oxide surface where you have made a guess at the initial structure and want to minimize to something more reasonable. Sometimes a physically unreasonable initial guess will converge to something reasonable, sometimes not. I strongly suggest trying to use cells with inversion, they behave much, much better. I also strongly suggest that you look at the Bond Valence Sums (BVS) and tweak the initial positions until they are reasonable. (x nn ; grep Bond *tnn). If, for instance, you have highly underbonded O (e.g. 0.8) it can take forever and the calculations can be unstable -- convergence is faster the more physical are the atomic positions. Good luck. --- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University http://www.numis.northwestern.edu Corrosion in 4D http://MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A "Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Gyorgi On Nov 3, 2015 03:19, "Elias Assmann" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/02/2015 05:04 PM, Peter Blaha wrote: > > if ($icycle == 1 && $itestdis < 10 && "$itestmem" == "0" && > > $?firstcheck) then echo 0.2 >.pratt unset firstcheck rm *.broy* if > > ($testmsr == 'MSR') cp $file.struct_old $file.struct <---comment > > You are going to laugh, but this line is missing in my version of > run(sp) [from 14.2]. Also, I am pretty sure I had deleted all *_old > files before starting the calculation, so I am really not sure how the > old RMTs could have crept back in. > > > goto mixer endif > > > Elias > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJWOHt1AAoJEE/4gtQZfOqPjSsQAIm5p02jZp6JTyoyoRnWsBTF > mLs4SM8ruYEIt3RXLCffp5pjnoxajlcUmhXQK/X5DFijOJinPzTOz55qo+4IDsyw > NflwA/ZIwEmOIf+xb8kfGHFrKikh1fPLzURsPcnUgsZicQHNdzBBNMoD7R1kbc/D > kEQbHequiY9gIHzE39/oO1Uq+2ARCOza7niTHzmZIr63STwvLfkb90r5puwI2F/D > APC6sZA/Yzqc80gujdCPOwqrsg8p3ZZfYN3vYn0w5YEybCXVHCV9oZFUhQvR8bBY > ejFVlSgtkjQnBy8RScpK6mUThvpfROKPaG0xq9raWNXkLcGvXnXrtwPV26MQ5d5D > AnzINCqVAn3Fbjf0whIXRb9RU7k3eyBki9REJbpBg4qfRXEKajKb/lH0Ah6P9/7/ > 7r6nXvkUiULeVd1HNCb4Zjtppkfu/UO23Q1DBkYoGvKRVyPlm1JtpkipMh6R10x9 > dMYR07Ai32IDxFS3X1z+WjIrdv0XAoW+SXaKne38zxpCg/A3WLFWE4sPlItrljWV > dm8ep35cd8JuL1/mJrN4tBd8FShJd9Zhb6qu8Sd04RSI66YpHVODdRXEbmIZfYvD > aUGHppQMKAPCN9ICC3l5kYQ62ppJP8GMJtLuoe3SNCQCa6hTD2C1Cs0qMS+arosZ > ztoOyFRKRKg6YKglJ4+I > =Tyd9 > -END PGP SIGNATURE- > ___ > 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] RMTs changing on their own?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2015 05:04 PM, Peter Blaha wrote: > if ($icycle == 1 && $itestdis < 10 && "$itestmem" == "0" && > $?firstcheck) then echo 0.2 >.pratt unset firstcheck rm *.broy* if > ($testmsr == 'MSR') cp $file.struct_old $file.struct <---comment You are going to laugh, but this line is missing in my version of run(sp) [from 14.2]. Also, I am pretty sure I had deleted all *_old files before starting the calculation, so I am really not sure how the old RMTs could have crept back in. > goto mixer endif Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJWOHt1AAoJEE/4gtQZfOqPjSsQAIm5p02jZp6JTyoyoRnWsBTF mLs4SM8ruYEIt3RXLCffp5pjnoxajlcUmhXQK/X5DFijOJinPzTOz55qo+4IDsyw NflwA/ZIwEmOIf+xb8kfGHFrKikh1fPLzURsPcnUgsZicQHNdzBBNMoD7R1kbc/D kEQbHequiY9gIHzE39/oO1Uq+2ARCOza7niTHzmZIr63STwvLfkb90r5puwI2F/D APC6sZA/Yzqc80gujdCPOwqrsg8p3ZZfYN3vYn0w5YEybCXVHCV9oZFUhQvR8bBY ejFVlSgtkjQnBy8RScpK6mUThvpfROKPaG0xq9raWNXkLcGvXnXrtwPV26MQ5d5D AnzINCqVAn3Fbjf0whIXRb9RU7k3eyBki9REJbpBg4qfRXEKajKb/lH0Ah6P9/7/ 7r6nXvkUiULeVd1HNCb4Zjtppkfu/UO23Q1DBkYoGvKRVyPlm1JtpkipMh6R10x9 dMYR07Ai32IDxFS3X1z+WjIrdv0XAoW+SXaKne38zxpCg/A3WLFWE4sPlItrljWV dm8ep35cd8JuL1/mJrN4tBd8FShJd9Zhb6qu8Sd04RSI66YpHVODdRXEbmIZfYvD aUGHppQMKAPCN9ICC3l5kYQ62ppJP8GMJtLuoe3SNCQCa6hTD2C1Cs0qMS+arosZ ztoOyFRKRKg6YKglJ4+I =Tyd9 -END PGP SIGNATURE- ___ 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] RMTs changing on their own?
Yes, it could really happen ! (Not happy about it, need to be changed) I recently introduced in the run(sp)_lapw scripts a hack that mixer should run a second time with a larger mixing (echo 0.2 >.pratt), in case it is the first iteration and the charge distance is very small. However, I also added a line in such a case that struct_old should be copied to struct (probably on Lauries request, because otherwise the positions could be inconsistent). if ($icycle == 1 && $itestdis < 10 && "$itestmem" == "0" && $?firstcheck) then echo 0.2 >.pratt unset firstcheck rm *.broy* if ($testmsr == 'MSR') cp $file.struct_old $file.struct <---comment goto mixer endif This hack is because in WIEN2k_14 the mixer started always with a very small PRATT-step, which could lead to stagnation. It would be best if mixer would do this internally. At the moment comment the copy-line to prevent this again. PS: When overlapping spheres happen, do: cp case.struct case.struct_new edit case.struct_new and set smaller sphere radii x clminter (-up(dn) cp case.struct_new case.struct cp case.clmsum_new case.clmsum ... clmup/dn On 11/02/2015 04:22 PM, Elias Assmann wrote: Hi List, My MSR1a (‘-min’) calculation was running along happily until I reduced the RMTs (using ‘clminter’). After that it continued to run for several iterations, but now has crashed (“SELECT” error in lapw1). I noticed that the RMTs in the current struct file are back to their original values, before the reduction. Is it possible that this change happened automatically? I happened to check on the calculation in the last iteration before it crashed, and saw that the ‘case.struct’ had the original, larger, RMTs while ‘case.struct_old’ still had the reduced ones. Now, after the crash, both files have the original radii. This is corroborated (I think) by the :RKM tag in ‘case.scf’, which changes in the last iteration, apparently back to the value it had before the RMT reduction: ... :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: ... :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: By the way, I had a separate calculation running in a subdirectory of this one, in case there could be any interference from that. Also, this is still the same calculation I asked about earlier, and I still get the *WARNING*s from ‘mixer’ without a more explicit message. Elias ___ 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/staff/tc_group_e.php -- ___ 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] RMTs changing on their own?
For the :WARN, please do "grep -ie Warn case.scf", sometimes there is more information. If that does not help send the case.scf to my private email. Not sure about the other. Peter added something to automatically change RMTs in the latest version, not sure if that played a role (I have never used it). Is there a clminter.log or similar in the directory? Do "grep clminter" on :log? On Mon, Nov 2, 2015 at 9:22 AM, Elias Assmann wrote: > Hi List, > > My MSR1a (‘-min’) calculation was running along happily until I reduced > the RMTs (using ‘clminter’). After that it continued to run for several > iterations, but now has crashed (“SELECT” error in lapw1). > > I noticed that the RMTs in the current struct file are back to their > original values, before the reduction. Is it possible that this change > happened automatically? > > I happened to check on the calculation in the last iteration before it > crashed, and saw that the ‘case.struct’ had the original, larger, RMTs > while ‘case.struct_old’ still had the reduced ones. Now, after the > crash, both files have the original radii. > > This is corroborated (I think) by the :RKM tag in ‘case.scf’, which > changes in the last iteration, apparently back to the value it had > before the RMT reduction: > > ... > :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > ... > :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: > > By the way, I had a separate calculation running in a subdirectory of > this one, in case there could be any interference from that. Also, this > is still the same calculation I asked about earlier, and I still get the > *WARNING*s from ‘mixer’ without a more explicit message. > > > Elias > > > -- > Elias Assmann > Institute of Theoretical and Computational Physics > TU Graz ⟨https://itp.tugraz.at/⟩ > > -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu Corrosion in 4D: MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A "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
