Update cc-pVXZ and add cc-pwCVXZ for Li, Be, Na, Mg

[rmcgibbo]

Description

Update cc-pVXZ (D through 5) for Li, Be, Na, and Mg, and add cc-pwCVXZ (D through 5) for Li, Be, Na and Mg with values from Prascher, D.E. Woon, K.A. Peterson, T.H. Dunning, Jr., A.K. Wilson, Theor. Chem. Acc. 128, 69 (2011), accessed from http://tyr0.chem.wsu.edu/~kipeters/basissets/alkal-nr.html. Closes gh-727.

Add cc-pwCVXZ-RI (D through 5) for Li, Be, Na and Mg with values from J. G. Hill and K. A Peterson, "Correlation consistent basis sets for explicitly correlated wavefunctions: Valence and core-valence basis sets for Li, Be, Na, and Mg" Phys. Chem. Chem. Phys. (2010). The values were accessed from http://www.rsc.org/suppdata/cp/c0/c0cp00020e/c0cp00020e.pdf.

Update cc-pV5Z-RI for Na from Hill and Peterson (2010).

Todos

• Add RI
• Check locally against molpro.
• Fix cc-pwCV5Z for Na and Mg

Status

• Ready to go

[rmcgibbo]

@loriab: I found a small problem with this PR that I was thinking you might know best how to fix.

At the 5z level for Na and Mg, Pracher (2011) mention [1] that it's not the case that the cc-pwCV5Z basis is formed simply by adding the tight functions to the cc-pV5Z basis. i.e. the contractions in cc-pwCV5Z are not a strict superset of the contractions in cc-pV5Z for these elements.

[1]

To avoid near linear-dependence in the s functions at the quintuple-z level for Na and Mg, an additional four s functions are uncontracted from the Hartree–Fock set and take the place of the usual optimized tight s functions for core-valence correlation

Is there a way to handle this with the psi machinery?

[loriab]

Uggh. Just put the full basis for Na & Mg 5-zeta in the tight file, please, and I'll add except them by hand.

[rmcgibbo]

This is ready for review now. I've compared the energies vs. molpro and double checked the equivalence of the basis sets.

[dgasmith]

Looks good to me, but this is up to @loriab really.

[loriab]

Yeah, I'll run the scripts so it percolates up, then PR them to here.

[loriab]

Sorry for the delay – scripts needed some serious updating. And I found that #331 had the same non-additivity (pwCV != pV + tight) problems as found here for Na/Mg 5-zeta but just got added to the outer basis sets rather than the basis composing machinery. So machinery got reworked to allow for the case – see NOTES for details. This is all in PR.

In the end, 100+ basis sets change, as represented in the reports below (yellow means element has changed from before; blue is new element). I think they look sane, but @rmcgibbo and @fevangelista might look them over to confirm.

@robertodr, I had to edit pcmsolver-ccsd-pte to adjust for the new Mg basis set (makes sense). But I only had to edit the CC ref values, not the SCF. Does it make sense to you why?

[loriab]

This is probably ready to go after @rmcgibbo accept the upstream PR. Needs a commit anyway to re-trigger Distelli.

[fevangelista]

It seems like in a couple of cases we go from an optimized contraction to one that is not. For example, here a s-gaussian with exponent 0.0230700 was added to the core orbital. However, this function is redundant because it is already included in the basis. This introduces a slight performance penalty when computing integrals. Do we have a policy for contraction optimization?

-Na     0 
 -S   11   1.00
 -  31700.0000000              0.458878D-03     
 -   4755.0000000              0.355070D-02     
 -   1082.0000000              0.182618D-01     
 -    306.4000000              0.716650D-01     
 -     99.5300000              0.212346D+00     
 -     35.4200000              0.416203D+00     
 -     13.3000000              0.373020D+00     
 -      4.3920000              0.625054D-01     
 -      1.6760000             -0.624532D-02     
 -      0.5889000              0.243374D-02     
 -      0.0564000             -0.442381D-03  

+Na     0
 +S   12   1.00
 +  31700.0000000              4.5887800e-04
 +   4755.0000000              3.5507000e-03
 +   1082.0000000              1.8261800e-02
 +    306.4000000              7.1665000e-02
 +     99.5300000              2.1234600e-01
 +     35.4200000              4.1620300e-01
 +     13.3000000              3.7302000e-01
 +      4.3920000              6.2505400e-02
 +      1.6760000             -6.2453200e-03
 +      0.5889000              2.4337400e-03
 +      0.0564000             -4.4238100e-04
 +      0.0230700              2.4192400e-04

 S   1   1.00
 -      0.0230700              1.0000000   
 +      0.0230700              1.0000000e+00

[loriab]

We have a clear policy (at least for what was originally added) of using optimized contractions from EMSL. From Kirk Peterson's website, we don't have that option, so we get what he supplies. Not sure what to do about it, unless implement a fn to re-optimize contractions.

[CDSherrill]

Perhaps Kirk would be willing to add this feature for us.

…

On Mon, Jun 12, 2017 at 2:32 PM, Lori A. Burns ***@***.***> wrote: We have a clear policy (at least for what was originally added) of using optimized contractions from EMSL. From Kirk Peterson's website <http://tyr0.chem.wsu.edu/%7Ekipeters/basis.html>, we don't have that option, so we get what he supplies. Not sure what to do about it, unless implement a fn to re-optimize contractions. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#728 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC9Qdij1x5IEyCPr7tRTjpEHhtNZnbNuks5sDYQzgaJpZM4NuweP> .

[andysim]

Looking at the EMSL outputs with and without optimization, it looks like a simple case of ripping out any functions from contractions that are already present as standalone functions. This should be really easy to put together in Python if we need it.

[loriab]

Admittedly I can't support this (I see what Andy sees), but I think there are many cases where the coefficients change between optimized and unoptimized general contractions.

Also, Distelli just doesn't acknowledge this PR. It's built others recently, so I don't know what its problem is. Can override again.

[amjames]

I agree that @loriab should ok this before it is merged, but I don't see anything wrong with it. 👍

[andysim]

Looks like we still have to look into the optimized contractions for group I and II, but that should be a very minor performance change that shouldn't change the answer. We can look into that post-merge

[robertodr]

Regarding the PTE test case, I get the following Integral setup running the code on master:

Using in-core PK algorithm.
 Calculation information:
    Number of atoms:                   1
    Number of AO shells:               8
    Number of primitives:             50
    Number of atomic orbitals:        19
    Number of basis functions:        18
                                             
    Integral cutoff                 1.00e-12
    Number of threads:                 1

while this one with the code on this PR:

 Using in-core PK algorithm.
  Calculation information:
     Number of atoms:                   1
     Number of AO shells:               8
     Number of primitives:             55
     Number of atomic orbitals:        19
     Number of basis functions:        18
     Integral cutoff                 1.00e-12
     Number of threads:                 1

The SCF results are the same within 10^-11 The CC results are different already at the first iteration of the T amplitude solver, i.e. the MP2 correlation energy. This despite the fact that the SCF energies reported by the two versions at the end of cctransort are the same.

[susilehtola]

I'm confused: in the printout, what is the difference between AOs and basis functions?
I assume this is referring to linearly independent basis functions - a key word is missing!

[fevangelista]

@robertodr: I think the only real difference in the PR for the cc-pVDZ basis is a change in the exponent of a d function. No d orbitals are occupied in Mg, so an energy difference would show up only in the correlation energy.

[andysim]

@susilehtola the AOs are the number of Cartesian functions, while basis functions are the number of functions actually present (fewer than AOs if AM>=2 and pure functions are used).

[susilehtola]

@andysim that's confusing, since the AOs should be spherically symmetric! It should say cartesian functions instead of atomic orbitals.

[robertodr]

@fevangelista indeed, you're right! Should've seen it myself! Il mer 14 giu 2017, 09:31 Susi Lehtola <notifications@github.com> ha scritto:

…

@andysim <https://github.com/andysim> that's confusing, since the AOs should be spherically symmetric! It should say cartesian functions instead of atomic orbitals. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#728 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADiXEZCgBKCxiaRxtg-TvQXqGZL0p5nUks5sD4xVgaJpZM4NuweP> .