On 3/28/07, gary thompson <garyt.and.sarahb@xxxxxxxxx> wrote:
On 3/28/07, Edward d'Auvergne <edward.dauvergne@xxxxxxxxx> wrote:
> A major problem with the looping over data pipes within the model-free
> minimise() function is that you won't have access to the 'pipes'
> argument.
Ok I am quite happy to sit back and let this hang for the moment ;-)
The whole things is literally quite trivial to implement (5 lines of
code maybe less and I don't think I can reoganise the relax ui and
data structure with that amount of code)
so I will leave it to when the redesign is finished and see where we
are and whether it will work with what we have.
However, the whole point here is that i don't need any access to the
runs argument or the pipes to make this work you need access to the
relax.processor from the user level *(and possibly not even that) and
from the model_free.minimise loop nowhere else it doesn't require
major ui or code base reorganisations
The UI design feature that the automatic looping over all model-free
models clashes with is the run concept (or data pipe in the future).
The flow of relax execution is founded upon this concept. Every last
user function is expected to operate on a single run as specified by
the user (either by a function argument in 1.2 or by the current data
pipe concept in the 1.3 line). The same goes with the grid_search()
and minimise() user functions - these deliberately operate on a single
run and the reason for this is simple. The user is free to optimise
all the model-free models (this can be models m1 to m5, models m0 to
m9, etc.). Or the user is free to choose a subset of models or can
optimise a single model. For example if you were to implement the
quadric technique in Bruschweiler et al. (1995), Science, 268,
886-889, only model tm2 is should be optimised. Therefore for
flexibility, relax should not impose a predefined set of model-free
models that will be optimised (a script operating relax is different
though).
Now, part of the new design for the 1.3 line is Chris' idea of the
'pipes' argument ('runs' argument prior to the renaming of the run) to
the majority of user functions. The code catching this argument will
loop over the data pipes one by one tricking the minimise, grid
search, and all other code into operating on a data pipe which is not
the current pipe. Therefore the argument (being a list of data pipes
corresponding to different model-free models) will not be passed into
the model-free minimise() code and the MPI code will not be able to
access it and then loop over the data pipes.
Edward
Re: how to parallelise model_free minimise