Re: Using NAMD for Metropolis Monte Carlo conformational searches

From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Tue Nov 09 2010 - 10:06:58 CST

On Tue, Nov 9, 2010 at 10:12 AM, Ajasja Ljubetič
<ajasja.ljubetic_at_gmail.com> wrote:
> Dear NAMD users,

dear ajasja,

this kind of thing could in principle be done,
but i suspect you would need to change the
source code.

i have implemented something very similar for
the lammps MD code where the taks was to
generate coordinates for conformational searches
in VMD and then have the MD code do a short
minimization and send back the potential energy.

recently we have been discussing to speed up
the process by converting lammps into a tcl plugin
to be run from inside VMD.

steve plimpton, the main lammps author has _very_
recently done the equivalent for python. the challenge
in many of these cases is to figure out how to launch
such a construct as a parallel job (from reading the
docs, it seems to be working with pypar).

there are two kinds of overhead that you have to consider,
and parsing the input files is only one of them. you may also
have to initiate reneighboring and a new domain decomposition,
at the latter point NAMD would give up, as this is usually a
very rare condition and often an indication of something
going wrong. the problem with lammps is, that it usually is
not quite as efficient as NAMD (NAMD can be 2x faster).
but if the startup time is a major contribution of the overall
time, then it may become competitive.

another approach would be to look at one of the MD
packages that are designed from ground up to allow users
build custom MD/MC packages from a script level, like MMTK.
http://dirac.cnrs-orleans.fr/MMTK/

i hope others may have additional comments or other
experiences and suggestions.

cheers,
    axel.

> would it be possible to use NAMD in Metropolis Monte Carlo conformational
> searches?
>  (By MMC I mean, that the probability of transition to the next
> configuration is weighted by the energy difference between the
> configurations).
> The simplest solution would be to generate a new conformation and run namd
> for this one file and then parse the log file. But I think this would
> introduce significant overhead (since NAMD would have to parse the psf and
> pdb for each frame etc.)
> Currently I'm using
> coorfile open dcd $dcdin
> while { ![coorfile read] } {
>   run 0
> }
> coorfile close
> to do random conformational searches. This works nicely, since I can
> pre-generate all conformations.
> I'm thinking of using a socket for communicating with NAMD. Then I could
> signal NAMD that a new conformation is available using a socket and do
>  coorfile open dcd frame_xxx.dcd
> coorfile read
> run 0
> coorfile close
> Or, better yet, if the file is not locket by coorfile open, I could even
> append to the same file (thereby avoiding coorfile open and coorfile close
> for every frame).
> I have to main questions:
> 1) Is it possible to send the total energy calculated by run 0 to the socket
> channel instead of only outputing it to the log (and forcing me to parse
> this output for every frame).
> 2) Is there a better way to do this kind of conformational searches?:)
>
>
> Thank you,
> Ajasja Ljubetič,
> young researcher,
> Condensed matter department,
> Institute Jozef Stefan,
> Ljubljana, Slovenia
>

-- 
Dr. Axel Kohlmeyer
akohlmey_at_gmail.com  http://goo.gl/1wk0
Institute for Computational Molecular Science
Temple University, Philadelphia PA, USA.

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:54:44 CST