Clarify angular momentum constraints

[andysim]

First of all, thanks for all of your work on this excellent project! I've been (very belatedly) working to hook the code into Psi4 via the new C++11 interface and have a question about angular momentum requirements. The documentation states that the angular momenta should be ordered as

A >= B, C >= D, CD >= AB

which is consistent with how the original libint was used in both Psi3 and Psi4. While this gives correct energies, it doesn't seem to work for derivatives. If I instead use the ordering

A >= B, C >= D, AB >= CD

I seem to get correct energies and gradients, and this ordering is consistent with the example Hartree-Fock code. Am I correct to assume that this ordering is to be used? Also, am I safe in assuming that the translational invariance relations are always applied, such that the derivative buffers always contain Ax,Ay,Az,Bx,By,Bz,Dx,Dy,Dz,Cx,Cy,Cz? my tests so far seem to indicate that this is true, but I just want to make sure I'm safe to assume this going forwards.

This PR will adjust the couple of places in the docs that I'm aware of the angular momentum requirements being stated - please just close it if I'm wrong about this.

[evaleev]

@andysim this code suggests the documentation is correct. The hartree-fock.cc example does not order shells by L so the loop structure does not ensure iteration over "efficient" unique shell sets. Do you have a reproducer? A unit test would be great ;)

Yes, internally (only) the translational invariance is utilized and the full set of derivatives is returned. It is definitely beneficial for derivatives to use the proper braket type (i.e. not use xx_xx and use unit Shell for the missing functions as it can be done for integrals) to minimize the actual number of derivatives computed (3k for k-center braket).

[andysim]

In trying to make a simple example, I realized that my iterators are screwed up and that the a.m. constraints are exactly as you stated - sorry for the wasted time. I'll go ahead and close this. Just out of interest, how does the HF example work if it does not obey the canonical ordering of a.m.? Is there some branch of the code that recognizes non-canonical ordering and applies permutations to the shells and the computed ints? Thanks for the tip about using unitshell - I am calling the templated compute2 methods right now so I am using xs_xx and friends. Hopefully I won't confuse myself further when I get to density fitted gradients.

[evaleev]

Yes, internally the Engine permutes as needed. But since observable performance is part of the API have to document this, otherwise it should not matter too much.

On Sat, Oct 12, 2019, 3:46 AM Andy Simmonett notifications@github.com wrote:

In trying to make a simple example, I realized that my iterators are screwed up and that the a.m. constraints are exactly as you stated - sorry for the wasted time. I'll go ahead and close this. Just out of interest, how does the HF example work if it does not obey the canonical ordering of a.m.? Is there some branch of the code that recognizes non-canonical ordering and applies permutations to the shells and the computed ints? Thanks for the tip about using unitshell - I am calling the templated compute2 methods right now so I am using xs_xx and friends. Hopefully I won't confuse myself further when I get to density fitted gradients.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/evaleev/libint/pull/151?email_source=notifications&email_token=AAQXIZ62PXTHUIRPPW3Z523QOF6GJA5CNFSM4I72TUX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBBYXLQ#issuecomment-541297582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQXIZZSRYINFNBEEIDAKV3QOF6GJANCNFSM4I72TUXQ .