QMCPACK
fixed upfs for all current elements
This fixes the upfs to be in the format of QE 7.1. This regenerated all but one upf using the exact same inputs as the original UPFs, due to the differences between the computer used this time vs when they were originally generated, the diffs look large, but they are out at the 14-16th decimal place. The energy from the rpts are unchanged, they look like:
diff recipes/Ag/ccECP/Ag.ccECP.AREP.rpt ../work/Ag/ccECP/Ag.ccECP.AREP/Ag.rpt 155c155
E_tot = -289.0035643111 Ry E_tot = -289.0035643110 Ry
which showed a diff of 2.7k lines. To the best of my knowledge there should be no issue with these being used as is. All of the upfs originally generated on my system that were updated, show a diff of just the lines that were altered to the new format.
Lastly, Tb SOREP had problems I couldn't pin down when run in opium, it happened no matter if I ran it on PERLMUTTER or on my personal system, whether it was run on the old version opium or not. I wasn't able to get the calculation to finish. I simply updated the format for that one by hand, it wasn't rerun.
closes #89
Hi Ben -
Prior to merging this i made a test calculation for bulk Al. The energies are a little bit different, and by just enough to potentially show up in the last digits of a result table. What are your thoughts for the possible origins of the difference? Inputs & outputs are attached. Al_test.tar.gz
$ grep "Execution Date" Al.ccECP.upf_*
Al.ccECP.upf_new:#Execution Date : Fri Apr 19 14:16:08 2024
Al.ccECP.upf_orig:#Execution Date : Thu Jun 30 16:16:13 2022
$ grep '^! ' *.out*
scf.out_new:! total energy = -4.13340513 Ry
scf.out_orig:! total energy = -4.12958855 Ry
Hello Paul,
This was one of two or so that didn’t work immediately with my automated script process. When I investigated it I noticed that it used p as the local channel which we only tend to do to avoid ghosts that sometimes occur when projecting with a as local. I tried it using s and got better performance in the tested states after moving it to s and no ghosts so I was confused as to why p was used prior. I updated it to use s. I did this only for Al ccECP and I think the helium core for Al as well. Here is the diff in the rpt: 19c19 < s
p 25,27d24 < [Relativity] < nrl < 43c40 < 6
7 45,47c42,44 < #300 2.00 - < #310 1.00 - < #320 0.00 -
300 2.00 - 310 1.00 - 320 0.00 - 142,149c139,147 < 0 -3.731010 -3.731010 -0.000000 < 1 -3.568520 -3.568520 -0.000008 < 2 -3.476690 -3.476691 0.000009 < 3 -3.149966 -3.150037 0.000967 < 4 -3.436697 -3.436697 -0.000000 < 5 -3.006399 -3.006524 0.001701 < 6 -2.028712 -2.028712 -0.000000 < MAD (eV): 0.000383525
0 -3.731010 -3.731010 0.000000 1 -3.857407 -3.857400 -0.000104 2 -3.568520 -3.568507 -0.000175 3 -3.476690 -3.476690 -0.000001 4 -3.149966 -3.149943 -0.000307 5 -3.436697 -3.436678 -0.000259 6 -3.006399 -3.006374 -0.000331 7 -2.028712 -2.028516 -0.002658 MAD (eV): 0.000479342
The top is the updated version, the lower is the legacy. I only made this change for one or two where I noticed p was used as local when it didn't seem required, I can get a list together. If you think it should be reverted, I can do that as well.
Sincerely,
Ben
On Wed, Apr 24, 2024 at 10:02 AM Paul R. C. Kent @.***> wrote:
Hi Ben -
Prior to merging this i made a test calculation for bulk Al. The energies are a little bit different, and by just enough to potentially show up in the last digits of a result table. What are your thoughts for the possible origins of the difference? Inputs & outputs are attached. Al_test.tar.gz https://github.com/QMCPACK/pseudopotentiallibrary/files/15095430/Al_test.tar.gz
$ grep "Execution Date" Al.ccECP.upf_* Al.ccECP.upf_new:#Execution Date : Fri Apr 19 14:16:08 2024 Al.ccECP.upf_orig:#Execution Date : Thu Jun 30 16:16:13 2022 $ grep '^! ' .out scf.out_new:! total energy = -4.13340513 Ry scf.out_orig:! total energy = -4.12958855 Ry
— Reply to this email directly, view it on GitHub https://github.com/QMCPACK/pseudopotentiallibrary/pull/105#issuecomment-2075024060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOSTPRGRBS3KAUMKQR6C7HTY663Q3AVCNFSM6AAAAABGPVT4XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZVGAZDIMBWGA . You are receiving this because you authored the thread.Message ID: @.***>
I forgot to mention, I had to remove one of the tested states as it was failing to converge. That is why there are only 7 tested states in the updated set, this wasn't due to changing the local channel. I was able to run it both ways once I removed the problematic configuration.
Ben
On Wed, Apr 24, 2024 at 10:16 AM Benjamin Kincaid @.***> wrote:
Hello Paul,
This was one of two or so that didn’t work immediately with my automated script process. When I investigated it I noticed that it used p as the local channel which we only tend to do to avoid ghosts that sometimes occur when projecting with a as local. I tried it using s and got better performance in the tested states after moving it to s and no ghosts so I was confused as to why p was used prior. I updated it to use s. I did this only for Al ccECP and I think the helium core for Al as well. Here is the diff in the rpt: 19c19 < s
p 25,27d24 < [Relativity] < nrl < 43c40 < 6
7 45,47c42,44 < #300 2.00 - < #310 1.00 - < #320 0.00 -
300 2.00 - 310 1.00 - 320 0.00 - 142,149c139,147 < 0 -3.731010 -3.731010 -0.000000 < 1 -3.568520 -3.568520 -0.000008 < 2 -3.476690 -3.476691 0.000009 < 3 -3.149966 -3.150037 0.000967 < 4 -3.436697 -3.436697 -0.000000 < 5 -3.006399 -3.006524 0.001701 < 6 -2.028712 -2.028712 -0.000000 < MAD (eV): 0.000383525
0 -3.731010 -3.731010 0.000000 1 -3.857407 -3.857400 -0.000104 2 -3.568520 -3.568507 -0.000175 3 -3.476690 -3.476690 -0.000001 4 -3.149966 -3.149943 -0.000307 5 -3.436697 -3.436678 -0.000259 6 -3.006399 -3.006374 -0.000331 7 -2.028712 -2.028516 -0.002658 MAD (eV): 0.000479342
The top is the updated version, the lower is the legacy. I only made this change for one or two where I noticed p was used as local when it didn't seem required, I can get a list together. If you think it should be reverted, I can do that as well.
Sincerely,
Ben
On Wed, Apr 24, 2024 at 10:02 AM Paul R. C. Kent @.***> wrote:
Hi Ben -
Prior to merging this i made a test calculation for bulk Al. The energies are a little bit different, and by just enough to potentially show up in the last digits of a result table. What are your thoughts for the possible origins of the difference? Inputs & outputs are attached. Al_test.tar.gz https://github.com/QMCPACK/pseudopotentiallibrary/files/15095430/Al_test.tar.gz
$ grep "Execution Date" Al.ccECP.upf_* Al.ccECP.upf_new:#Execution Date : Fri Apr 19 14:16:08 2024 Al.ccECP.upf_orig:#Execution Date : Thu Jun 30 16:16:13 2022 $ grep '^! ' .out scf.out_new:! total energy = -4.13340513 Ry scf.out_orig:! total energy = -4.12958855 Ry
— Reply to this email directly, view it on GitHub https://github.com/QMCPACK/pseudopotentiallibrary/pull/105#issuecomment-2075024060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOSTPRGRBS3KAUMKQR6C7HTY663Q3AVCNFSM6AAAAABGPVT4XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZVGAZDIMBWGA . You are receiving this because you authored the thread.Message ID: @.***>
OK. Please make that list -- we should craft a sentence to put in the news and updates part of the website. e.g.
"2024-04-24: Updated all UPF files for the new QE7.1 format. All of the UPF files were regenerated. As part of the update we changed the local channels for X, Y, Z, for better overall accuracy. Total energies should only change a small amount. Contact us if that is not the case."
@bkincaid256 Thanks for the push. I agree with @prckent that if there is a significant change in the total energies, it needs to be publicized. For example, some time ago, I added energies.txt for each ECP, which shows isolated atomic energies from various codes. The QE numbers there would then be outdated. Another option would be to leave the local channel the same since the improvement in transferability seems marginal.
Additionally, we should also update the *.rpt files. This will make the reference state clear to the user and good for reproducibility.
The two ecps affected by the change in local channel are Al.ccECP.upf, and Si.ccECP.upf. I can revert them if that is more convenient, also for all but these two the energies in the rpts are virtually identical. I have generated a full list of diffs between the old rpts and the new, pretty much every discrepancy looks to be machine precision differences. I can update them though as it won't take more than adding a line in my script. There were a few test configurations that had to be removed due to not converging on this machine for whatever reason. I worry about losing that information when the upf should still perform the same on it, opium just had some hiccup with it this time.
OK, so if the local channel changes are only in Al and Si, and if the transferability improvement in Si is also marginal, I am inclined towards keeping them unchanged for now (unless we find a good reason to change later). Note that we have published papers using both of these ECPs where we report the SCF totals (diamond Si and GCTA Al).
*rpt file changes are indeed not important if the changes are machine precision.
I reversed the change to the two upfs. If someone could verify the energy is giving the old result, that would be very much appreciated.
This has been waiting a bit too long imo... should we merge or are there concerns outstanding?
I found what Kayahan mentioned. It was a section of the UPF I wasn't aware needed changing. Fixing it should be as easy as copying what I have done in the header to that section. I will get that fixed, rerun the set and update you.
Thanks Ben. Let me know about merging or not. Q. Do you have a link to a specification for the PP_ADDINFO section?
Sorry for the delayed response. I was looking up and down for a spec to explicitly follow, but it seems that quantum espresso has removed their specification for UPF_v1. On their site they only quote the spec for UPF_v2. Due to that, I have been trying to cook up a simple test case based on what Kayahan was able to get running. I want to make sure this doesn't break things when merged. I will try to get that worked out as soon as I can, but if someone has an example of an atom with DFT+U already lying around for AREP and SOREP that would make things simple. If a couple test cases can be run then I think everything should be safe to green light.
To clarify, this most recent update only really alters the SOREP UPFs. Those are the only ones with the ADD_INFO section. The rest of the AREPs should be functionally identical to whatever was tested last iteration which from what I remember seemed to run as expected. The rest of the update made sure that the .rpt files are accurate to the UPF generated as before they were left as they had been when first added to the table.