WTI/Experiment Electronics/Data Processing: Go4

Previous tutorial 7  |    Go4   Example 8   |  Next tutorial 9

Tutorial 8

What do we have now

The setup of the steps now follows nicely our analysis. But the data flow goes only in the direction of processing generations of events. Often it is very useful to split the events according to sub systems or detectors. This can also be done using the Go4 steps.

Set up parallel steps

For that we first create a directory and change to it. We enable Go4 by
> . go4login
Now the variable GO4SYS should point to the top Go4 directory. Copy the tarball tut08.tar from Example above into your directory and unpack it to your new directory:
> tar xvf tut08.tar
> . ./rename.sh XXX St5
> make all
As before this should create a libGo4UserAnalysis.so library which is used by the standard Go4 analysis main program..
The most important components are:

TSt5Analysissetup.C
TSt5MakeUnp1TSt5EventUnp1
TSt5MakeCal1TSt5EventCal1
TSt5MakeUnp2TSt5EventUnp2
TSt5MakeCal2TSt5EventCal2
TSt5MakePhysTSt5EventPhys
TSt5Param

We have five steps: 2 unpack, 2 calibrate and physics. Each step has a processor (Make) producing an output event (Event). The first step uses the MBS input provided by Go4 as in the previous example. But it processes only subevents with ID 1 and copies it into the output event. Similarly the first calibration step calibrates only data from this subevent. The second unpack and calibration steps do the same for subevents with ID 2. Naturally the last step needs both outputs of the calibration steps to do the final analysis. The table below shows the setup as it is done in the setup file.

StepInputProcessorOutput
Unpack1MBSMakeUnp1EventUnp1
Calib1EventUnp1MakeCal1EventCal1
Unpack2Input of Unpack1 MBSMakeUnp2EventUnp2
Calib2EventUnp2MakeCal2EventCal2
PhysicsOutput of Calib1 and Calib2MakePhysEventPhys

In comparison with tutorial 7 you may notice, that there are breaks in the chain of output/input events, namely in steps Unpack2 and Physics. Unpack2 needs the MBS event as input to get the data of subevent 2. This event has already been read for step 1. In the TSt5MakeUnp2.cxx you will see that in fact the event source of step Unpack1 is used. Similarly TSt5MakePhys.cxx uses the two outputs from Calib1 and Calib2, respectively.
In the setup file for these two steps no input event is declared. Because the chain of steps is controlled by the framework, we must disable the checking of the IO chain. This is done by the line

go4->SetStepChecking(kFALSE);
The steps are created and setup in setup.C as before.

Running the analysis from shell

The built in random event generator is used as data source:
> go4analysis -events 100000
The output shows in detail what happens like in the previous examples. After having processed the 100000 events, the program terminates and has produced a root file which we now inspect using the Go4 browser.

Launch analysis by GUI

Now use the Analysis->Launch Analysis to open the window to launch the analysis. Check if the values in the window are correct, i.e. that the directory path is your current directory.
After pressing the Start button the analysis is launched and the configuration window comes up. Select as Event source MBS Random and give it a name. Then press Submit and close the window (can be opened any time by Analysis->Configuration). You will see now five tabs, one for each step. The source/store radio buttons refer to file IO: Enable source means get event from file, otherwise from previous step, Enable store means store events to file. The first step logically must have an enabled source. These three step control settings can be seen in the tab headers by x or o.

If you look into the folders you will see subfolders for the steps:

Why does it not work really?

As long as we do not write/read files everything is OK. But look at the last step. It needs the output events of the calibration steps. That means, even if their calibrated data have been stored in files, the last step cannot get them from there without code changes.
Similarly the second unpack step needs the first one because it uses its input MBS event. But eventually one wants to unpack only subsystem 2, and then we have to change the code. All that prevents us from using the analysis in an efficient way, i.e. save results of steps in files, disable these steps, and get the data for the following steps from the files.
The solution will be shown in the next tutorial.
In addition it would be nice if we could execute a function when all objects are there and ready to go, i.e to check if all is OK. Similarly we would like a function called after the event loop stopped.

Next tutorial

WTI Experiment Electronic Data Processing Group
Hans Essel , GSI Helmholtzzentrum für Schwerionenforschung mbH, GSI
Total 150, last 2024 Apr 25 16:57
Last update: 2009 Nov 24 16:06