Seperate J and K Builders

On J and K builders note also that these matrices are amenable to different approximations. Methods such as Fast Multipoles can be applied effectively to the generation of the Coulomb interaction but not to the exchange term (for approximations to the J-term see for example https://aip.scitation.org/doi/10.1063/1.4891797). So in that sense it is a good idea to keep them separate. The real problem with keeping them separate is the doubling of the 2-electron integral evaluation cost. I guess it would take constructing (or finding) a model to see if there are any conditions under which certain approximations to the integrals that can be made if J and K are done separately that generate enough of a gain to win over the initial doubling of the work.

From the perspective of designing the code I don’t see a real problem with writing the Hamiltonian as

            H=T+V+J+K

Where T is kinetic energy, V is the nuclear attraction, J the Coulomb interaction and K the exchange term. The only real problem here is the separation of V and J. For efficiency you would want to merge those two as their sum should go to zero for interactions with remote parts of a system. I.e. the better approach would to be write the Hamiltonian as

            H=T+C+K

Where C is the sum of all Coulomb interactions (both 1- and 2-electron), i.e. C=V+J. Historically V and J have been separated, presumably because the algorithms involved are very different. Nevertheless, note that if we want to calculate the Coulomb interaction of a test charge with the rest of the system then as r-->infinity C-->0 whereas V-->-infinity and J-->+infinity.

Hubertus van Dam, 631-344-6020, hvandam@bnl.gov Brookhaven National Laboratory

From: Ryan Richard notifications@github.com Reply-To: NWChemEx-Project/LibChemist reply@reply.github.com Date: Thursday, September 27, 2018 at 2:34 PM To: NWChemEx-Project/LibChemist LibChemist@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [NWChemEx-Project/LibChemist] Seperate J and K Builders (#49)

While direct SCF will want to build J and K together, there's not really a benefit to building them together for core. For DFT one may not even need K.

Point is we should probably also allow for separate J and K builders. I guess we'd have one JKBuilder that just combines the results so that way the FockBuilder can always be written in terms of a JKBuilder? Maybe we have two FockBuilders one that assumes J and K are separate builds and one that assumes they're together? Guess I'm not sure how to generalize this...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/NWChemEx-Project/LibChemist/issues/49, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEcvnhHyrnmRtse6-U05BAK6DuQ3ZNY2ks5ufRpCgaJpZM4W9Oh_.

NWChemEx / Chemist

Seperate J and K Builders #49