The sequence of steps within a task is set by an XML file that is uploaded
via the GINO front end to create the task. This file also sets up input &
output files, what code to run, which batch quesues to run it on, etc.
The XML files are generated by perl scripts in the task directories under
$beatestPlRoot.
Beam Test Pipeline Overview
Currently being updated
The pipeline automatically retrieves all online data produced by LATTE which are currently stored in directories associated with runs numbers and brings them to the SLAC farm. After that, it populates an ORACLE database which provide queries to the data. The pipeline also creates
Beam Test Pipeline Overview
Currently being updated
The pipeline automatically retrieves all online data produced by LATTE which are currently stored in directories associated with runs numbers and brings them to the SLAC farm. After that, it populates an ORACLE database which provide queries to the data. The pipeline also creates reports, and launches data processing/reconstruction code to produce data files and high level analysis ntuples.
A pipeline diagram can be seen below 
...
Pipeline tasks are structured as a linear chain of steps. Each step must succeed before going on to the next one. Each step must be attempted, until one fails or the last one succeeds. That is to say, there is no flow control, and no parallelism. In order to deal with this, and to reduce the chance that a step would not be reached due to the failure of a previous step on which it did not logically depend, the work we do in the pipeline is split into 7 tasks, all but one of which (updateELogDB) are launched by other tasks. This launching is done without GINO's (the pipeline infrastructure) knowledge.
The sequence of steps within a task is set by an XML file that is uploaded via the GINO front end to create the task. This file also sets up input & output files, what code to run, which batch quesues to run it on, etc. The XML files are generated by perl scripts in the task directories under $beatestPlRoot.
There is no file, script, datastructure, or anything outside the maintainer's head that codifies the global structure of it all.
Tasks launch other tasks using the $beamtestPlRoot/lib/TaskLaunch.pl script. My convention has been that I launch each task in a separate TP. The TP and the script and wrapper that it uses have names beginning with "Launch".
The names of files registered with GINO is constrained to follow a certain format. When one task produces a file that is used as input to another task, the name given by the first task is not the name expected by the second one. Thus, part of the process of one task launching another is to create symbolic links with the name expected by the downstream task.
...