On Sat, Apr 09, 2005, Thomas E. Cheatham, III wrote:
>
> (1) you would need to have MPI installed to use the features
This is a definite downside. But if mutlisander becomes really useful, we
may
decide it makes sense to require this for certain types of calculations.
>
> (2) if you are running (really) large replicas, running more than one
at
> the same time could cause system slow downs (swapping, cache
misses, ...)
I think this cuts the other way: in the Dave Mathew's implementation, each
node has to read a prmtop file that has parameters for all the replicas,
even
if it is really only going to work on a few of them. So you could have
swapping be worse with the current code, at least in principle.
>
> (3) we need to remove the power of two restriction on number of
processors
This should not be there with multisander. The only restriction is that
the number of nodes assigned to each replica be a power of two. This
is easy to defeat (just define noBTREE during compilation), and might not
be much of a performance penalty for NEB.
The big disadvantage of my proposal [to implement NEB using multisander]
is
that we would have to muck with code that currently works, for benefits
that
are a little hard to quantify. I propose the following: Tom and I will
put
together a path-integral MD code that uses multisander. The "springs"
that
connect replicas in path-integral MD are really quite similar to those
that
connect replicas in NEB. That experience can be used later (say late
summer)
to decide whether or not doing the same thing for NEB makes good sense.
Furthermore, what we learn with PIMD will presumably help in converting
NEB,
if we decide that is a good thing to do.
[Note: PIMD has to be done for periodic systems, so we can't use the
current
NEB model as a guide. Hence, the multisander approach seems very
appropriate.
NEB, on the other hand, is probably going to be mostly used in a GB
context.]
[Second note: the multisander approach could also simplify free energy
simulations: instead of having to create a "perturbed" prmtop file, one
would
just create two "ordinary" prmtop files, for the lambda = 0 and lambda = 1
states. One would have to be sure that the order of atoms was consistent
in
the two prmtops, but it would be more straightforward to assign charges,
parameters, and so on. Again, this involves breaking code that is working
now, so I won't undertake it lightly.]
I will just close by saying that I was impressed by how easy it was to add
an empirical valence bond capability to sander using the multisander
tools.
I want to explore the potential benefits of applying these ideas in a
consistent way to replica exchange, NEB, PIMD and free energy as well.
....dac
I am also putting this, plus Tom and Dave's comments, on the Amber-wiki:
http://amber.scripps.edu/cgi-bin/wiki.pl/Latest_Development_News
Received on Wed Apr 05 2006 - 23:49:58 PDT
