Fix Lattice + OpenBC in batched drivers

[ye-luo]

Proposed changes

When using spline orbitals with boundary condition "n", legacy drivers does one more check when a step is proposed. If the new position is located out of the box in any of the direction marked "n", the proposed move is marked invalid. This bug fixes handled this case.

Think about running a single atom VMC using HF with QE WF and then use "n n n". if electrons are allowed outside the box, the wavefunction norm is infinite due to finite electron density everywhere. Confining electrons within the box prevents this bad situation effectively making electron density 0 outside the box.

Another note. makeMoveAndCheck also rejects moves larger than half of the box as long as a lattice is defined. This is not implemented in the batched API. However, this requires me to regenerate reference numbers for deterministic-diamondC_2x1x1_pp-vmcbatch-dmcbatch-mwalkers-serialized_sdj tests.

What type(s) of changes does this code introduce?

• Bugfix

Does this introduce a breaking change?

• No

What systems has this change been tested on?

Bora

Checklist

• Yes. This PR is up to date with current the current state of 'develop'
• Yes. Code added or changed in the PR has been clang-formatted

[ye-luo]

Test this please

[ye-luo]

Test this please

[ye-luo]

Series 0 is VMC, 1 is DMC.
Legacy

(base) yeluo@bora:/scratch3/yeluo/debug/TEST_batch_small/legacy$ qmca -q ev dmcleg.s00?.scalar.dat
 
                            LocalEnergy               Variance           ratio 
dmcleg  series 0  -36.538548 +/- 0.012871   3.494229 +/- 0.114336   0.0956 
dmcleg  series 1  -36.853090 +/- 0.003588   2.724231 +/- 0.018199   0.0739 

batch before fix

(base) yeluo@bora:/scratch3/yeluo/debug/TEST_batch_small/batch_bad$ qmca -q ev dmc.s00?.scalar.dat
 
                            LocalEnergy               Variance           ratio 
dmc  series 0  -31.004785 +/- 1.808544   21.503997 +/- 6.378338   0.6936 
dmc  series 1  -36.463603 +/- 0.007947   2.973913 +/- 0.021162   0.0816 

batch after fix

(base) yeluo@bora:/scratch3/yeluo/debug/TEST_batch_small/batch$ qmca -q ev dmc.s00?.scalar.dat
 
                            LocalEnergy               Variance           ratio 
dmc  series 0  -36.534624 +/- 0.013333   3.501475 +/- 0.144681   0.0958 
dmc  series 1  -36.852782 +/- 0.004356   2.705856 +/- 0.015095   0.0734 

[ye-luo]

Test this please

[prckent]

Thanks so much for tracking this down.

I was tempted to ask about masking the work in the use_drift section of VMCBatches.cpp:136+ and the similar section of DMCBatched.cpp:201+, where we might have invalid moves… but do you agree that updating the function signatures wouldn’t bring enough benefit given it is a rare event?

I will ask if we are certain it is safe to call the functions in these regions with invalid moves?

I think it is safe with the current implementations but the comments/docs for the WaveFunctionComponents and ParticleSet should be updated with a suitable note/warning that they have to handle arbitrary positions.

[ye-luo]

Calculating drift (flex_calcRatioGrad) is fine even positions are invalid because all our SPOs can be evaluated at any position. Jastrows are always defined throughout the space as required by LCAO molecule cases. There is no need to mask use_drift.

"handle arbitrary positions" is a vague requirement. Sometimes, we just need WFCs to run as the results will be discarded regardless. I don't think feel the necessity to put extra note on WFC which might cause unnecessary confusion to developers. The handling is at driver level with both ParticleSet and TWF involved, Individual WFC doesn't need to take responsibility.

PaticleSet yes, I added an extra note mw_makeMove, "Note that: drivers should reject invalid moves." PSdispatcher::flex_makeMove actually requires std::vector<bool>& are_valid return.

[prckent]

The code coverage report reminds us that the CoordsType::POS_SPIN code path is not hit here. Not a big deal given the simplicity and that we are presumably missing that in lots of places. Something to chip away at in future.