On 5/17/07, Gary S. Thompson <[EMAIL PROTECTED]> wrote: > Edward d'Auvergne wrote: > > >On Fri, 2007-05-04 at 13:59 +0100, Gary S. Thompson wrote: > > > > > >>[EMAIL PROTECTED] wrote:
[snip] > >>Architecture > >>-------------- > >> > >>The processor extensions act as a wrapper around the core of relax and > >>with relativley minimal changes (see for example > >>multi.commands.MF_minimise_command and > >>specific_fns.model_free.minimse()) which allows relax to distribute > >>distribute computational tasks in a mater slave manner on a number of > >>different processor 'fabrics'. The a fabric is thus defines a > >>mechanism of distributing computational tasks. The three fabrics > >>currently supported are > >> > >> > > > >When the multi-processor code is ported back to the 1.3 branch, once > >that branch is closer to completion, the multi.commands.MF_* classes > >should be moved into specific_fns.model_free.multi.MF_* where the file > >is called 'specific_fns/model_free/multi.py'. I'm in the process of > >splitting up the model_free.py file into multiple, more manageable > >files. The code of the MF_* classes is specific to model-free analysis > >and should really be placed in the 'specific_fns/model_free' directory. > >This code is also all minimisation code so maybe it could go into the > >future 'specific_fns/model_free/minimise.py' file. > > > > > > > one other thought is to try and move it down a level into the generic > miniser level.... I don't think this is necessary. Actually doing this would probably be extremely painful and I doubt could be made generic enough for any type of analysis using the 'grid_search' or 'minimise' generic functions. Bye, Edward _______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
