Current Status & the Vision for the TRAP

The implementation of the new DAQ hardware architecture has facilitated the need for new on-line and off-line data analysis packages. The goal of the software development project is to provide a real time online display of data, possibly subjected to user cuts, and also a means to perform a more detailed off-line analysis. The data structure is required to be platform independent (Sun OS, Unix/Linux, and Windows compatibility). The online analyzer will be implemented in a style to have little impact on the DAQ deadtime.

These ideas are being realized in a step-wise scheme. Currently, a modest analysis package based upon CERN/HBOOK libraries is in use, while the desired fully functional analysis package (TUNL Real-Time Analysis Package, TRAP) is under development. The presently used package is in fact an offline replay code. The software architecture is shown in the Figure  5.1.

Figure 5.1: Architecture of the current online system.

4.0in][c]6in

The CODA Event Builder (EB) receives the data from the ROC and sorts it into CODA data banks, which are transfered to disk resident CODA data file. The current software then opens the data file and starts processing the events which have been written thus far. Therefore, there is a delay in the processing of the events from the time they are generated in the EB and the time they are flushed to the data file. Once the analyzer has begun operating on the data, a Physics Analysis Workstation (PAW) session can be started to display the histograms in the Shared Memory Region (SMR). The data can be processed by a user routine to perform any calculations/cuts on the raw data variables. The processed/raw quantities can also be saved into a platform independent HBOOK ntuple for later analysis.

A schematic of the proposed TRAP system is shown in the Figure 5.2. The host server receives the data from the ROC over a dedicated network line and the CODA data banks are generated by the Event Builder process. The events are then passed to the Ring Buffer for distribution to the CODA Event Recorder for disk storage and the Event Buffer for the TRAP. The first level of event processing is done at TRAP by unpacking and sorting events from different detector systems.

Figure 5.2: Architecture of the proposed TRAP.

4.0in][c]6in

Once sorted, the events are stored at three different locations: 1) The ROOT Tree contains sorted data for each detector, event by event. The ROOT Tree is a platform independent, disk resident, compressed binary data file which can be used later to perform offline analysis; 2) A set of histograms (defined by the user) will be stored in a ROOT Histogram disk resident file. This file serves the purpose of storing accumulated/unaccumulated histograms to monitor the status of the experiment. After accumulated, no further analysis/cuts can be performed on the histograms; 3) A shared memory region (SMR) where histograms will be stored to provide a real-time interface to the analyzed data. It must be noted that the list of histograms in the SMR does not necessarily have to be the same as the list of histograms in the ROOT Hist file.

The three tasks mentioned above are facilitated by the use of the ROOT C++ classes TNtuple, THxx, and TMapFile, respectively. The TRAP defines a ROOT Tree and histogram definitions are based upon a user description of the experiment. This system was tested on previously accumulated data from the neutron-deuteron break up experiment. The TRAP is transparent to the flow of data from the Event Buffer. In this case, the data were being generated from a file previously stored by the Event Recorder. The CODA data banks were unpacked by the TRAP event unpacker according to a user description file that associated each detector element to DAQ hardware channel. The detectors elements were mapped to different histograms for the Hist file and the SMR and to various branches of the ROOT Tree. The histograms and the Tree were filled after unpacking each event. The update frequency of the SMR can be adjusted on the GUI to optimize the appearance of live-time histogram filling. Once the host server generates and updates the SMR, a client process can probe the same SMR and retrieve the histograms stored by the server. The client is not authorized to delete, change, or refresh any histograms in the SMR. The client can be configured to update the histogram display at any frequency. Because the client is an independent process, the client histogram updates do not conflict with any server operations (such as taking data or putting histograms in the SMR), other than sharing the CPU cycles of the computer. Figure 5.3 shows the event processing rate as a function of server SMR update frequency in the presence of writing a ROOT Tree. It must be noted that the real-time rates would be higher than these values because the data would be passed through the event builder instead of reading from a disk resident file, which caused added disk I/O time. A variety of common operations (zoom, integration, shading, addition, scaling, etc) on histograms retrieved by the client are available via a ROOT GUI.

Figure 5.3: An example of ROOT displays : Both graphs show the same data presenting the event processing rate as a function of SMR update frequency by the server.

4.0in][c]6in

By successfully reading and displaying the data from the CODA banks in real-time, and writing a platform independent ROOT Tree, it has been demonstrated that such a DAQ analysis scheme is achievable and can be implemented with a modest investment of human resources. The work continues on further benchmark tests and building user friendly GUIs to generate CODA readout lists (CRLs) and histogram/Tree definitions, as well as to make the client software package more robust.