> 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:59 PDT
