From: harish vashisth (
Date: Thu Apr 02 2009 - 17:13:12 CDT

Hi Vlad,

     Good to know that you invested some significant time out of your
research work to develop this RAMD module. It will be nicer for some people
who do not want to learn tcl-scripting in NAMD (ideally, they should learn
it !!!). I appreciate you acknowledging our work as well. However, there are
certain things I would like to clarify based on your writings:

a. It is not correct to say that the script can not be controlled from NAMD
config file. Simplest thing is to paste all the commands of the script in
the config file and do whatever one wants to. But I think what you mention
is about changing atom ids to which you want to apply force. All the data
for script except atom ids is read from config file. Well, if users are
smart enough they can tag beta-columns of their PDB files for RAMD force
application similar to how they learn in SMD tutorial.

b. Secondly, it is wrong to expect script to perform MD and RAMD. The script
is not supposed to do so. MD is always running under NAMD's central code
while tcl-forces utility only allows people to add external forces which is
what script does nicely on-the-fly. We have also coded this way all of our
in-house SMD protocols used in the published work instead of using default
implemented SMD.

c. Third is about the use of rand(). It is very common sense for people
doing computer simulations to know that they should provide identical seed
every time to see reproducibility which is also only possible for serial
single-processor jobs. srand() does nothing except supplying a seed and such
things as assumed if someone is working on protein simulations. It is not
too hard a task to add srand(), i suppose and we do not think it is any
limitation of script rather flexibility for users to do so. To be more
clear, one would never want to do single process RAMD jobs unless system is
too small. Our systems were between 50k to 100k atoms and we had to run upto
500 ps of RAMD many times to observe expulsion. We had to do these jobs on
parallel processors or it will take ages to collect data on 800 trajectories
given in article. It is up to users to do single processor jobs for testing
purposes and these things in no way undermine utility of original script.

Although I agree with you that users must change things to output data in
certain formats. We did not have time to add these universal* rules as some
science needs to be done before making these sophistications. Still, we
mention at places in the script what is system-specific and what needs to be
changed. I appreciate that you have invested time in fine-tuning the
original script and did build a separate module on RAMD protocol which
hopefully will be useful to people who are just reluctant to learn
scripting. Good luck with your RAMD module development work!!! We hope that
your module be included in NAMD source code and appropriate citations appear
on our work as well as to original papers on RAMD from your group.

Thanks and Regards,

On Wed, Apr 1, 2009 at 4:24 AM, Vlad Cojocaru <> wrote:

> Dear NAMD users,
> Since I got some questions about the method developed in our group (Random
> Acceleration Molecular Dynamics - RAMD) to investigate ligand exit pathways
> from buried active sites in proteins I thought of sharing with you the
> latest developments regarding the implementation of RAMD as a tcl module for
> The method was implemented in AMBER8 before I joined the group. Porting it
> to AMBER9 and later AMBER10 is rather difficult (especially since I don't
> know fortran and parallel programming).
> So, whenever I was asked about RAMD I had to tell people to compile an old
> version of AMBER if they want to use it. Then I thought it would be very
> straight-forward to implement it in NAMD as a tcl module. I started working
> with the ABF module, and I got inspired by it so I started building a
> similar module for RAMD.
> In the meantime in a recent paper (Biophys J. 2008 Nov 1;95(9):4193-204.
> Epub 2008 Aug 1) Vashisth H et al, report a tcl script for running RAMD in
> NAMD (available as supplementary material). Although the script does what
> RAMD is meant to do, the runs cannot be controlled via the NAMD
> configuration file (you always need to modify the script if you want to run
> different trajectories). This script does not perform combined RAMD-MD as
> our AMBER8 implementation does. The runs with this script are not
> reproducible even on single CPUs simply because the script uses the rand
> function in tcl without initializing it by srand. Also, the output is not
> formatted in a nice way to extract the relevant information for assessing
> the trajectory.
> A while ago I have finished a version of my RAMD module for NAMD. The runs
> are fully controlled from the NAMD configuration file. The module compares
> to the Vashisth script but its more complex and can do almost everything
> that our AMBER8 implementation can do. There is still one difference though:
> the input is a force constant while in AMBER is an acceleration. Because of
> this the results are not yet fully comparable. The module is not
> bullet-proof tested yet but if people are interested in testing and using
> it, I'd be happy to share it and if it proves useful and easy-to-use I will
> ask the NAMD developers what to do to include it in NAMD (if that's
> possible)... I also started working on a new version that should be
> identical to the AMBER8 implementation (not ready yet though).
> As I said, for building this module, I inspired myself from the structure
> of the ABF module, so I am grateful to Jerome, Chris and all others that
> contributed to the ABF module. My RAMD module was also compared against the
> Vashisth H et al. script, and I greatly acknowledge their work which gave me
> the motivation to continue working on the module.
> Feel free to contact me for the scripts in case you wish to test them. As I
> said, they still need careful testing before using them for production runs.
> For testing, I recommend careful comparison with Vanish script (if you add
> an srand statement in that script and use the same parameters - including
> random number seed - ) and run on 1 CPU you should get the same results. If
> usage feed-back is good, I will put an effort to include a standard test .
> Best wishes
> vlad
> --
> ----------------------------------------------------------------------------
> Dr. Vlad Cojocaru
> EML Research gGmbH
> Schloss-Wolfsbrunnenweg 33
> 69118 Heidelberg
> Tel: ++49-6221-533202
> Fax: ++49-6221-533298
> e-mail:Vlad.Cojocaru[at]
> ----------------------------------------------------------------------------
> EML Research gGmbH
> Amtgericht Mannheim / HRB 337446
> Managing Partner: Dr. h.c. Klaus Tschira
> Scientific and Managing Director: Prof. Dr.-Ing. Andreas Reuter
> ----------------------------------------------------------------------------

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:52:33 CST