Re: [Taverna-users] Iterations and waiting for data

[Stian Soiland-R. <soi...@cs...>]

On Fri, Aug 29, 2008 at 11:45 AM, Tom Crick <tc...@cs...> wrote:
> I think the nested workflow idea will be a good solution for this, but
> the only problem will be the Fail processor discarding the values - they
> will need to be returned to check to see if the optimisation needs to
> continue. Thanks for the links, I will check out the Beanshell example.

You're in a way asking for loops, which is difficult to achive in a
Taverna 1 workflow.

> Also, it is appropriate to use the UI Select control to decide which
> path in a three-way branch you wish to take in the workflow i.e. you
> have three different optimisation tools/methods you could use and you
> wish the user to select one? The rest of the workflow would be pretty
> much the same for all three, but it would just mean calling a particular
> web service when the user selects one of the three.

Most of the time we would always say that the UI controls are bad
practice because they stop the workflow execution in the middle and
also requires the workflow to run on the desktop.  If you only want to
be able to have a parameter that you decide at run-time, you could
also do this as a normal workflow.

We have a bug already to be able to specify an input from a limited
selection of values:

http://www.mygrid.org.uk/dev/issues/browse/TAV-486



You can put a beanshell script "checkA" that check if the string from
the UI control is "pathA" and throws an Exception if not, and you have
a similar two beanshell scripts for pathB and pathC (those being the
three choices of the UI popup).

Then put control links from procA to checkA, procB to checkB, etc.,
and hopefully only one of them would run depending on which thing you
choose in the pop-up.


The problem is that Freefluo (the Taverna 1 enactor) can be a bit
buggy about this, for instance if you use the "Fail_if_true" processor
and the "Fail_if_false" processor, and you give it the string "fish"
- neither will fail and both processors will run - but only one of
them will "win" if merging the output - it cannot be determined in
advance which one!

If however you make sure your beanshell scripts fail except if they
get the correct string, then you can reasonable make sure that only
one of them will finish, and only one of the three branches will
execute.



For Taverna 2 this has been changed so that you can't have the "Select
first result" merge, you can only have a merge to a list when you
connect several links to a ports. This also means that the above
method wouldn't work in Taverna 2, however it's possible to do it in a
much cleaner way, where you could have a single processor with three
activities (for instance 3 nested workflows), and on the dispatch
stack of the processor you can have a "side"-activity that does the UI
bit, returning say the number 2 to select the second activity.     We
have not written such a layer yet for Taverna 2, but it shouldn't be
too hard if there's requests for it.

(A very similar layer can do the often asked-for while-loop)


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester