LAMMPS WWW Site - LAMMPS Documentation - LAMMPS Mailing List Archives
Re: [lammps-users] [EXTERNAL] Re: feature request: hybrid monte carlo
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lammps-users] [EXTERNAL] Re: feature request: hybrid monte carlo


From: Efrem Braun <efrem.braun@...297...>
Date: Mon, 10 Jul 2017 22:20:56 +0200

Sounds reasonable to me. I'll talk offline with Ana about getting her code ready for release.

Efrem Braun

On Mon, Jul 10, 2017 at 7:15 PM, Thompson, Aidan <athomps@...3...> wrote:

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

 

 

--

      Aidan P. Thompson

      01444 Multiscale Science

      Sandia National Laboratories

      PO Box 5800, MS 1322      Phone: 505-844-9702

      Albuquerque, NM 87185     Fax  : 505-845-7442

 

 

From: Efrem Braun <efrem.braun@...43...97...>
Date: Saturday, July 8, 2017 at 6:46 PM
To: "asilveira@...5315..." <asilveira@...5315...>
Cc: Aidan Thompson <aidan.thompson@...24...>, Steve Plimpton <sjplimp@...24...>, lammps/lammps LAMMPS Users List <lammps-users@...396...sourceforge.net>
Subject: [EXTERNAL] Re: [lammps-users] feature request: hybrid monte carlo

 

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.

 

Efrem Braun

 

On Fri, Jul 7, 2017 at 10:09 PM, Ana Silveira <asilveira@...5315...> wrote:

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




On 07-07-2017 14:53, Efrem Braun wrote:

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?

Efrem Braun

On Fri, Jul 7, 2017 at 4:42 PM, Steve Plimpton <sjplimp@...24...>
wrote:

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

On Fri, Jul 7, 2017 at 5:57 AM, Efrem Braun
<efrem.braun@...297...> wrote:

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.

Efrem Braun

 

------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, Slashdot.org! http://sdm.link/slashdot [1]
_______________________________________________
lammps-users mailing list
lammps-users@...396...sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lammps-users [2]




Links:
------
[1] http://sdm.link/slashdot
[2] https://lists.sourceforge.net/lists/listinfo/lammps-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
lammps-users mailing list
lammps-users@...396...sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lammps-users