> This idea, although it is good, unfortunately still suffers from the
> problem I described in the second paragraph of section 1.1
> (https://mail.gna.org/public/relax-devel/2006-10/msg00054.html,
> Message-id:
<1160551172.9523.60.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>).
> The dense branching of the 'run' argument would simply be replaced by
> the 'runs'. This is a consequence of all the times 'self.relax.data'
> needs to be accessed. The unnecessary complexity and branching is
> still there - the 1645 occurrences of the text 'self.run' would
> remain, they would just be renamed to 'self.runs'.
Either I don't understand the problem, or you don't understand my
solution (or both? - either way probably my fault). Importantly, if it
is not already clear, what I am suggesting is a simple extension of your
proposal, not a replacement for it. As I see it, the proposal above
doesn't involve branching of the 'runs' argument - it is caught at the
earliest possible opportunity (ie. in the prompt code) and passed into a
simple and general run_loop function. My suggestion is precisely
analagous to your spin selection loop in both design and motivation (or
if it is not, that is because I'm not understanding something - it is my
intention that it should be).
The 1645 occurrences of self.run would not remain in my suggestion, as I
understand it. There are no references to self.run in the psuedocode
above, so I see no reason why there should be any more under my proposal
that there is under yours. If 'runs' is passed by the user (and I
envision this as a relatively rare occurence) it simply has the effect
of passing flow control to run_loop so that the desired command is
executed in all the required runs in turn. Note that run_loop uses your
proposed run.switch() function, it does not pass 'runs' any deeper into
the relax code.
Sorry, the misunderstanding is 100% on my part. I assumed that the
run_loop was at the lowest level, at the point where 'self.relax.data'
is accessed. This is probably a relic of my old way of thinking that
only code for testing user function arguments should be located in the
functions of the 'prompt' directory. It is also because I was
associating it with the molecule-residue-spin loop proposal as well,
i.e. you loop over runs first, then molecule, then residues, then
spins.
Now that I can see the errors of my ways (or thinking), and that the
idea is implemented at the level of the user functions themselves, the
concept is quite good. Essentially the run loop switches between the
pipes executing the actual user function on each - that is a good
idea! That does add an extra level of optional flexibility to relax.
Thanks for clearing that up.
This should be implemented at the level of the user functions as it
would be messy implementing it at the next level (the individual
functions of the 'generic_fns', 'specific_fns', and 'dx' directories).
The 'runs' argument (or possibly 'pipes' argument) would then only
exist for a very short time in the code of the 'prompt' directory. I
would suggest that the run loop be placed in the file
'generic_fns/runs.py'. If the full proposal is accepted, this will be
renamed to 'generic_fns/pipes.py' and the function hence called
'pipe_loop'.
Your idea Chris should definitely be part of the changes. It would be
extremely simple to implement too (once the pipe concept has been
implemented). I hope I didn't offend you by misunderstanding your
proposal. Oh, I have one simple question. Do you think that the
current pipe should be included in the pipe loop, even if it isn't
passed in as an argument?
Edward
Re: Redesign of the relax data model: 2. A new run concept