Horton ERIs differ from PySCF in cc-pvtz about horton

[tovrstra]

Can you add the output of this script? It could be related to ordering conventions (px, py, pz) versus (py, pz, px).

[tovrstra]

The problem is the ordering of the (pure) d functions and up. (I'm not sure if there is a problem with Cartesian functions because we didn't test that yet.) The ordering in HORTON is documented here:

http://theochem.github.io/horton/tech_ref_gaussian_basis.html#pure-or-harmonic-basis-functions

The order is shown there up to G functions but the pattern is trivial to generalize toward higher moments.

There is a similar reordering going on when loading things from Gaussian. See the following code:

https://github.com/theochem/horton/blob/master/horton/io/gaussian.py#L373

[tovrstra]

P.S. The ordering within Cartesian shells in HORTON is documented here:

http://theochem.github.io/horton/tech_ref_gaussian_basis.html#cartesian-basis-functions

(This is basically just alphabetical.)

[tovrstra]

It does not look like a bug in HORTON anymore, so I'll move this to another milestone and make it a feature (for the pyscf wrapper.)

[matt-chan]

Yep, sounds good. I'll hold off from releasing the wrapper at the moment.

I guess at some point we should have a discussion about whether we should be adopting the standards used by Psi4 and libcint/pyscf?

[PaulWAyers]

I actually like the "alphabetical order" choice. It is so simple to explain and generalize, so even if others aren't using it, perhaps we should, and then write wrappers that let us output integrals in "other" orderings if so desired.

[tovrstra]

Yes, given our intent to play well with other codes, we should be able to handle different ordering styles nicely. We currently do that already in hortion.io when reading/writing files.

One difficulty is that other codes don't document their ordering. I usually had to figure it out by reverse engineering and running several test cases. E.g., in the case of Gaussian, the ordering inside Cartesian and inside pure shells is weird and follows no real pattern that is consistent between different angular momenta. I guess similar annoyances exist in other programs. For that reason, HORTON follows (and documents) an ordering that is trivial for both Cartesian and pure functions of any angular momentum:

• Cartesian: alphabetical (same as in libint)
• Pure: first ordered by the absolute value of the azimuthal quantum number, then cosine before sine. (The reason is that a negative azimuthal quantum number does not make sense for real spherical harmonics. This choice also facilitates recursive algorithms to compute spherical harmonics.)

It makes little sense to switch to the order of some other code X because it is arbitrary and poorly defined. (E.g. where does PySCF document its ordering?). It is also a painful change because it is backward incompatible and it requires reprogramming all the conversion routines for interfacing with other codes.

It is more appealing (but not urgent) to make HORTON ordering agnostic, such that intergrals/densities/... can be computed with different ordering conventions. Something like that goes beyond the scope of the 2.x branch.

[matt-chan]

I sent an email to Qiming Sun to ask why he ordered them that way. PySCF doesn't document their ordering as far as I can see, but I might have missed something.

The only thing I would wonder about is whether the numerical conditioning of the integrals change if we order our shells differently. I didn't know that it was possible to have different values of integrals (or different permutations of the matrix elements at least) and still come up with the same energy at the end?

[tovrstra]

It should not affect the numerical conditioning or any observable property. E.g. the eigenvalues of a matrix do not depend on the order of the indices. Also, a wavefunction does not change when the orbital basis functions are permuted, as long as the expansion coefficient are permuted consistently.

To make things work, all parts of the code should follow the same conventions, e.g. integrals for other operators, the computation of densities on grid points and IO. (This can be hardwired, like we do now, or the ordering must be defined by some variable that gets passed to all relevant functions.) Such conventions are in principle arbitrary but consistency does matter. Most QC codes follow different orderings, so I guess there is no big advantage for using one over the other.

Some recursion relations are easier to write out with some ordering, which could explain some differences. (That is how I fixed the HORTON conventions.)

[tovrstra]

I'll fix issue #123 first, which will make it easier to implement the reordering in the wrapper. Long-term solution (HORTON 3) is to change the ordering in HORTON.

[SamKChang]

@matt-chan I think the ordering of PySCF follows the convention of NWChem.

[matt-chan]

Yup. We figured that out from talking to Qiming. Thanks for letting me know!

This will definitely be fixed in the next major release of HORTON.

On Mon, 3 Oct 2016 at 10:11 Kuang-Yu Samuel Chang [email protected]
wrote:

@matt-chan https://github.com/matt-chan I think the ordering of PySCF
follows the convention of NWChem.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#87 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA_-NVuiNgcPgGLmuHqbX22qGrP38BhOks5qwQ0GgaJpZM4Ixrva
.