3. Possible solution – Make the components of the pipeline pluggable, so that they can be inserted, dropped or the order changed dependent on the project requirements.
4.
5. It just needs to know any variables (e.g. a run folder), the functions it is to run and the order it is to run them in
6. Each function knows nothing apart from what it is to do and what it should return (typically something which alerts the next function/script to know when to run) Flag Waver Function b Function c Function d Function e Function a
13. It is up to the component which is launched to complete fully and properly – not the function!
14. It is also up to the user to only select an order where if one component is dependent on the output of another that it is queued after that
15.
16. It also has the parameters required (i.e. a run folder)
17. Flag waver calls each function in turn, passing in anything which delays the script the function will call (i.e. LSF job ids for dependency)
18. Function calls the object which will launch the component script or do something, giving it any required parameters. (If something is needed to be looked up, the Object should do this, not the Flag Waver or the function).
19.
20. Object returns any information which the next function will require, typically again, LSF job ids.