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.
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.
> > >> 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.
Cheers,
Edward
Re: how to parallelise model_free minimise