Edward d'Auvergne wrote:
On 3/27/07, gary thompson <garyt@xxxxxxxxxxxxxxx> wrote:
On 3/26/07, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:
> On 3/27/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
> > Edward d'Auvergne wrote:
> > > On 3/24/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
>
> > >> 2. what is going to change between runs or even over runs of
the relax
> > >> program.
> > >
> > > For each iteration of the main loop, these arguments and
parameters
> > > will change.
> > >
> > Not necessarily? certainly things such as remap_table, ri_labels,
etc do
> > not seem to change between passes through the loop
>
> These actually change if you have a data set missing for a single spin
> system because of peak overlap, etc. Most of the time you don't see
> this though.
>
>
Ah now I see! Well the answer here is to preprocess the data in the
master process
minimise loop and look for shared instances and only send
the shared instances over the wire along with some tokens defining
what to replace with what.
Sort of. I'd prefer to keep out of the language of 'shared instances'
and 'tokens', mainly because I cannot relate these terms to what is
actually happening. Each spin system has a container with data
specific to it. In the old code you are working with the residue
containers. In the new code it will be spin containers located in the
nested mol-res-spin data structure.
For the 'mf' and 'local_tm' parameter sets, the data sent for each
calculation is mainly the relevant variables and arrays in the spin
container. For the 'all' and 'diff' parameter sets, the data for each
spin system needs to be merged into a number of large data sets (by
looping over the new spin_loop() function). The initialisation of the
Mf class of the 'maths_fns.mf' module then sorts all of this data out.
No I am afraid my explanation wasn't clear enough! This is a purely
local thing for reducing the amount of data that goes over the wire (and
it may be an optimisation that doesn't work, premature optimisation is
the root of all evil etc... after all) So all i would do is at one end
of the data transfer note what is common between the objects being sent
and relpace it by a shared instance before i pickle the data to send to
another processor.Then at the other end i would unshare it (if
necessary and in a lot of cases I guess it would be uneccessary) before
calculation commenced....
Then we put it all back together at the end
(i.e. we unshare things by replacing tokens with unique instances
(this is a form of the flyweight pattern in one way but not another)
Not quite. At the end you get a parameter vector and minimisation
stats. This needs to be unpacked and placed into the relax data
storage object in the correct location.
sorry I wasn't quite clear enough again. At the other end isn't at the
end of the computation, it is on the slave processor (i.e. at the other
end of the interprocess communication)
> > >> As an aside when the redesign of the spin_loops and minimise
/model
> > >> loops cuts in it would be a good idea 9from the paralle point
of view)
> > >> to have the spin loop running faster than the minimse/model loop
> > >
> > Sorry I wasn't quite clear here, its not comuptational speed I am
> > talking about but the speed of the 'loop counter'
>
> Sorry, I don't quite understand what the speed of a 'loop counter' is.
>
>
loop counter: a number that increases linearly each time you make a
new pass through the loop
That's what I though. Wouldn't the computational speed of the
execution of one iteration of the main loop affect this ;) I'll get
to the rest of your message in a second post.
no it is a virtual loop counter used in dicussing which you loop through
faster morels or spins/minimisation instances....
Cheers,
Edward
.
regards
gary
--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx Fax +44-113-2331407
-------------------------------------------------------------------
Re: how to parallelise model_free minimise