-
Notifications
You must be signed in to change notification settings - Fork 139
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
Virtual move Monte Carlo #1969
Virtual move Monte Carlo #1969
Conversation
ClusterData is a more accurate name than LinkerData since it stores information about the cluster that's being built up, which does contain information about the linkers, but that's not it's main purpose.
The way I implemented the rotate moves, the cluster's center of rotation was always the origin. This has the effect that the particles became confined to the insphere of the simulation box. I only noticed this when I ran simulations of larger systems.
and some other stuff.
Must totally abort the cluster move if any of the linker particles start or end up in the inactive region. Perhaps an optimization opportunity: once a linkee has been definitely added to the cluster, check its current and trial position to see if it starts or ends up in the inactive region. That would give you a much earlier early exit (compared to what we do now) since you wouldn't have to continue checking the rest of the current or following linkers' neighbors for overlaps/pair energies.
This is the mode that allows for the cluster cleaving version of the algorithm as described in the SI of Whitelam and Geissler.
Best to get the main implementation into HOOMD and then test experimental features since it will be easier to validate the straightforward implementation.
…option Also count the number of AABBTree builds triggered by the VMMC updater.
Move buildAABBTree to end of loop so that I minimize the number of times I get the array handles.
This was causing the tree to never be rebuilt because the particles were wrapped back into the primary image before the displacement check was performed. And since the diaplacement check used the minimum plane-to-plane distance, the particle could never really move far enough to trigger a rebuild. This may have been leading to rare overlaps.
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This pull request has been automatically closed because it has not had recent activity. |
…l-move-monte-carlo
0. Do not try to add ghost particles to the cluster. This was causing a memory access error in MPI simulations, but is fixed with this commit. 1. Invalidate the move if the reverse move puts the particle in the inactive region 2. access tags array in same scope as positions and orientations
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This pull request has been automatically closed because it has not had recent activity. |
Description
Motivation and context
Resolves #???
How has this been tested?
Checklist:
sphinx-doc/credits.rst
) in the pull request source branch.CHANGELOG.rst
following the established format.