On Wed, 2006-10-11 at 18:25 +1000, Edward d'Auvergne wrote:
2.3 The pipe concept
A single run can be thought of as a pipe where data is input, processed,
or output as user functions are called. There are different types of
pipe for different analyses, e.g. a reduced spectral density mapping
pipe, a model-free pipe, an exponential curve-fitting pipe, etc. When
running relax you choose which run (or pipe) you are currently in and
the 'run.switch()' user function allows you to jump between multiple
runs (or pipes). The modification of user functions in which runs are
combined or branched (which can be thought of as the pipes merging or
splitting) would be straight forward. For example the
'model_selection()' user function currently accepts the following
arguments:
model_selection(self, method=None, modsel_run=None, runs=None)
In this case the 'modsel_run' can be dropped and the results of model
selection placed into the current run (or pipe). The 'run' user
function class could contain the following user functions for pipe
manipulation:
run.copy() # Create a new run (or pipe) with the current contents of
another run (or pipe).
run.create() # Create a new run (or pipe). Switch to this pipe by
default.
run.current() # Print the current run (or pipe).
run.delete() # Delete the given run (or pipe).
run.delete_all() # Delete all runs. Essentially deleting
'self.relax.data'.
run.hybridise() # Fuse two runs (or pipes) into the current run (or
pipe). Overlapping data in the two runs must be identical!
run.list() # Print all runs (or pipes).
run.switch() # Switch to another run (or pipe).
One evolutionary path of the run concept which could be followed with
this set of proposed changes is to completely replace it with the pipe
concept. All instances of 'run' in relax would be renamed to 'pipe'.
For example 'run.create()' will become 'pipe.create()',
'self.relax.data[self.relax.run]' will become
'self.relax.data[self.relax.pipe]', etc. I believe that the name 'pipe'
is a better representation of the run concept than 'run'. What do you
think of the idea?
I like this idea.
One thought that occured to me is that sometimes its useful to execute a
command on several runs (or pipes) at once. One way of doing this would
be to retain a 'run' argument for user commands, but to have it
optional. If it is passed, then the command executes in each of the
specified runs, but returns to the current run after execution.
Implimentation of this could employ a generic internal 'run loop'
function which loops through the runs and calls the fuction. So we might
have, at the prompt code level:
def user_command(args, runs=None):
sanity_check(args)
if runs:
run_loop(runs, do_command, args)
else:
do_command(args)
with:
def run_loop(runs, do_command, args):
current_run = run.current()
for run_name in runs:
run.switch(run_name)
do_command(args)
run.switch(current_run)
The alternative would be to have the run_loop visible to the user
(called something more usefull, I guess), and leave the user to deal
with it.
Chris
The hypothetical ideas of this paragraph are not part of the current
proposals, however they further illustrate the pipe concept. The pipe
concept is highly amenable for the creation of a Qt GUI. Program
execution could be directed by a graphical 'pipe' construction (possibly
in 3D using OpenGL). Elements of the pipe, equivalent to the user
functions of the prompt and script interfaces, could be dragged from
toolbars and dropped into a canvas. These could be linked together by
moving the element with the mouse and having it click into other
elements. For example 'run.delete()' (alternatively 'pipe.delete()')
could be represented as a cap added to the end of a pipe - its execution
removes all the data of that pipe from memory. This pictorial
representation of execution would be very powerful and intuitive.
Scripts could be imported into the GUI and represented as a network of
interconnected pipes and vice versa. Execution of relax could even be
animated as semi-transparent pipes filling up bit by bit as each user
executes. Imagination is the only limit!
_______________________________________________
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
Re: Redesign of the relax data model: 2. A new run concept