>> >> 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! The parallelisation
of the processing of data pipes (the old 'runs') would most likely
give the least improvements.
Regards,
Edward
Re: relax, MPI, and Grid computing.