Closed JonathonMisiewicz closed 9 months ago
For OBC having atoms on the boundary is invalid ... so maxR=1 is the "right" thing even for OBC. However, indeed, it makes sense to make maxR for nonperiodic dimensions to be 0, and 1 for periodic dimensions.
On Tue, Feb 6, 2024 at 9:19 AM Jonathon Misiewicz @.***> wrote:
@.**** commented on this pull request.
In src/madness/chem/potentialmanager.h https://github.com/m-a-d-n-e-s-s/madness/pull/517#discussion_r1479898385 :
@@ -106,6 +106,49 @@ class CoreOrbitalDerivativeFunctor : public FunctionFunctorInterface<double,3> { }; };
+class NuclearDensityFunctor : public FunctionFunctorInterface<double,3> {
I understand how the existing code isn't supporting non-periodic dimensions properly, and why we'd need multiple R. I don't understand the problem with the first point. My understanding was that maxR was needed for adding periodic images on the boundary. The plan (which I'll need to revise because only some dimensions may be periodic) was that the maxR = 0 constructor was for the non-periodic case, and maxR = 1 was for periodic. Is there some reason why I want maxR = 1 even in the case of OBC?
— Reply to this email directly, view it on GitHub https://github.com/m-a-d-n-e-s-s/madness/pull/517#discussion_r1479898385, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQXIZZ4PVGBG3A6PB3GJ7DYSI3YVAVCNFSM6AAAAABBYIJHU2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQNRVGM2DENBVGI . You are receiving this because you were mentioned.Message ID: @.***>
-- web: valeyev.net
Moving to jm/cleanup/nuclear-density-functor/
.
For @evaleev review.
Absolutely not to be merged until periodic MRA-SCF is working.