[gmx-developers] Feasibility of implementing new integration schemes in Gromacs
David van der Spoel
spoel at xray.bmc.uu.se
Tue Jun 26 08:57:43 CEST 2007
Nick Schafer wrote:
> Dear Gromacs-Developers –
> First of all, I should point out that I am completely new to this list
> and also quite new to MD in general. My name is Nick Schafer and I am
> an undergraduate student at the University of Wisconsin, Madison working
> for Professor Dan Negrut in the mechanical engineering department. I’m
> working with Professor Negrut on testing new integration algorithms for
> molecular dynamics. After some deliberation and one or two false
> starts, we have decided to attempt to modify NAMD-Lite (formerly MDX), a
> watered down, sequential version of NAMD (a code that I assume you are
> all at least familiar with by name). So far it is going fairly well.
> The documentation for NAMD-Lite is fairly good and the code is
> understandable. In the coming months, I will (hopefully) be
> implementing our integrators, designing and performing several
> experiments, and analyzing/writing up our results.
> This is where GROMACS comes in. I recently switched from Windows to
> Linux as a development platform and I was browsing the “Science” section
> of the Synaptic Package Manager and noticed GROMACS. I decided to look
> into it and I found your webpage and this e-mailing list. My basic
> question is: Would GROMACS be a good choice for testing new methods of
> integration? Would it be feasible for me to modify/recompile the code?
> One reason I am interested in GROMACS is that it doesn’t have the
> biology bias that NAMD does, but I could still use VMD to analyze the
> results of my experiments. Does anyone here know of any reason why I
> should attempt to modify one code or the other? Any help is appreciated
> and don’t be afraid to point out anything that I said that sounds crazy
> or is completely wrong. My feelings won’t be hurt.
thanks for the initiative. As you may be aware there is a large bunch of
literature out there about integration algorithms. GROMACS implements
one of the simplest, leap-frog, because it is simple and cheap - it only
requires one force evaluation per integration time step. Our philosophy
is as follows:
+ there are many factors that influence the accuracy of the results of a
simulation, one of the smaller contributors is the integration algorithm
(more important ones are various estimated interaction parameters, force
constants etc., please refer to the gromacs manual chapter 3)
+ it would be great to have an integrator that is completely
time-reversible and helps energy conservation
Hence, we welcome integration algorithms with better properties than
leap-frog, if they do not slow down the program. Having said that, it
may still make sense for special applications, and we definitely would
like to have it optional.
Since gromacs is released under the GPL, you are free to modify things
etc, and you will find that the developer mailing list is a good place
to ask for help. The integration code is quite readable. A good start
would be to check out the source code in src/mdlib/update. Recompiling
is easy, and you will find some help on the website.
Do also note that there are other algorithms that have a tight interplay
with the integration: constraint algorithms (to keep chemical bonds at a
predefined distance), temperature scaling (modifying velocities) and
pressure scaling (modifying coordinates).
Good luck, and please let us know if you have further questions.
David van der Spoel, PhD, Assoc. Prof., Molecular Biophysics group,
Dept. of Cell and Molecular Biology, Uppsala University.
Husargatan 3, Box 596, 75124 Uppsala, Sweden
phone: 46 18 471 4205 fax: 46 18 511 755
spoel at xray.bmc.uu.se spoel at gromacs.org http://folding.bmc.uu.se
More information about the gromacs.org_gmx-developers