I am importing several basis sets from ORCA (eg Neese’s SARC sets), but I suspect
than psi4 does not normalize the contraction coefficients like ORCA. Am I correct?
RHF test calcs with Mg2+:
build-in cc-pVDZ basis (perfect agreement):
psi4: -198.8242026903669171
orca: -198.824202690121
psi4: -198.8242026837470462 (import from orca)
Is it only the Jensen basis sets? They were added via PR and a processing error is not unthinkable. Agree that 6 decimal places is not something one should neglect beyond. Were you referring to the “mported pc-1 basis:” energy agreement, or do you see a specific place where we’re truncating at 6?
I did not use the build-in Jensen basis sets. They were just a test. Originally
I wanted to get Neese’s SARC basis sets into psi4, but the DHK calculations gave very large deviation from ORCA. I needed a smaller basis set for tests not yet in psi4 and chose pc-1.
The 6 decimal numbers refer to the conversion script I used to convert the ORCA-style basis set to psi4-style.
I had the wrong print statement in python and was wondering why I see large errors. My fault, not psi4’s.
The real issue is that if I provide a non-normalized basis set from somewhere, it does not get normalized in psi4 (so I assume), and gives the deviations shown in the “imported pc-1 basis” section.
To summarize:
I export a basis from ORCA which is not normalized (eg pc-1) and make a .gbs file for use with psi4. Then I see large deviations between ORCA and psi4. If I provide a .gbs file with a normalized pc-1 basis set, I get excellent agreement.
The ORCA people got back to me and apparently I found a bug in their basis set export tool.
The coefficients they print under certain circumstance are plain wrong (if I understand it correctly.)
This is all a mess, but it seems it is all good with psi4.
Whew. Ok, let me know if anything else comes up attributable to psi4.
Btw, DKH in psi4 when run simply does not match Molpro. As I understand it, one needs to decontract, run a part, recontract, run another part to get a match. I’ll investigate and fix when I get a chance, but that’s the current situation.
While the issue has been resolved, I’d like to point out that you have to be careful when comparing the contraction coefficients of generally contracted basis sets like pc-n (in contrast to pcseg-n) in programs that use segmented contractions.
Namely, while the core contractions are properly normalized when all primitives are included, typically one drops the free primitives out of the contraction in segmented codes, because this is a free lunch. However, when the basis set is renormalized, the contraction coefficients will change because one primitive was dropped. The question is: are the coefficients printed out before or after the normalization?