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

Multiparticle move error: #441

Open
jpotoff opened this issue Jun 7, 2022 · 6 comments
Open

Multiparticle move error: #441

jpotoff opened this issue Jun 7, 2022 · 6 comments
Assignees

Comments

@jpotoff
Copy link
Collaborator

jpotoff commented Jun 7, 2022

During GEMC simulations of C12H26, simulations using 1% multiparticle move may fail with this error. There is a correlation with temperature and density. The error is more prevalent for simulations near Tr=0.7 (higher density).
mp_crash.zip

Error: Trial Displacement exceeds half the box length in Multiparticle move!
       Trial transformation vector: [-4.1427e+01, 4.2487e+01, 2.2134e+01]
       Box Dimensions: [8.4888e+01, 8.4888e+01, 8.4888e+01]
This might be due to a bad initial configuration, where atoms of the molecules
are too close to each other or overlap. Please equilibrate your system using
rigid body translation or rotation MC moves before using the Multiparticle
move.
@LSchwiebert
Copy link
Collaborator

I'm unable to reproduce this consistently with the provided test case. It did occur once or twice, but not enough for me to be able to debug the problem. If you can provide a better test case, that would be ideal.

Because the MP move produces some slight round-off in the results, frequent checkpointing (every few thousand moves) would make it more likely to be able to reproduce the problem by restarting the simulation.

@jpotoff
Copy link
Collaborator Author

jpotoff commented Dec 12, 2022

The Brownian multiparticle move is totally unstable for this system
NEMTC2.zip
, even with an equilibrated initial configuration. Using GOMC version 2.75a (main)

@LSchwiebert
Copy link
Collaborator

For the example that you have, the problem is there are two particles (one in molecule 115 and one in molecule 375) that are too close, so generating too much force. The locations of the two particles are:

{x = 35.788, y = 3.624, z = 27.02}

and

{x = 35.312121251361688, y = 1.474629798157524, z = 27.47257217106413}

I will look into it some more. It's possible that some previous BM MP move is bringing these too close together.

@LSchwiebert LSchwiebert self-assigned this Dec 20, 2022
@LSchwiebert
Copy link
Collaborator

The NeMTMC move is, because of random sampling, performing a Regrowth move that is moving molecule 375 to a location that is closer to molecule 115. I can look into whether the Regrowth move is accepting a move that it shouldn't or calculating the energies incorrectly, but that seems unlikely. Here are the old and new energies for the molecule for this move:

Old: intraBond = 2421.0172370239925, intraNonbond = -151.91710368507319, inter = 25482.566079823038
New: {intraBond = 1985.1929760199696, intraNonbond = 1567.1178294113402, inter = 19098.893020986743

These changes look reasonable, but moving the particles this close (the square of the distance changes from 16.643842233786 to 5.069576514725) results in a force that pushes one of the molecules too far away.

This seems more like an algorithmic problem that we need to sort out. One option would be to not exit and instead generate a warning, but continue without accepting that move. It's clear that in this case, we are moving the molecule just beyond the edge of half the bounding box and some other random choices would later work.

@jpotoff
Copy link
Collaborator Author

jpotoff commented Dec 20, 2022

I think part of the issue may stem from the non-equilibrium transfer move. I'm not sure if we are applying the standard acceptance criteria to regrowth moves during the non-equilibrium part of the move, since we do a check for acceptance/rejection at the end of the entire sequence of moves.

@LSchwiebert
Copy link
Collaborator

LSchwiebert commented Dec 20, 2022

That seems likely, as we make accept or reject the Regrowth move during that particular step of the NeMT move, not at the end. In other words, we are applying the standard acceptance criteria of the Regrowth move in the midst of the NeMT move, but I'm uncertain if we retain that acceptance if we reject at the end of the NeMT move.

Perhaps we rollback those changes at the end of the NeMT move. (I can check that.) But, even in that case, we still need to handle the change for the rest of the BM steps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants