[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
course.

~~~~~~~~~~~~
Michael Shirts
Assistant Professor
Department of Chemical Engineering
University of Virginia
michael.shirts at virginia.edu
(434)-243-1821


> 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