R.Lutter, O.Schaile, K.Schöffel, K.Steinberger, P.Thirolf, and C.Broude¹
Accelerator Laboratory of the Universities of Munich, Am Coulombwall 6,
D-85748 Garching, Germany
¹Weizmann Institute of Science, Rehovot, Israel
email:MARaBOU@physik.uni-muenchen.de
Abstract
MARaBOU is a system for data acquisition and evaluation developed at the Tandem Accelerator Laboratory of the Universities of Munich. It consists of a front-end system for data readout, event building, and data transport based on the Multi Branch System MBS, and a back-end system responsible for setup, run control, histogramming, data analysis, and data storage written within the ROOT framework. The ROOT part includes a GUI to control the MBS front-end, a histogram presenter to visualize the data, and class libraries to describe the experiment.
MARaBOU has been recently established as the common data acquisition system at the Tandem Accelerator Laboratory of the Universities of Munich. MARaBOU consists of two main parts as shown in fig.1: it uses the Multi Branch System MBS developed at the Gesellschaft für Schwerionenforschung (GSI), Darmstadt, Germany, as a front-end for data readout, event building, and data transport; the back-end system is written within the ROOT framework and provides class libraries for setup, run control, histogramming, and data analysis and storage. A special code generator eases the use of the system and helps the user to start from scratch.
| |
Fig.2 shows the current hardware configuration. Each data acquisition station is equipped with a pair of PowerPCs (CES RIO2-8062, 200MHz) and a VME-CAMAC interface (CBV, Bastian Technology). A trigger module (GSI) synchronizes the data readout. Data are read from CAMAC by one processor via a VSB connection and written to a dual-ported memory, the second processor then takes data from the VSB port of the memory and sends blocks of formatted events to the Linux host.
 |
The process of code generation is shown in fig.4. The user has to describe the event structure of his experiment by writing a few C++ statements to a so-called ROOT macro (fig.3). These declarations are then processed by ROOT's C++ interpreter CINT and generate code for the MBS front-end as well as for the analyzing program in the Linux workstation.
{
gROOT->Macro("LoadConfigLibs.C"); // load libraries needed by config
TMrbConfig * exa = new TMrbConfig("exa", "Example configuration"); // create a C++ object
// to store config data
TMrbEvent_10_1 * rdo = new TMrbEvent_10_1(1, "readout", "readout of camac data"); // define an event (trigger 1) for readout
TMrbSubevent_10_11 * cdata = new TMrbSubevent_10_11("data", "camac data"); // define a subevent type [10,11]:
// data stored in a zero-padded list
TMrbSilena_4418V * adc1 = new TMrbSilena_4418V("adc1", "C1.N3"); // define camac modules
TMrbSilena_4418V * adc2 = new TMrbSilena_4418V("adc2", "C1.N5"); // (module type & position)
cdata->Use("adc1", "etot de1 de2 de3 de4 veto"); // assign event parameters
cdata->Use("adc2", "pos1r pos1l pos2r pos2l"); // to camac modules
rdo->HasSubevent("cdata"); // connect subevent to event/trigger
exa->WriteTimeStamp(); // include a time stamp to raw data
exa->DefineVariables("I", 1000, "v1[3] v2[4] v3[5]"); // define variables and windows
exa->DefineVariables("F", 1.2345, "v4[2] v5 v6"); // (can be modified interactively)
exa->DefineWindows("I", 0, 1023, "w1 w3 w2");
dtsca = new TMrbUct_8904("dtsca", "C1.N14"); // dead time scaler
exa->WriteDeadTime("dtsca", 1000); // 1 dead-time event every 1000 true events
exa->MakeReadoutCode("", "Overwrite"); // generate C readout code for MBS
exa->MakeAnalyzeCode(); // generate C++ class defs, global pointers, and class methods
// for data analysis within ROOT
exa->WriteToFile("", "Overwrite:Verbose"); // save configuration to root file
gSystem->Exit(0);
}
|
The MBS part has to be compiled under LynxOs and to be linked to the MBS readout task. It performs CAMAC and VME readout and formats events according to definitions in the configuration macro.
The analyzing part consists of a set of C++ class definitions and methods providing means to process incoming event data. It includes standardized methods for histogramming, monitoring, and event storage in ROOT tree format. The user then has to overwrite the Analyze() method with his specific event analysis. Compiling this code and linking it to ROOT and MARaBOU libraries results in a module called M_analyze which acts as a client to the MBS front-end.
 |
M_analyze contains all the code needed to run the experiment. It is responsible for
As M_analyze is able to re-read ROOT-formatted event data from file instead of taking data directly from MBS it may be used without modifications to analyze events in an offline session.
M_analyze is controlled by a graphical user interface (GUI) called C_analyze (fig.6): it allows to choose the mode of operation (input from TCP or file), to define file names and run ids, to set up the MBS front-end (configure, clear), to control the data flow (start, pause, stop), and to save the accumulated histograms.
Histograms, filter conditions, and fitting functions are stored in a memory-mapped file and thus may be accessed online by other programs.
Fig.5 shows the interaction between M_analyze as a data producer and different consumers. At the end of each run the mapped file is converted to standard ROOT format for later use in an offline session.
 |
|
The program HistPresent (fig.7) provides tools typically needed in an online monitoring environment of nuclear physics experiments. Nonetheless it turned out to be also useful for offline data analysis and presentation.
The program gives simple access to ROOT objects stored in memory-mapped areas or normal ROOT files. The objects handled are 1- 2- or 3-dimensional histograms, 1- or 2-dimensional windows, and functions. It allows operations on histograms like adding, subtracting, multiplying, dividing, scaling. Histograms can be re-binned, zoomed, overlaid and projected. All the graphics options provided by ROOT like lego plots, surfaces and contour plots are available.
Windows used as cuts in 1- or 2-dimensional histograms are important in the analysis. HistPresent allows definition of windows either graphically with the help of the mouse or by typing the values on the keyboard or by a combination of both. They can be stored on files e.g. to be used in an online monitoring program. It might be worth to mention that all ROOT objects on a file carry unique names/versions. This largely simplifies the access of objects and readable programming.
ROOT contains the minimization and error analysis program MINUIT. HistPresent provides a simple interface to the functions of MINUIT. Fitting of Gaussians (optionally with tails) and polynomials is possible just with the help of the mouse. More complicated formula functions may be provided by the user in form of a ROOT macro (essentially C++ code). A built-in template macro makes this an easy task even for a non-experienced user. Functions may be stored to and retrieved from a ROOT file like windows. This is typically used to apply corrections to raw data in an analysis program.
A rudimentary peak finder useful for gamma ray experiments is provided.
All graphical objects can be stored as PostScript or gif files or directly sent to a printer.
Many parameters used by the program like canvas positions and sizes, default file names, printer names etc. may be customized in a resource file (.rootrc). Some parameters like expansion factors, lin-log scale are remembered in and between sessions for each histogram individually.
HistPresent has been developed along with its use in experiments. It therefore mainly reflects the needs of the current users. Thanks to the modularity of ROOT and its built-in C++ interpreter CINT implementation of a new functionality is a simple task.
 |