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