-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parameter derivatives for SOECPotential #4418
Conversation
this changes the reference values by adding a 2body jastrow and another electron to the wave function. This is needed in order to add tests on WF parameter derivatives since the current wave function (using FreeOrbital SpinorSets) doesn't have any free parameters. My soecp_eval_reference code adds a simple bspline and evaluates it...it is validated against gen_bspline_jastrow.py and test_J2_bspline.cpp
Test this please |
throw std::runtime_error("SOECPComponent::evaluateValueAndDerivatives should not be called in real build\n"); | ||
#else | ||
if (sknot_ < 2) | ||
APP_ABORT("Spin knots must be greater than 2\n"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not "greater equal"?
Could you move this check where sknot_ is set?
APP_ABORT better using exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
Tests were failing with the real build for my initial PR because I have data that needs to interface with WF APIs and thus need to be ValueType....but part of the SOECP eval is inherently complex. Problem line was wvec_[iq] = lsum * psiratio_[iq] * spin_quad_weights_[iq]; lsum has to be ComplexType (due to the ldots matrix element that is carried out) but wvec_ needs to be ValueType for the subsequent gemv call to get the dhpsioverpsi correct. I wasn't sure of the cleanest way to fix this...basically none of the spinor and SOECP stuff should ever be used if it is a real build in the first place but it seems we don't have perfect guards in place. I tried to modify the CMakeLists to only build SOECPotential/SOECPComponent if QMC_COMPLEX, but that left a lot undefined symbols due to the ECPotential/ECPComponent builders. So I resorted to adding an ifdef for now in the evaluateValueAndDerivatives...which I don't like because I know we are trying to move away from that but that was the simplest solution I came up with. If anyone has a better solution, let me know |
Test this please |
Please review the developer documentation
on the wiki of this project that contains help and requirements.
Proposed changes
This PR implements parameter derivatives for the SOECPotential. This closes #4297
Note that I had to modify the SOECP unit test a bit in order to have a wave function that could be optimized. The new reference values are all obtained from the standalone code soecp_val_reference.cpp in QMCHamiltonians/tests. This implements everything from scratch and uses finite differences to obtain the reference values.
What type(s) of changes does this code introduce?
Delete the items that do not apply
Does this introduce a breaking change?
What systems has this change been tested on?
M1 mac
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.