From: Vlad Cojocaru (Vlad.Cojocaru_at_eml-r.villa-bosch.de)
Date: Fri Apr 03 2009 - 07:02:15 CDT
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
> <Vlad.Cojocaru_at_eml-r.villa-bosch.de
> <mailto:Vlad.Cojocaru_at_eml-r.villa-bosch.de>> 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-r.villa-bosch.de
> <http://eml-r.villa-bosch.de>
>
> http://projects.villa-bosch.de/mcm/people/cojocaru/
>
> ----------------------------------------------------------------------------
> EML Research gGmbH
> Amtgericht Mannheim / HRB 337446
> Managing Partner: Dr. h.c. Klaus Tschira
> Scientific and Managing Director: Prof. Dr.-Ing. Andreas Reuter
> http://www.eml-r.org
> ----------------------------------------------------------------------------
>
>
>
-- ---------------------------------------------------------------------------- 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-r.villa-bosch.de http://projects.villa-bosch.de/mcm/people/cojocaru/ ---------------------------------------------------------------------------- EML Research gGmbH Amtgericht Mannheim / HRB 337446 Managing Partner: Dr. h.c. Klaus Tschira Scientific and Managing Director: Prof. Dr.-Ing. Andreas Reuter http://www.eml-r.org ----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:52:33 CST