From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Mon Oct 18 2010 - 22:12:10 CDT
On Mon, Oct 18, 2010 at 10:24 PM, Cole Gleason <cole_at_colegleason.com> wrote:
> On Mon, Oct 18, 2010 at 8:20 PM, Nicholas Musolino <musolino_at_mit.edu> wrote:
>>
>> Alex K. has provided some super-helpful information, as always, about using tabulated potential functions.
>> I just wanted to check in and ask, are you sure that you (and your professor) are on the same page about what it takes to recompile NAMD? It's possible he's used to bigger (more complicated) software projects that spend a very long while for compile time.
the compile time really isn't so much of an issue. the abysmal performance
of interfacing a hand written fortran90 parser into c++ code would be
a major PITA.
why not write a little fortran wrapper around it to first generate the tables
and then run the MD code using them. that is how i would introduce
a generic parser into an MD code.
> I think this might be the case. I wasn't sure that I would even have
> to recompile all of it. Hopefully asking him to go this route won't
> break his heart, as he seems kind of attached to this function parser
> for some reason.
no surprise there. fortran is about the worst programming language to
write a generic parser in. there are much better ones, and any decent
script language interpreter would be a better choice. so if somebody
spent much effort on writing something under the worst circumstances,
it is to be expected that this person is attached to that code. it is
still very likely to be a needless complication.
[...]
> This also seems like an interesting route, as I want other members of
> the team to be able to edit functions, but I don't need them to be
> recompiling code. Do you know if there are any good tutorials
> regarding this?
not really. traditionally, these kind of experiments are done by
people that do know programming well and write or adapt their
own MD codes. using a code like NAMD really only makes
sense for these kinds of experiments, if you need to run long
production MD calculations for larger system as fast as possible.
and for _that_ performance would matter a lot and that means,
that tabulation is the only reasonable choice. for any complicated
functional form, the tabulation with spline interpolation is very
likely faster than writing it as actual c/c++ code. that is the
experience in LAMMPS. in gromacs, this is not quite the same,
since gromacs has fast, yet somewhat approximate non-bonded
kernels programmed in vectorized assembly for common functional
forms.
if performance would not matter, it would probably as easy
(and fast) to write a whole MD code in a script language.
writing a minimal toy MD code is a nice exercise to learn MD.
i've done this to demonstrate some simple standard optimization
and parallelization techniques for and HPC school for physicists:
http://sites.google.com/site/akohlmey/software/ljmd
cheers,
axel.
> Thanks!
> --
> 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:54:38 CST