L2 DMC

[jtkrogel]

Putting up this WIP PR to gather feedback on the merge of new DMC projector features for L2 potentials into mainline. I'm particularly interested in any issues spotted relative to #1947.

Please ignore the DMCUpdatePbyPVMC and DMCUpdatePbyPL2VMC classes. These are development scaffolding and will be removed. The main task is to merge DMCUpdatePbyPL2 and DMCUpdatePbyPWithRejectionFast in a manner that is suitable for current mainline.

Other changes of note reside in DriftOperators and QMCHamiltonian.

[qmc-robot]

Can one of the admins verify this patch?

[markdewing]

What's an L2 potential? Is the background published somewhere?

[jtkrogel]

Sorry, this is a pseudo-Hamiltonian in the literature (but with the "a" term set to zero, keeping only the L^2, or "b", term).

See https://doi.org/10.1103/PhysRevLett.62.2088.

[PDoakORNL]

Main thing that I think is going to impact you is the Update layer is removed. advanceWalker is replaced by a static function advanceWalkers See VMCBatched::advanceWalkers, DMCBatched::advanceWalkers.

They're a number of ways we could to deal with specialized updates, since in your case you're only overiding advanceWalkers it suggests that choosing an implementation for advanceWalkers at construction of the driver is sufficient.

class DMCBatched
{
...
using AdvanceWalkersFunction = std::function<void(const DMCBatched::StateForThread&, Crowd&,DriverTimers&,ContextForStep&,bool)>;
DMCBatched(...,advanceWalkers) : ... advanceWalkers_(advanceWalkers) {}
...
AdvanceWalkersFunction advanceWalkers_;
...
}

class DMCL2Advance {
void operator()(const DMCBatched::StateForThread& sft, Crowd& crowd, ContextForSteps& move_context, bool recompute)
{
...
}

I think its clear much of the advanceWalkers_ code is actually shared, the specialized section is a subset of this, how consistent and how small will require an examination of different update codes we actually want to keep.

[jtkrogel]

This branch is now up to date with develop. I'm going to add a deterministic test, clean up the code a bit, and then request a merge.

It will be good to have this functionality released prior to the move to batched drivers as it is a core technology for the Reboredo FWP. Having tests, etc, merged will also facilitate the transition to batched drivers when they are ready.

[jtkrogel]

Ready for merge.

[ye-luo]

Okay to test

[prckent]

@jtkrogel What are you thoughts on the mixed precision builds that are failing in the CI? Hopefully they are small fixes.

[jtkrogel]

Mixed precision build issues should be resolved now.

[ye-luo]

@jtkrogel could you resolved the reorder warning. Basically the declaration order is not consistent with the constructor initialization order.

[ye-luo]

I fixed the GCC reorder warning. Get this in before the upcoming release.