-
Notifications
You must be signed in to change notification settings - Fork 141
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
Refactor grid randomization #4363
Conversation
Extract the storage and generation of the random rotation matrix to make it easier to test. Fix the issue in QMCPACK#4362 where the distribution of the rotations does not cover the entire sphere.
class RandomRotationState | ||
{ | ||
public: | ||
using RealType = QMCTraits::RealType; |
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.
Delete Type from name, the capitalization already indicates this is a type.
RandomRotationState() : rng_vals_({0.0, 0.0, 0.0}) {} | ||
RandomRotationState(RandomGenerator& rng) : rng_vals_({rng(), rng(), rng()}) {} | ||
|
||
TensorType getRandomRotationMatrix() const |
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.
I think this should just be a function that takes a RNG and returns a random rotation matrix.
@@ -866,13 +865,9 @@ void NonLocalECPComponent::evaluateOneBodyOpMatrixdRContribution(ParticleSet& W, | |||
} | |||
|
|||
///Randomly rotate sgrid_m | |||
void NonLocalECPComponent::randomize_grid(RandomGenerator& myRNG) | |||
void NonLocalECPComponent::randomize_grid(const RandomRotationState& rs) |
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.
Note that there is also NonLocalECPComponent::randomize_grid(std::vector& sphere, RandomGenerator& myRNG). From what I can tell, this is only used by the legacy NonLocalECPotential_CUDA.cpp. For consistency, should that randomize_grid call be changed as well since the legacy code hasn't been removed yet?
That probably breaks more tests and since we are eventually dropping the legacy, maybe it isn't worth changing. But it seems to me things should be done consistently for whatever is actively in the code base.
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.
Indeed, we will want to fix this everywhere.
The code used by the legacy CUDA code paths will also need to be updated.
There will have to be some discussion around updating the tests. This will be a significant effort even for the smallest possible update and likely need parallelizing over multiple people.
Also make fix in CUDA code.
Add a python script to generate the values (based on comments from the original code)
I experimented with an ugly bash-awk-sed combination to update the test values for all CPU build variants as well as for the legacy CUDA variants. It looks like nearly all of the updates can be automated this way. Estimators such as the density will have to be updated by hand. Should I pursue this or is anyone else close to a clean solution? |
Test this please |
I have a fully updated set of reference values in #4383 that passes CI. They could be merged independently of this refactor or pulled into this PR. The conflict in this PR also needs fixing. What are the preferred next steps? Who has bandwidth? |
I think #4383 should be merged independently. |
Add some documentation to generateRotationMatrix
Keep the parts that don't depend on the RNG in Numerics, change those names to RotationMatrix3D, and put the parts that depend on the RNG in QMCHamiltonians.
Test this please |
PPset[ipp]->randomize_grid(*myRNG); | ||
{ | ||
TensorType rmat = generateRandomRotationMatrix(*myRNG); | ||
PPset[ipp]->randomize_grid(rmat); |
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.
Could you fuse them into one line and keep the code concise?
The order of function argument evaluations is undefined in the standard. This leads to a difference in evaluation order between debug and release builds, which causes the order of rng1, rng2, and rng3 to be swapped. In debug builds, the arguments get placed on the stack in the reverse order listed. In release builds, the code is likely inlined, and the arguments effectively get evaluated in the forward order listed.
From random_grid to rotateQuadratureGrid
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.
Is it time to remove the WIP tag?
Test this please |
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.
LGTM. Still need non-ANL approval.
… into random_rotation
Test this please |
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.
The python code needs a description at the top saying what it is, what it was used for, where the output went, when it would need to be rerun etc.
Good to see the nearly 100% patch coverage
Also update the script to match a fix for the complex build.
Test this pleas |
Test this please |
Fixes the issue raised in #4362. There will be a lot of CI failures. Not sure the best way to approach the fix and updating the deterministic tests. This is a start to at least introduce a possible fix.
Does some refactoring to put the inputs to the random rotation matrix into their own class. The generation of the rotation matrix is extracted from the randomize_grid function, to make it testable in isolation.
A single unit test is added to the rotation matrix - will need more in the future.
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?
desktop
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.