Add delay_rank to driver input

[jtkrogel]

The delay_rank parameter should be settable in the driver input. There are a few benefits to enabling this:

• It will no longer (necessarily) be inherited as state between old wavefunction optimization runs and new VMC/DMC runs.
• This will enable runtime optimization scans over subsequent VMC blocks (very similar to using variable target_walkers to optimize gpu performance). Better to do this in a single submission and not require multiple submissions.
• This will enable a direct path to support this parameter in Nexus (w/o risking clobbering of user request via imported wavefunctions from prior runs).

This should be a simple feature to implement once there is time.

[prckent]

Alternative scheme: We write some code to auto-tune the delay rank and avoid needing to specify it at all apart from developer nerd runs. The code is then automagically near enough to optimal and there is no need to specify wavefunction updating parameters in the driver.

We want to avoid something like the pools and band group setting in QE or the nsim and ncpu tags in VASP that in my experience are approximately never set optimally by users.

[jtkrogel]

I agree. One less hyperparameter to tune user side is a win all around in my book. This should become the default behavior eventually. Walker count performance tuning would be another good target.

Still, being able to vary delay_rank easily in the input until then is a good step.

[prckent]

Can you live with the setting in the wavefunction specification for now?

    <wavefunction name="psi0" target="e">
         <determinantset type="einspline" href="pwscf.pwscf.h5" tilematrix="2 0 0 0 1 0 0 0 1" twistnum="0" source="ion0" meshfactor="1.0" precision="double">
            <slaterdeterminant delay_rank="5">
               <determinant id="updet" size="8">
                  <occupation mode="ground" spindataset="0"/>
               </determinant>
               <determinant id="downdet" size="8">
                  <occupation mode="ground" spindataset="0"/>
               </determinant>
            </slaterdeterminant>
         </determinantset>
         <jastrow type="One-Body" name="J1" function="bspline" source="ion0" print="yes">

[jtkrogel]

Sure. I probably just won't support it (well) in Nexus. That whole input block can get overwritten by wavefunction optimization runs.

I could write it to the input initially and basically give no guarantees. For simple Jastrow optimization, that might be fine. Thoughts?

[prckent]

Perhaps poll others on Slack? I am OK with the no guarantee route. Less work, more motivation to implement this code soon.

Is it Nexus doing the ignoring/overwriting or is it the writer of the wavefunction block XML that needs to be updated in QMCPACK with this flag though? (bug in QMCPACK if the latter, easy fix).

[jtkrogel]

I will put in the "no guarantee" route for now.

QMCPACK is writing it out. Nexus copies the XML that is written out from a past optimization run into the current one, so the state in the prior run for delay_rank effectively sets it for the new one (this is the hazard of placing a driver parameter in the trial wavefunction). This will be true of the traditional <include/> route as well.