From: harish vashisth (
Date: Fri Apr 03 2009 - 07:22:51 CDT

Hi Vlad,
  Thanks for putting effort in writing in writing this. Definitely, you have
invested time in fine-tuning our script and building a more flexible module.
I am sure it will be better in some sense as RAMD is originally idea from
your group and not from us. We have been able to demonstrate another good
use for it in our system. make RAMD implemented in NAMD. It will be good for
some people.


On Fri, Apr 3, 2009 at 8:02 AM, Vlad Cojocaru <> wrote:

> Hi Harish,
> Well, thanks for your coming in here ... I will shortly answer your points.
> First, I'd like to ignore your first phrase which sounds a bit ironic. I
> hope I am wrong here and you did not mean it in this way.
> a). Its exactly that what I meant, you cannot change parameters unless you
> modify the script itself. As for typing the whole script in the
> configuration file, its a matter of taste here, I personally like clean,
> short, and re-usable configuration files . I did not say that people do not
> have to learn tcl scripting. Of course they do ... But I think its nice to
> have all parameters defined in the NAMD configuration file much the way the
> ABF module works.
> b). Our RAMD implementation in AMBER 8 does both pure RAMD and combined
> RAMD-MD simulations. Combined RAMD-MD simulations mean that when your ligand
> moved more than the threshold distance, you switch to pure MD simulations
> and let the ligand relax in its new position. After MD you have the choice
> to switch back to RAMD or continue with MD in function of how much the
> ligand moved. This flavor of the method is not covered in your script and
> our AMBER 8 implementation it was not tested very much (no publication on
> this yet). But still, we believe that some of the problems of pure RAMD can
> be solved by this approach. This is what I meant by combined RAMD-MD
> simulations.
> c). I agree here with you. Anybody can simply add an srand statement in
> your script. I just pointed out that is not there in your original script.
> And if somebody cannot reproduce results with the script, should be aware of
> why they cannot. And I don't think that one should expect that everybody who
> tries to apply these methods knows tcl a-priori. 5 years ago, I had no idea
> about programming, so I had no clue about srand() or rand() functions in
> tcl. I learned it in the meantime, but many people at the beginning of their
> studies might not know programming.
> My goal was and it is to have at a point in time RAMD distributed with NAMD
> and it can be your implementation, my implementation or somebody else's. Its
> not important which implementation as long as it is robust and can be easily
> used by other people. I simply believe that in its current form, your
> script is not suitable for that. If you want to proceed and write it in a
> form to distribute it, I have nothing against it. At the end, the NAMD
> developers will decide first whether they think RAMD is worthed to be
> distributed and second which implementation is more suitable for
> distribution.
> The only thing I wanted to achieve with my initial email was to point out
> that there are 2 options to run RAMD in NAMD: (i) your script and (ii) my
> module . I do not claim that one is better or worse. I just say, there two
> options and I pointed out the limitations I found by testing your script.
> People should feel free to test one, the other, or both. User feed-back will
> tell which is better.
> And let's not further bore people with this discussion. Lets stay off list
> from now on. I would be very happy to discuss with you about RAMD and
> different implementations via email, phone or any other means if you wish
> so.
> Cheers
> vlad
> harish vashisth wrote:
> 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,
> -harish
> 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
>> NAMD.
>> 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
>> ----------------------------------------------------------------------------
> --
> ----------------------------------------------------------------------------
> 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