Operator Design

[ryanmrichard]

          The outstanding issue now is that

src/scf/gradients/scf_grad.cpp

hard codes a bunch of terms that combined form the total gradient. Ideally we should have something more flexible. The OpType argument passes a Hamiltonian $H(T,V,Vee,Vnn,S)$ indicating all the terms that need to be evaluated. However, I am not sure if we can loop over these terms and compute them as they involve different data types. Another way something similar could be done is to introduce null operators. Then, for example, in a Hartree-Fock calculation one can replace the exchange-correlation term with the null operator which would just return an empty tensor. This way one cannot extend the terms beyond the ones that are anticipated but for a more limited set one could skip the terms that are not needed (I assume that calling a module and immediately returning an empty tensor does not cost much and that adding a zero tensor doesn't cost much either), or is there a way to be more flexible than that? Is there some code I could steal some ideas from?

Originally posted by @hjjvandam in https://github.com/NWChemEx-Project/SCF/issues/187#issuecomment-1502295383

[ryanmrichard]

This is something that's been on the radar, but we never wrote it down. We've got two competing pressures: wanting to be able to use types to distinguish between terms, and wanting to use the terms in a generic way.

Conceivably we could do some sort of visitor pattern, where the visitor would define a handler for each operator it knows how to handle. The various driver modules would then create a visitor, loop over terms in the operator, and pass the visitor to each term in the operator.

IMHO there should be an error if the Hamiltonian contains a term the visitor doesn't know how to handle as that amounts to the user requesting a feature which isn't implemented.