Update OptimizableObject and its usage
Proposed changes
Add OptimizableObject as a base class for classes directly owning variational parameters. No more as base class of WFC/SPOSet. Following this API design. https://github.com/ye-luo/qmcpack/wiki/Optimization-API-changes
What type(s) of changes does this code introduce?
- Refactoring (no functional changes, no api changes)
Does this introduce a breaking change?
- No
What systems has this change been tested on?
epyc-server
Checklist
- Yes. This PR is up to date with current the current state of 'develop'
@PDoakORNL in this PR OptimizableObject is moved out of base classes and added as a base class only on their derived classes with actual optimizable parameters.
Is there a plan to get rid of checkInVariables and resetParameters in favor of using only checkInVariablesExclusive and resetParametersExclusive? (In other words, is having both functions in the API an intermediate state of the code?)
Eventually I would like an API that removes the need to call checkOutVariables to propagate the global-to-local index mapping.
Is there a plan to get rid of checkInVariables and resetParameters in favor of using only checkInVariablesExclusive and resetParametersExclusive? (In other words, is having both functions in the API an intermediate state of the code?)
Yes. SPO/WFC level of checkInVariables and resetParameters will be removed. Not there yet ;)
Eventually I would like an API that removes the need to call checkOutVariables to propagate the global-to-local index mapping.
I found checkOutVariables is still needed, it settings internal state for later evaluateDerivatives. In case of ROHF, there is only one set of sposet but there are two objects. So checkOutVariables needs to be called on both objects and thus needs to be called from TWF tree.
@markdewing Does this PR look good to you?
Test this please