On 3/21/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
Edward d'Auvergne wrote:
>> >> >> do i modify interpreter.run to take a quit varaiable set to
>> False so
>> >> >> that run_script can be
>> >> >> run with quit = false?
>> >> >
>> >> >
>> >> > Avoid the interpreter and wait at the optimisation steps - the only
>> >> > serious number crunching code in relax.
>> >>
>> >>
>> >> I agree! interpeters are not required on the slave just the relax
>> data
>> >> structures in a clean and useable state
>> >
>> >
>> > If you're working at the level of the model-free 'minimise()'
>> > function, don't bother with the relax data structures! See my
>> > previous post mentioned above.
>>
>> I follow now, my only worry is that the processing will be fairly fine
>> grained so causing a greater ratio of network traffic to processing
>
>
> The level of the minimise() method is coarser than splitting up a grid
> search. That is because the main loop of the method executes the grid
> search for each optimisation instance.
does this limit the number of processors I can use?
Yes. If you are studying n spin systems (or residues in a typical
protein analysis) you will be limited to n processors.
also i am not
following what you mean by each optimization instance is this a model
type if so that is too (!) course grained...
There are 4 different classes of model-free model supported by relax.
These are found by the 'determine_param_set_type()' method and are
handled differently by the 'minimise()' method and the 'maths_fns.mf'
module. The four types are:
'mf' - one model-free model.
'local_tm' - one model-free model together with the local tm parameter.
'diff' - solely the diffusion tensor (the model-free model
parameters are held constant).
'all' - all model-free models of all spin systems together with
the Brownian rotational diffusion parameters.
The minimise() method loops over the minimisation instances which for
the four models total n, n, 1, and 1 instances respectively.
The original aim for the
optimisation during minimisation was to split up residue ranges as this
gives coarse grains but a reasonable number of them.... (e.g. if you
have a 120 aa protein you have upto 120 grains available (though by that
stage your communication overhead may get too much)
I'll assume that 'split up residue ranges' means for n residues there
are n optimisations. This is constrained by the model. For a grid
search with 10 to 20 increments per dimension across the space of the
most complex model-free model, this could be a few minutes per
residue. For the minimisation the timing could be similar. I don't
think there will be much communication overhead in this situation. If
this is found to be too coarse, then the grid search could be
parallelised. The minimisation of one optimisation instance can never
be parallelised though (unless you get into the minimisation code and
implement a parallelised optimisation algorithm (I wouldn't do that
though))!
so actually I was
looking at the relax_fit specific function....
'relax_fit'? Do you mean the fitting of the exponential curves to
determine the R1 and R2 relaxation rates?
plus passing parameters
to restrict the residue range or using the select function pluse some
saving and restoring of state in the master.
It could be me not fully understanding MPI but isn't it the master
which collects the results and then places these into the relax data
storage object? Or do the slaves have access to the program namespace
and hence have access to the relax data storage object singleton and
can do it themselves? Why does the program state need saving?
If i have this upside down
and back to front i apolergise I am still learning ;-)
So am I, mainly though your relax subversion commit messages! My
knowledge of MPI is definitely lacking.
Bye,
Edward
Re: r3237 - in /branches/multi_processor: multi/mpi4py_processor.py relax