Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

one- and two-electron operators #289

Open
ilfreddy opened this issue Apr 6, 2020 · 5 comments
Open

one- and two-electron operators #289

ilfreddy opened this issue Apr 6, 2020 · 5 comments

Comments

@ilfreddy
Copy link
Contributor

ilfreddy commented Apr 6, 2020

Is there any good (code-related) reason to keep 1- and 2-el operators separate in the code? As a matter of coding, this distinction seems to me rather arbitrary. I'm starting to code ZORA and I am implementing the ZORA "potential" (1-V/2c^2) and its inverse "kappa". In this first implementation I'm only considering the nuclear potential and therefore the ZORA potential is a 1-el operator. I have also implemented the corresponding kinetic energy operator (p kappa p)/2. As long as V is the nuclear potential all such operators will be 1-el, but as soon as I will add the coulomb and xc pieces, they will become 2-el operators and I will have to move them to the other folder. Does not make much sense to me.

@stigrj
Copy link
Contributor

stigrj commented Apr 6, 2020

At some point in the past these were actually two different base classes OneElectronOperator and TwoElectronOperator. I think it might be a good idea to re-introduce this separation, so that a TwoElectronOperator takes an OrbitalVector as a second argument to setup, instead of to its constructor, i.e. instead of this (P is Poisson operator)

CoulombOperator J(P, Phi);
J.setup(prec);

we do this

CoulombOperator J(P);
J.setup(prec, Phi);

This way the operator is not tied to a particular Phi.

@stigrj
Copy link
Contributor

stigrj commented Apr 6, 2020

But short answer: no it doesn't matter, put it where ever you want

@ilfreddy
Copy link
Contributor Author

ilfreddy commented Apr 6, 2020

But then if you don't need Phi in the constructor, why would you want two base classes? Setup is anyway different for each derived class (or is it?). Or do you assume that each operator has a setup(prec)?

@stigrj
Copy link
Contributor

stigrj commented Apr 6, 2020

All operators must have a setup(prec) function

@ilfreddy
Copy link
Contributor Author

ilfreddy commented Apr 6, 2020

OK. I have no strong opinion about having the base classes. If you thin k it is a good idea, we can do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants