fixed upfs for all current elements #105
Conversation
|
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. |
|
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
<#105 (comment)>,
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
> <#105 (comment)>,
> 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 Additionally, we should also update the |
|
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).
|
|
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 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:
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