From: Joshua Adelman (jla65_at_pitt.edu)
Date: Mon Oct 18 2010 - 20:42:42 CDT
Hi Cole,
As Axel suggested, there are other MD packages that handle this type of functionally without modification. An alternative to tabulating the functions is a direct mathematical expression parser like the one that is found in OpenMM (https://simtk.org/home/openmm), which is called Lepton (https://simtk.org/home/lepton).
Depending on what types of simulations you are planning on running, you might want to give OpenMM a try (or at least a look) since it allows you to write custom force-field terms and has a nice python wrapper. It's not a full-fledged MD code, in that you basically have to assemble the parts from scratch, and the CPU mode is largely unoptimized, but if you have access to any decent GPUs, it can be quite fast even with the custom force calls. I've been using it mostly to run some coarse-grained simulations, but you can run fully atomistic biological systems as well. It may not be the right tool for this job for any number of reasons, but I just wanted to throw out another option.
Back in NAMD 2.6, I hacked in some custom force calls, based on the GlobalMaster routines, but that only ran on the head process and you had to recompile each time you made changes to the underlying functional form.
Best of luck,
Josh
On Oct 18, 2010, at 6:39 PM, Axel Kohlmeyer wrote:
> On Mon, Oct 18, 2010 at 5:53 PM, Cole Gleason <cole_at_colegleason.com> wrote:
>> Hello all,
>
> hello cole,
>
>> I am a high school senior working with a few other students and my professor
>> on some Molecular Dynamics research. I'm handling the admin side of things
>> by building and keeping our small cluster running. What my professor wants
>> to do is be able to change the functions and parameters of the pairwise
>> interactions in simulations. While I don't think that is too hard, the
>> problem is that he wants to do this without recompiling the code every time.
>> He gave me some kind of Fortran90 function parser one of his friends wrote
>> and wants me to allow the function parser to feed the equations to NAMD.
>
> that is not a bad idea in principle.
>
>> The function parser seems to take a function string and create an internal
>> representation of the function. My professor suggested we use some kind of
>> C library to call the fortran code.
>
> there are better ways to do this.
>
>> Now, I think this is the wrong approach. It seems that even if this is
>> possible, the performance hit will be significant. Someone told me that I
>
> exactly.
>
>> should instead just rewrite the parts of the NAMD source code (or CHARMM
>> perhaps?) we want to change and then somehow just recompile those sections.
>> Is that possible? How do I go about doing that?
>
> the best way to proceed would be to "tabulate" the functions.
> i.e. produce a file that has the potential function and its resulting
> force for each pair of particle types in a r, U(r), f(r) table.
> this process would not be time critical and the tables can be created
> easily even with a script language (python, perl, awk, tcl, ruby, and so on).
> those tables would then be read in and used for computing
> forces and energies during the MD simulation.
>
> i know there was a hacked(?) version of NAMD that supports this kind
> of "tabulation" floating around, but i don't know if this feature has made
> it into the 2.7 release version.
>
> but i know for sure that both the LAMMPS and the Gromacs MD codes
> support this kind of feature for a long time now. i also have been thinking
> to make that process easier by incorporating a function evaluator right
> into the MD code, like your professor suggested, but have so far always
> put this project on the back burner, since it is so easy to generate those
> tables externally and just use them.
>
>> Obviously this post is a little vague, so please tell me if you need any
>> more information. Thanks in advance to anyone who responds.
>
> what would be interesting to know, is what functions exactly your
> professor wants to look into. there are quite a few MD codes
> available that support a _lot_ of different potential types/functions.
> the parameters to those potentials can practically always be
> changed without recompilation.
>
> cheers,
> axel.
>
>
>>
>> --
>> Cole Gleason
>> ----------------------
>> Student, Marmion Academy
>> Email: cole_at_colegleason.com
>> Website: colegleason.com
>>
>
>
>
> --
> Dr. Axel Kohlmeyer akohlmey_at_gmail.com
> http://sites.google.com/site/akohlmey/
>
> Institute for Computational Molecular Science
> Temple University, Philadelphia PA, USA.
>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:56:14 CST