qmcpack icon indicating copy to clipboard operation
qmcpack copied to clipboard

[WIP] Orbital rotation optimization prototype

Open markdewing opened this issue 3 years ago • 0 comments

This implements option 2 in https://github.com/QMCPACK/qmcpack/issues/3983#issuecomment-1197380631 It saves a history of applied rotations.

One purpose of this PR is allow others to test orbital rotation (@anbenali ). Variational parameters can be saved and restored from the vp.h5 file, though this is still a prototype. RHF wavefunctions, where the up and down coefficients should be constrained to the be the same is not implemented. For testing I've used separate coefficient matrices and let them vary separately.

The problem with previous code is that checkInVariables is used to signal the beginning of an optimization cycle. This function does not get called on all the clones, so it is not a good choice for this signal.

The rotation code depends on two things in the call to checkInVariables:

  1. Sets the parameters to zero in order to get the parameter change when resetParameters gets called.
  2. Stores the rotated coefficient matrix for later use.

The new code addresses these as:

  1. Computes the delta between old parameters (in myVars) and the new parameters (in active). This also has the effect that calling resetParameters multiple times with the same parameters will have no effect.
  2. Always applies the rotation from the existing coefficient matrix - no copy is saved. This should work for both the LCAO and spline code. (The spline code doesn't implement saving the coefficient matrix - with this change it does not need to).

One problem that arises is the coefficient matrix is stored as a shared pointer, and is shared among the clones. If multiple threads call resetParameters, the rotation gets applied multiple times.

The hack to fix this here is to use the fact that checkInVariables (the irony!) is only called on one clone, and use that clone to perform the rotation. This should be changed to something better before going into the code.

The mechanism to save and restore extra parameter information in the HDF file is to add two new functions in TWF (saveExtraParameters/readExtraParameters) and various pieces in the wavefunction hierarchy. The hdf_archive object is pulled out of saveAsHDF/readFromHDF so it can be passed to save/readExtraParameters.

The SPOSet version of save/readExtraParameters has an id parameter to distinguish between up and down electrons.

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

Delete the items that do not apply

  • New feature

Does this introduce a breaking change?

  • No

What systems has this change been tested on?

laptop

Checklist

Update the following with a yes where the items apply. If you're unsure about any of them, don't hesitate to ask. This is simply a reminder of what we are going to look for before merging your code.

  • 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
  • No. This PR adds tests to cover any new code, or to catch a bug that is being fixed
  • No. Documentation has been added (if appropriate)

markdewing avatar Aug 01 '22 05:08 markdewing