[gmx-developers] Hybrid MC, accept/reject state

Shirts, Michael (mrs5pt) mrs5pt at eservices.virginia.edu
Wed Feb 13 17:38:52 CET 2013

Hi, Christian-

Hybrid MC (plus potentially other MC methods) is on the agenda for 5.0, with
a draft version most likely sometime this summer. There are a lot of ways
that the current md.c makes it hard to do things like this, because of the
complicated bookkeeping -- it should be much easier after that point. I
myself would have to sit down for a few hours to figure out exactly how one
would need to do this with current bookkeeping.

I would say that generally, hybrid MC is not that much more efficient than
just using MD, at least for most implementations, so I don't know that the
coding work will be worth the input time.   Unless you have some
particularly clever additional trick your are adding to the process, of

Michael Shirts
Assistant Professor
Department of Chemical Engineering
University of Virginia
michael.shirts at virginia.edu

> From: "Christian H." <hypolit at googlemail.com>
> Reply-To: Discussion list for GROMACS development <gmx-developers at gromacs.org>
> Date: Wed, 13 Feb 2013 17:01:51 +0100
> To: <gmx-developers at gromacs.org>
> Subject: [gmx-developers] Hybrid MC, accept/reject state
> Hi,
> I am trying to figure out how one would go about implementing a simple
> Hybrid Monte Carlo scheme in GROMACS. For my purposes I am only interested
> in the md-vv integrator, using either a NVT or NPT ensemble. MPI is not a
> strict necessity, as the system I am going to look at are probably small.
> So far I reversed the order between the energy calculation and the
> trajectory output, by keeping a backup of my current configuration where
> appropriate. This way I can check whether to accept the current
> configuration before anything is written to the trajectory file.
> The point I am struggling with is the overall energy: It seems it is not
> sufficient to just deal with enerd->term[F_ETOT] from md.c. For example if
> I do an integration step, (thereby changing the current
> enerd->term[F_ETOT]) and then decide to reject it (setting enerd->[F_ETOT]
> = previousEnergy and copying back the previous state->x), a different value
> than previousEnergy is written to the .edr file.
> I guess the actual energy output takes place in print_ebin of
> mdlib/mdebin.c, or more precisely do_enx of gmxlib/enxio.c. I can't really
> make out of this works though. Is there any detailed information about the
> file format available somewhere? It seems like either enerd->term[F_ETOT]
> from md.c is not directly used and/or the total energy is recalculated
> somewhere along the way.
> If anybody sees a glaring error in my approach in general, please point it
> out as well - I am really new to the GROMACS source and have only a rough
> understanding of how it works overall.
> Thanks,
> Christian
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.

More information about the gromacs.org_gmx-developers mailing list