Whoa, that's a big supercomputer. You are most welcome to give it a
go, it should speed up your model-free runs using relax. The changes
will necessarily be extensive and will cause breakages while
development occurs, so Gary if you decide to go forwards with it, I
will probably fork relax and create an unstable development branch
called 1.3 where all new developments will go. It might even be a
good idea to create a private branch for your changes from 1.3. I
will then reserve 1.2 for bug fixes only.
I've always planned on adding support for clusters and I have a basic
framework in place which might be a good platform to start from. The
other idea I've had in the back of my mind is the conversion of the
all the model-free function code in the directory 'maths_fns' to C
(while still retaining the Python code as an option), which may give
potential gains of 10 to 20 times increased performance. This code is
by far the most CPU intensive, the minimisation code isn't anywhere
near as expensive.
The framework currently in place is the threading code. The way the
threading code works is through SSH tunnels. It starts a new instance
of relax on the remote machine (or local if there are a number of CPUs
or CPU cores), that instance gets data sent to it, does the
calculation, and returns the result. It does work, although it's not
very good at catching failures. I haven't used it lately so I don't
know if it's broken.
SSH tunnels is probably not the best option for your system. Do you
know anything about MPI? There are a number of options available for
distributed calculations, but it will need to have a clean and stable
Python interface. Which ever system is decided upon, threading inside
the program will probably be necessary so that each thread can be sent
to a different machine. This requires calculations which can be
parallelised. As minimisation is an iterative process with each
iteration requiring the results of the previous, and as it's not the
most CPU intensive part anyway, I can't see too many gains in
modifying that code. I've already parallelised the Monte Carlo
simulations for the threading code as those calculations are the most
obvious target. But all residue specific calculations could be
parellelised as well. This is probably where you can get the best
speed ups. I have a few more comments below.
On 4/13/06, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
Dear Ed
I was we have a 148 processor beowolf cluster ;-) I was thinking of
having a go at developing a distributed version of relax... are you ok
with that or do you have plans of your own?
The general idea was to have scripts look almost as they are but
1. have a command to register multi processor handlers
The user function class 'threading' is probably close to what you want.
2. have a command to add machines and parameters to the multi processor pool
threading.add() is probably a good template.
3. add code to the generic functions/or replace the generic funcntions
if the multiprocessing is setup to batch up components of calculations
and pass them out to the compute servers
'generic/minimise.py' is the best bet. Otherwise there is
'maths_fns/mf.py' which can be hacked.
4. add code to multiplex the results back together again
That should be pretty straight forward.
obviously this would just be a prototype at first but it could be rather
useful
regards
gary
Bye,
Edward
Re: multi processing