m-a-d-n-e-s-s / madness

Multiresolution Adaptive Numerical Environment for Scientific Simulation
GNU General Public License v2.0
181 stars 62 forks source link

Preliminary changes to support periodic MRA-SCF #517

Closed JonathonMisiewicz closed 9 months ago

JonathonMisiewicz commented 10 months ago

For @evaleev review.

Absolutely not to be merged until periodic MRA-SCF is working.

evaleev commented 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

JonathonMisiewicz commented 9 months ago

Moving to jm/cleanup/nuclear-density-functor/.