OrbOpt parameters are not correctly reported if read from vp.h5 file

[jptowns]

Describe the bug In an orbopt calculation, one can specify parameters manually using the "opt_vars" parameter:

    <sposet_collection type="bspline" source="i" href="wfn.h5" tilematrix="1 0 0 0 1 0 0 0 1" gpu="no" meshfactor="1.0" twist="0  0  0"\
 precision="double">
      <rotated_sposet name="rot-spo-up" method="global">
        <opt_vars>
          0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1
          0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
          0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
          0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
          0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
          0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
          0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
          0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
          0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
          0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
        </opt_vars>
        <sposet name="spo-up" size="24">
          <occupation mode="ground" spindataset="0"/>
        </sposet>
      </rotated_sposet>
      <rotated_sposet name="rot-spo-dn" method="global">
        <sposet name="spo-up" size="24">
          <occupation mode="ground" spindataset="0"/>
        </sposet>
      </rotated_sposet>
    </sposet_collection>

And QMCPACK properly reports these parameters at the start of a calculation:

Orbital rotation using global rotation
nparams_active: 80 params2.size(): 80
                Parameter name               Value
rot-spo-up_orb_rot_0000_0004                 1.000000e-01 0 1  ON 0
rot-spo-up_orb_rot_0000_0005                 1.000000e-01 0 1  ON 1
rot-spo-up_orb_rot_0000_0006                 1.000000e-01 0 1  ON 2
rot-spo-up_orb_rot_0000_0007                 1.000000e-01 0 1  ON 3
rot-spo-up_orb_rot_0000_0008                 1.000000e-01 0 1  ON 4
rot-spo-up_orb_rot_0000_0009                 1.000000e-01 0 1  ON 5
rot-spo-up_orb_rot_0000_0010                 1.000000e-01 0 1  ON 6
rot-spo-up_orb_rot_0000_0011                 1.000000e-01 0 1  ON 7
rot-spo-up_orb_rot_0000_0012                 0.000000e+00 0 1  ON 8
rot-spo-up_orb_rot_0000_0013                 0.000000e+00 0 1  ON 9
rot-spo-up_orb_rot_0000_0014                 0.000000e+00 0 1  ON 10
rot-spo-up_orb_rot_0000_0015                 0.000000e+00 0 1  ON 11
rot-spo-up_orb_rot_0000_0016                 0.000000e+00 0 1  ON 12
rot-spo-up_orb_rot_0000_0017                 0.000000e+00 0 1  ON 13
rot-spo-up_orb_rot_0000_0018                 0.000000e+00 0 1  ON 14
rot-spo-up_orb_rot_0000_0019                 0.000000e+00 0 1  ON 15
rot-spo-up_orb_rot_0000_0020                 0.000000e+00 0 1  ON 16
rot-spo-up_orb_rot_0000_0021                 0.000000e+00 0 1  ON 17
rot-spo-up_orb_rot_0000_0022                 0.000000e+00 0 1  ON 18
...

However, if instead the <opt_vars> tag is not used and the parameters are supplied via "override_variational_parameters", QMCPACK incorrectly reports zero rotation. Starting a fresh calculation with <override_variational_parameters/>:

<qmcsystem>
  <wavefunction>
    <sposet_collection type="bspline" source="i" href="wfn.h5" tilematrix="1 0 0 0 1 0 0 0 1" gpu="no" meshfactor="1.0" twist="0  0  0"\
 precision="double">
      <rotated_sposet name="rot-spo-up" method="global">
        <sposet name="spo-up" size="24">
          <occupation mode="ground" spindataset="0"/>
        </sposet>
      </rotated_sposet>
      <rotated_sposet name="rot-spo-dn" method="global">
        <sposet name="spo-up" size="24">
          <occupation mode="ground" spindataset="0"/>
        </sposet>
      </rotated_sposet>
    </sposet_collection>

    <determinantset>
      <slaterdeterminant delay_rank="1">
        <determinant sposet="rot-spo-up"/>
        <determinant sposet="rot-spo-dn"/>
      </slaterdeterminant>
    </determinantset>

<override_variational_parameters href="c2qmc.s099.vp.h5"/>
  </wavefunction>
</qmcsystem>

Results in zero rotations being reported:

Orbital rotation using global rotation
nparams_active: 80 params2.size(): 0
                Parameter name               Value
rot-spo-up_orb_rot_0000_0004                 0.000000e+00 0 1  ON 0
rot-spo-up_orb_rot_0000_0005                 0.000000e+00 0 1  ON 1
rot-spo-up_orb_rot_0000_0006                 0.000000e+00 0 1  ON 2
rot-spo-up_orb_rot_0000_0007                 0.000000e+00 0 1  ON 3
rot-spo-up_orb_rot_0000_0008                 0.000000e+00 0 1  ON 4
rot-spo-up_orb_rot_0000_0009                 0.000000e+00 0 1  ON 5
rot-spo-up_orb_rot_0000_0010                 0.000000e+00 0 1  ON 6
rot-spo-up_orb_rot_0000_0011                 0.000000e+00 0 1  ON 7
rot-spo-up_orb_rot_0000_0012                 0.000000e+00 0 1  ON 8
rot-spo-up_orb_rot_0000_0013                 0.000000e+00 0 1  ON 9
rot-spo-up_orb_rot_0000_0014                 0.000000e+00 0 1  ON 10
...

This matters because it makes it look as rotation i/o does not work. One can easily verify that the rotations are recorded in the vp.h5 file, and that the energy/variance is different from no rotation. But looking only at the output file one might conclude that no rotation was applied. But it is applied, just not accurately reported.

To Reproduce Tested using qmcpack/develop 8658ea9bec1271069c5779e79180fba0adc3a68e (27 July)

Expected behavior I expected the wavefunction parameters to be read and reported accurately.

System: RHEL8 gcc

Additional context Add any other context about the problem here.

[markdewing]

The subtle part is the values themselves don't matter, and past the first rotation, the actual values are meaningless. The difference in values between calls to apply the rotation is what actually matters to the algorithm.

However, I do appreciate your point about the user-interface aspect of this, and having the parameters show up as zero does make it appear as if the code isn't working. It might be tricky to set the initial values that show up to something other than zero.