Edward d'Auvergne wrote:
On 3/29/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
garyt@xxxxxxxxxxxxxxx wrote:
> Author: varioustoxins
> Date: Thu Mar 29 11:45:22 2007
> New Revision: 3243
>
> URL: http://svn.gna.org/viewcvs/relax?rev=3243&view=rev
> Log:
> First fully working multi branch with both uniprocessor and mpi4py
support
> communication overhead for 18 residues (test_short.py from chris) with
> in memory io ~25%
>
Modified:
branches/multi_processor/multi/mpi4py_processor.py
branches/multi_processor/multi/uni_processor.py
branches/multi_processor/prompt/interpreter.py
branches/multi_processor/relax
branches/multi_processor/specific_fns/model_free.py
as alluded to in the commit message with a fairly simple implimentation
(each minimisation instance is sent off separately) I see an overhead of
~25% with with a small data set of 18 residues. I don't think this will
improve with the current implimentation as there are too many messages,
however, I do intend to increase the chunk size of the communication
(multiple minimises per message) as one of the next steps and see what
the results are.
That should decrease the communication overhead. How did you
determine the percentage overhead value?
The run was made under mpi and with the uniprocessor version on a
single processor, so these are very crude overheads . Compaisons were
made by comparing mpi runtime and non mpi runtime by wall
And which model-free model
was/were optimised?
worst case scenario!
test_small.py:
-----------------------------8<----------------------------------------------:
# Script for model-free analysis.
dataPaths = ['test_data/noe750.dat',
'test_data/T1_750_hgts.bs',
'test_data/T2_750_hgts.bs']
dataTypes = [('NOE', '750', 750.8e6),
('R1', '750', 750.8e6),
('R2', '750', 750.8e6)]
# Set the run names (also the names of preset model-free models).
#runs = ['tm1', 'tm2', 'tm3', 'tm4', 'tm5', 'tm6', 'tm7', 'tm8', 'tm9']
runs = ['m1', 'm2', 'm3', 'm4', 'm5', 'm6', 'm7', 'm8', 'm9']
# Nuclei type
nuclei('N')
# Loop over the runs.
for name in runs:
# Create the run.
run.create(name, 'mf')
# Load the sequence.
#sequence.read(name, 'noe.500.out')
# Load a PDB file.
structure.read_pdb(name, 'test_data/test.pdb')
#pdb.read(name, 'test_data/test.pdb')
structure.vectors(name, proton='HN')
# Load the relaxation data.
for dataSet in xrange(len(dataPaths)):
relax_data.read(name, dataTypes[dataSet][0],
dataTypes[dataSet][1], dataTypes[dataSet][2], dataPaths[dataSet])
# Setup other values.
diffusion_tensor.init(name, 1e-8, fixed=1)
#diffusion_tensor.init(name, (1e-8, 1.0, 60, 290), param_types=0,
spheroid_type='oblate', fixed=0)
value.set(name, 1.02 * 1e-10, 'bond_length')
value.set(name, -160 * 1e-6, 'csa')
#value.set(name, 0.970, 's2')
#value.set(name, 1.0, 's2f')
#value.set(name, 2048e-12, 'te')
#value.set(name, 2048e-12, 'tf')
#value.set(name, 2048e-12, 'ts')
#value.set(name, 0.149/(2*pi*600e6)**2, 'rex')
# Select the model-free model.
model_free.select_model(run=name, model=name)
#fix(name, 'all_res')
# Minimise.
grid_search(name, inc=11)
minimise('newton', run=name)
# Write the results.
results.write(run=name, file='results', force=1)
# Save the program state.
state.save('save', force=1)
-----------------------------8<----------------------------------------------:
One other comment is that I have had to alter prompt/interpreter.py
because it was exiting too early
# Quit.
- if quit:
- sys.exit()
+ # FIXME: need to drop off end of interpreter loop to exit cleanly
+ #if quit:
+ # sys.exit()
I can't see a problem with it returning rather than quitting but
obviously am ope to counter claims
I really cannot for the life of me remember why I put that exit
statement there (that was so long ago). Oh well, debugging should
pick up any problems.
I haven't seen any as yet but the test suite will help
On the topic of debugging, if you would like to
port the unit test code from the 1.3 line into your branch so you can
write unit tests for the code, the svnmerge program/script distributed
with Subversion will help a lot.
yes thats on the list as well though some of the multiprocessor code
will be hard to unit test
Overall I am very happy with the current results and feel that the
level of change to the main relax code base is very small and that
the code is relativley portable and well defined
That did touch very little of the model-free specific code base.
;-)
One
question I have is will there be a separate model-free minimise()
function for normal and MPI operation?
no the non mpi version just calls the uniprocessor processor
multi.uni_processor. The current uniprocessor implimentation is non
optimal by space on single processor machines but will have the same
overhead by time as any other implimentations (barring the use of
command cacheing which may save to object creation overhead)
Another point is that I can't
run the code in the branch without having MPI up and running.
you should be able to run relax without a --multi command line and
without an mpirun and the uniprocessor implimentations should run.
However, currently when I run it I get The dependency 'mpi4py' has not
been installed is that the problem you have?? I will investigate the problem
obviously there is consdiderable code cleanup and documentation still
to be done and also implimentation of processors for threading and
ssh tunnels
The code is shaping up nicely. With a good clean up it should be
relatively easy to port to the 1.3 line later on.
yep time to go from alpha to beta, glad you like it
1It looks like a
great framework for the threading and grid computing via ssh tunnels.
indeed thats the intention and design goal ;-)
Cheers,
Edward
regards
gary
_______________________________________________
relax (http://nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
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
.
--
-------------------------------------------------------------------
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: r3243 - in /branches/multi_processor: ./ multi/ prompt/ specific_fns/