Hi,
Please see below:
2010/1/18 Michael Bieri <michael.bieri@xxxxxx>:
Hi Edward
This all sounds reasonable.
I will add a log windows for all the functions implemented yet (NOE, R1,
R2 and Model-free).
As a new start-up panel, I would suggest to have an empty canvas, where
users are able to choose between Model-free (current version), N-state
model, Frame order theories, J(w) mapping.... using buttons. This will
then open another interface, such as the current for Model-free. What do
you think about this?
This sounds good. What do you think of large buttons with the
pictures you have already made for each analysis type?
I also don't get what you understand in custom mode? Is this something
between scripting and GUI? If so, I would suggest to create a window
that has a virtual console on the right and a tree with all the
commands. The user can choose the commands to execute and add values
that are not generated during his calculation (reading of peak and
parameter files would be in a similar way as in the automatic mode).
Custom mode would be something like that found in OpenDX. Actually
the idea follows that design quite closely. You can also think of it
as lego, but with pipes joining the blocks. The blocks correspond to
the API calls, i.e. are almost identical to the user functions. The
pipes then direct the data flow. Each user function can be selected
by the user and dropped into the main 3D canvas. These objects can be
moved through the space in a CAD-like manner. Like in OpenDX, each
object will have input and output connectors (bumps). You can then
click and drag, from the output connector, a pipe which can be
attached to any input connector. There would also be execute, cancel,
and reset buttons, and the execution through the data pipes would be
animated. Certain objects will be solely for input
(relax_data.read(), value.set(), etc.), some will solely be for output
(relax_data.write(), value.write(), state.save(), etc.), some will be
for branching pipes (relax_data.copy(), etc.), some will be for
merging pipes (model_selection()), and some will be for simply
processing the contents of the pipe (miminise(),
model_free.select_model(), etc). The ideas here are endless. This
type of flexibility would allow the user to make custom analyses. For
example they could recreate the original model-free analysis protocol
of Mandel et al., 1995, or that of Orekhov et al., 1999 studying the
bacteriorhodopsin fragment. Or someone may discover a protocol which
is even more robust than the one I came up with (d'Auvergne and
Gooley, 2008). With the custom mode (which is now available in the
prompt and script UIs), the user is totally free to use relax in any
way they see fit.
State-save:
At the moment, I am not fully aware what state.save does. But It would
be very useful to combine the relax save file with the relaxGUI save
file (kind of hybrid).
This just takes the relax data store (data.Relax_data_store), converts
it to XML, and stores it in a file. All permanent data goes into this
store. Relaxation data, parameter values, bond lengths,
molecule-residues-spin containers, optimisation statistics,
back-calculated values, structural information (i.e. the PDB file),
everything! It is just a container with many other containers inside
it. We can add one more - a container for the information required to
restore the GUI. You can have a look at the files created by
state.save() and see how they are structured. Then in the program
import the data store:
from data import Relax_data_store; ds = Relax_data_store()
The data store is a singleton
(http://en.wikipedia.org/wiki/Singleton_pattern) so 'ds' will contain
all the data. If you look at this structure, you'll see that the XML
save state and the data store have the same internal structure. Note
that the full_analysis.py script deletes information from this data
store with each iteration. The reason for this is because the
computer would otherwise run out of ram. But normally data is not
removed and the data store contains everything! Does this description
help?
Another thing would be to include a multiprocessor function. You told me
once that something like this is ongoing. Alternatively, there is the
module Parallelpython (http://www.parallelpython.com/ ) that allows
multi processor support. I am not sure if we would use threads for the
automatic model-free calculation if jobs are assigned to different
processors. But if so, this would be the best and easiest way by just
calculating local tm and then simultaneously start as many calculations
(as threads) as available processors. This would speed up the full
automatic mode!
This is not necessary. Gary Thompson (garyt att bmb dot leeds dott ac
dot uk) has written an incredibly powerful multi-processor
implementation of relax (which will soon hopefully be published). I'm
currently updating this code to be compatible with the main 1.3 relax
line (http://svn.gna.org/viewcvs/relax/branches/multi_processor_merge/).
This can be set up, in the future, as simply a setting within the
GUI. Parallelpython is not necessary as it is incredibly easy
nowadays to run OpenMPI on Linux systems. More interesting would be a
'grid fabric' added to Gary's multi-processing architecture so that
you could run relax across a number of computers in the department.
But essentially everything is already done. To get this into the GUI,
the multi_processor_merge branch has to first be merged back into the
mainline.
The most urgent task will be to get the model-free calculation running.
There I need your help as I don't get it running...
I can help. But I can't code at the moment due to the whitespace
indentation problems. This is an easy fix, and one patch for all
files in the 'gui_bieri' package. But no other changes can occur when
this is happening!
I will work on the log windows incl progress bar and cancel button (and
split the patch).
Remember to create one patch per idea, and include a descriptive
commit message for me to copy-and-past.
Cheers,
Edward
Re: Designs for the relax GUI.