Skip to content
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

Fix issue #377 Make Multiparticle reversible #412

Merged
merged 22 commits into from
Feb 8, 2022
Merged

Conversation

LSchwiebert
Copy link
Collaborator

No description provided.

Copy link
Collaborator

@GregorySchwing GregorySchwing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Introduced a force_inRange array which is used to indicate whether the translation used the force-bias or was random xyz, so the next move can use this information to reverse the move if it so desires. Also, introduced a key variable to r123 calls. Modified the rotation method.

@LSchwiebert
Copy link
Collaborator Author

Thanks for adding a description of the changes. I will test some proposed changes and resubmit the patch for approval.

Copy link
Collaborator

@msoroush msoroush left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just minor change in using random123 for drawing random number in Accept() function and using omp critical in MultiparticleBrownianMotion`.

double accept = MPCoeff * uBoltz;
double pr = prng();
double pr = r123wrapper.GetRandomNumber(newCOMs.Count());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason we dont want to use Mersenne Twister (prng()) here? Since newCOMs.Count() returns the number of molecule (not atoms), we are basically reusing same random number twice.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The molecule indices are numbered 0 - newCOMs.Count() - 1, so this is really a different one from what was used before. Unless I missed something. I was testing some things when I made this change. I can change it back, but I figured in the long run we want o switch to the same RNG for everything, so...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I thought we draw random number for every atom and not molecule. I was wrong though. Up to you if you want to use prng() or random123

Comment on lines 475 to 480
#ifdef _OPENMP
//Even though we call different random123 functions, they all change c[0]
//and use the same rng() function, so they all need to be in the same
//critical section (not different names).
#pragma omp critical
#endif
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, in later version we can implement the random123 CPU version, similar to GPU version to avoid using omp critical overhead.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Yes, I will test and verify that change before merging the patch. I'll push an update if I can get it working without a critical section.

@@ -525,7 +527,7 @@ inline void MultiParticleBrownian::RotateForceBiased(uint molIndex)

matrix = RotationMatrix::FromAxisAngle(rotLen, rot.Normalize());

XYZ center = newCOMs.Get(molIndex);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot make a comment in Line 464, but similar to Multiparticle, we need to use omp critical for XYZ MultiParticleBrownian::CalcRandomTransform(XYZ const &lb, double const max, uint molIndex) function.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I will do that if I can't find a work-around to needing the critical section with the MultiParticle move.

@LSchwiebert
Copy link
Collaborator Author

I have addressed Mohammad's comment about the omp critical section by revising the Random123Wrapper code to use local variables. Also refactored Random123Wrapper to make it easier to maintain and keep the function calls consistent.

Should be ready to merge now.

@LSchwiebert LSchwiebert requested a review from msoroush February 2, 2022 18:13
@LSchwiebert LSchwiebert merged commit bfc8fd0 into development Feb 8, 2022
@LSchwiebert LSchwiebert deleted the multiparticle branch February 8, 2022 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants