tom
all this talk about how far sander has progressed gets me thinking about
the beginnings of it all.......paris 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----
td
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
way
>> 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
node.
> 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
processors
>
>> One way to reconcile this might be to have a multisander
implementation
>> 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
feasible?
>
> However, the generalibility of this, and the ability to simplify the
code
> is a serious bonus.
>
> I have to think more about the feasibility of what you are proposing
(i.e.
> sequential replicas). This, in a broader context, is a significantly
more
> 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
