On 3/21/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
Edward d'Auvergne wrote:
>> >> >> my main thought was to
>> >> >>effectivley add restrictions to a some commands. So consider grid
>> >> search
>> >> >>I would add an extra parameter at the generic and functional
>> levels
>> >> >>which would give a range of steps within the current parameters to
>> >> >>calculate.... e.g here are the ranges which give a grid of
>> 10x10x10 ie
>> >> >>1000 steps. slave 1. you calculate 1-250 slave 2. 251-500 and so
>> >> on.....
>> >> >>is this the correct way to go?
>> >> >>
>> >> >>
>> >> >
>> >> >Subdividing the grid search will be an interesting problem!
>> Should it
>> >> >be at the 'generic_fns' level, the 'specific_fns' level, or
>> implemented
>> >> >directly into the minimisation package? I think that the
>> >> 'specific_fns'
>> >> >level, again within the 'minimise()' model-free method (copied,
>> >> modified
>> >> >for MPI, and renamed to 'minimise_mpi()') would be the best place to
>> >> >target.
>> >> >
>> >> >An algorithm to subdivide the grid would be useful. Then an
>> algorithm
>> >> >to collect the results and determine which subspace of the grid
>> has the
>> >> >point with the lowest chi2 value should be used. I.e. this will
>> be an
>> >> >MPI-oriented grid search over a number of standard grid searches.
>> >> >
>> >> >However your best MPI gains are likely to be achieved by sending
>> each
>> >> >grid search to a different node. This higher level would be shared
>> >> with
>> >> >the standard model-free optimisation code and hence you don't
>> need to
>> >> >worry about writing separate MPI code for the grid search and for
>> the
>> >> >minimisation. Slight improvements may be achieved by breaking up
>> the
>> >> >grid search, but I would personally tackle this later on.
>> >> >
>> >> >
>> >> >
>> >>
>> >> again I need to think about this. However if this uses divisons by
>> model
>> >> again it will perform poorly as the different models will take
>> different
>> >> amounts of time to calculate so many processors will sit idle...
>> >> again if I am not undertsanding properly please accept my apologies
>> >> relax is very heavily layered and alot of names are repeated multiple
>> >> times it can be quite had to follow whatis going on in the code
>> base ;-)
>> >
>> >
>> > Idle time will be inevitable. Especially when it comes to the 'all'
>> > model-free minimisation instance (the optimisation of all model-free
>> > model parameters for all residues together with all diffusion
>> > parameters). That cannot be avoided.
>> >
>> I agree especially if you are going for the low hanging fruit. In the
>> case of the all minimisation it might be possible to parallelise it
>> but the code would have to work at a much lower level and many messages
>> would have to be passed. Whether it would work or not would depend on
>> how frequently nodes had to update data between themselves. Certainly
>> it would only work well on a homogenous system or a fairly well balanced
>> hetrogenous system (i.e. you would have to know the relative speed of
>> each slave and weight the amount of work it did correctly)
>
>
> By definition, minimisation algorithms are a serial process. They
> walk downhill through the space using information from the previous
> and current positions. I can't see how the 'all' model-free
> minimisation instance can ever be parallelised - it will take a while
> no matter what. Unless a proven parallelised optimisation algorithm
> is coded from scratch. And even then extensive testing would be
> required to validate the algorithm within the model-free space. Where
> we will get improvements with the 'all' parameter set is in the
> parallelisation of the Monte Carlo simulations!
oh definitley and also grid searches for anisotropic systems can be
quite slow
The grid search for the 'diff' model - the diffusion tensor with the
model-free parameters fixed - can take a while. That step would
benefit from the grid within a grid parallelisation approach.
> The parallelisation
> of the processing of data pipes (the old 'runs') would most likely
> give the least improvements.
>
indeed ;-) It would be the last thing to do....
Actually, this parallelisation would actually be quite beneficial when
optimising the 'diff' model (especially if you are running the
different diffusion model analyses simultaneously). For your work
with optimising MPI, it might be worth profiling the execution of the
'full_analysis.py' script for the full model-free analysis. Not real
profiling but roughly measuring the time it takes to complete various
stages of the analysis. A graph or plot of the results, with and
without MPI, could be useful for determining which points are
bottlenecks and which steps can be improved by additional
parallelisation. What do you think?
Bye,
Edward
Re: relax, MPI, and Grid computing.