Re: amber-developers: some ideas about multisander

From: darden <>
Date: Tue, 17 May 2005 15:29:17 -0700

all this talk about how far sander has progressed gets me thinking about
the beginnings of it 1977 when prep and link were first
written. Don't you think we could plan for a 30th anniversary of
prep/link. Don't know when edit happened. We could all take a subroutine
to give a talk about---bring back paul weiner to reminisce....and then
chandra singh could talk about why hollerith will never die
just an idea----

On Sat, 9 Apr 2005, Thomas E. Cheatham, III wrote:

>> But the big drawback to making the change is that multisander is
>> embedded firmly within mpi. In the computing environment I am in, I
>> often run many more images along a path (~30) than there are processors
>> available for the calculation. In general, this is likely to be the
>> that many users will do NEB calculations. In that case, multisander
>> would be a bad infrastructure because multiple concurrent processes
>> would be run on the same processor.
> In general, this is not a serious limitation since you can run more than
> one MPI "process" on a give node, i.e. you could run then all on one
> I used to do this often to debug the parallel code; the overhead of the
> MPI is not that significant. However, I see three limitations that do
> complicate things:
> (1) you would need to have MPI installed to use the features
> (2) if you are running (really) large replicas, running more than one at
> the same time could cause system slow downs (swapping, cache misses,
> (3) we need to remove the power of two restriction on number of
>> One way to reconcile this might be to have a multisander
>> that could adapt to run each of the images that is on the same
processor in
>> serial. Carlos, do you have any thoughts about whether this is
> However, the generalibility of this, and the ability to simplify the
> is a serious bonus.
> I have to think more about the feasibility of what you are proposing
> sequential replicas). This, in a broader context, is a significantly
> general "master-slave" idea where one could have effectively a stack or
> list of waiting tasks that are farmed out as processors are available.
> --tom
Received on Wed Apr 05 2006 - 23:49:56 PDT
Custom Search