Hello,
I’d like to submit a feature request for Hybrid Monte Carlo (HMC) simulations. At present, one can do mixed MD/MC using a combination of ‘fix gcmc’ and a time integration fix. However, there’s no way to accept/reject the MD moves that take place between the steps when ‘fix gcmc’ is invoked. I believe that such accept/reject rules are formally necessary to provide detailed balance for proper sampling. (Velocity re-randomization is also necessary, but this can be currently implemented by the user looping between ‘velocity create’ and ‘run’ commands.)
I’m not sure of the best implementation for this feature. I think it’d probably be best to add a keyword to ‘fix gcmc’ to do this, and then LAMMPS would save the state at the end of the Monte Carlo moves and compare it to the energy of the state when the Monte Carlo moves next begin.
I might be able to implement this myself, but I wanted to check first to see if this feature is already being developed and to see what else the developers or other users thought about this.
you may have a better chance for this to remain visible to LAMMPS
developers, if you submit your feature request on github as an issue.
axel.
Efrem - long ago I wrote a sample “hmc” command in collaboration
with Ed Maginn (UND) to try out HMC in LAMMPS.
We were never totally happy with how it worked, so
it was never released. I will send you a small
tarball with the code (single command) and doc
page.
It would be great if you want to modify/test it and
see if you can make it work and release it.
Steve
Looks like this is something I might be implement to do as a nice exercise. The “hmc” code is pretty much as simple as I suspected, and provides me some nice guidance for good ways to implement saving positions and forces between HMC steps.
A question I’m wondering regarding the implementation:
The “hmc” code I was sent only allows for MD moves to be accepted/rejected per the MC rules. However, I think it’d be best to allow the user the flexibility to add on other MC moves to that list, e.g., to be able to do translate, rotate, insert/delete, and MD moves, or a subset of their choice. The former moves are already implemented in “fix gcmc” and I think it wouldn’t be clean if MC moves are implemented twice in two different fixes.
So should HMC be implemented as an extension to the existing “fix gcmc”? In my opinion, “fix gcmc” is somewhat of a misnomer, since that fix can also be used to do just translation/rotation MC as well. So to me, “fix gcmc” is just an umbrella fix for any types of MC moves. If we define it that way, it makes sense for that umbrella to also allow MD as an additional type of MC move.
That said, I’d also understand if the “fix gcmc” implementer wanted me to keep my hands off.
Thoughts?
Hi Efrem and Steve
In 2014 we implemented HMC in Lammps, whose latest version is available at https://github.com/atoms-ufrj/fix_hmc. It used to works with both rigid bodies and for flexible molecules. The reason for including both types of moves stems from the fact that HMC is highly inefficient for flexible molecules: "stiff" intramolecular interactions restrict the time step severely in order to achieve satisfactory acceptance rates. Sampling flexible molecules would involve two types of HMC moves: (1) rigid body moves (translation and rotation) with a bigger time step size (2) turn on the intramolecular interactions and employ a smaller time step size.
That fix_hmc won't work with latests versions of Lammps given that the images of atoms belonging to rigid bodies were treated differently. The required modifications to make fix_hmc compatible with newer version, however, are not difficult to make. Also, I haven't followed all the changes in Lammps since then, so I'm not sure whether other issues will appear or not.
We are also interested in releasing HMC in Lammps, so maybe we could do some complementary work on that.
Thanks,
Ana
I’m rethinking my earlier proposal to incorporate HMC moves into the existing ‘fix gcmc’. In fact, if there’s a separate fix for it, such as Steve’s and Ana’s mentioned ‘fix hmc’, then the user can choose to have both translate, rotate, and insert/delete moves by using ‘fix gcmc’, and also to have MD moves by using ‘fix hmc’. Having such a separate fix might be the best bet, especially because future updates might want to change ‘fix hmc’ to incorporate some more advanced HMC features, so it could get quite complicated, and then it’s probably best not to mix it up with ‘fix gcmc’ for development purposes. The version of ‘fix hmc’ that Steve sent me would need to be adapted to get it to play nice with ‘fix gcmc’ in such a manner, since in that version it wasn’t implemented as a ‘fix’.
Ana, nice to hear that you’re interested in doing some work on this. Perhaps we could work together on developing/adapting your code!
LAMMPS core devs: let us know what you think about these proposals.
The fix gcmc implementation is already too complicated, so I strongly support not attempting to add HMC to it, but rather treating it as a separate fix. If the two fixes can be used at the same time, that would be nice.
Aidan
Sounds reasonable to me. I’ll talk offline with Ana about getting her code ready for release.