Generalized erfc integrals

[andysim]

For range separated DFT functionals, we need a K - b wK terms, where a and b are scalars, K is the full (1/r12) exchange operator and wK is the long-range (erf(w r12)/r12) exchange term. In Psi4 we currently construct two different integral objects to handle these two terms but, if I'm not mistaken, they could be computed simultaneously by generalizing the erfc kernel from

(1 - erf(w R)) / R

to

(a - b erf(w R)) / R

If I'm understanding this correctly, it should just be a case of injecting the appropriate coefficients into the fundamental integrals. I'd be happy to tackle this if it's something you think is reasonable but I'm not sure of the best way to do it. Would creating a new generalized erfc class make more sense than adapting the current one? Is it best to have default parameters defining the regular erfc and allow the constructor to take a and b in the parameter pack in addition to w, or is a post-construction setter function more appropriate? Any advice is greatly appreciated. Thanks, Andy.

[evaleev]

Andy, new op type would be preferred. Unfortunately adding new type requires touching several code points (damn irreducible complexity).

On Tue, Nov 19, 2019, 11:46 AM Andy Simmonett [email protected] wrote:

For range separated DFT functionals, we need a K - b wK terms, where a and b are scalars, K is the full (1/r12) exchange operator and wK is the long-range (erf(w r12)/r12) exchange term. In Psi4 we currently construct two different integral objects to handle these two terms but, if I'm not mistaken, they could be computed simultaneously by generalizing the erfc kernel from

(1 - erf(w R)) / R

to

(a - b erf(w R)) / R

If I'm understanding this correctly, it should just be a case of injecting the appropriate coefficients into the fundamental integrals https://github.com/evaleev/libint/blob/master/include/libint2/boys.h#L1719-L1736. I'd be happy to tackle this if it's something you think is reasonable but I'm not sure of the best way to do it. Would creating a new generalized erfc class make more sense than adapting the current one? Is it best to have default parameters defining the regular erfc and allow the constructor to take a and b in the parameter pack in addition to w, or is a post-construction setter function more appropriate? Any advice is greatly appreciated. Thanks, Andy.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/evaleev/libint/issues/153?email_source=notifications&email_token=AAQXIZ7EYW6LTCLW7BPV5B3QUQJ4ZA5CNFSM4JPGGHD2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H2M3TCQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQXIZY6WACRCJ4KRFDCHDDQUQJ4ZANCNFSM4JPGGHDQ .

[andysim]

Great - thanks very much for the speedy feedback. I'll have a stab at getting something working and will make a PR if I do.