go4logo2.gif (1869 Byte)   New GSI Analysis System GO4  

New Data Analysis Systems at GSI

Draft V 0.5 (July 22, 98, H. G. Essel)

x    ExpDV
N. Herrmann
x    M. Kaspar
x    P. Koczon
x    W. Koenig
x    Ch. Kozhuharov
x    W.F.J. Müller
x    K. Sümmerer


Current Status

According to the 1998 DV paper most experiments currently use GOOSY and/or PAW except the Hades experiment which uses ROOT. Platforms are:

PAW: OpenVMS, Linux, AIX
ROOT: DECunix, Linux

Analysis Classes and Modes

One can classify the requirements for analysis systems in three categories:
Class A: Experiments with complex detector set-ups (geometry, tracks, reconstruction etc.) and high data volume. Examples are HADES and FOPI. The CERN experiment ALICE also would fit here.
Class B: Experiments with complex histograms, statistical analysis. Examples are KAOS, EB, FRS, ESR.
Class C: Experiments with low computing, not too many channels per event, statistical analysis. Examples are small test experiments.

Operation Modes

Besides these classes there are three analysis operation modes:
Analysis gets data from storage (A, B, C)
Online: Analysis gets data from DAQ (A, B, C)
Control: Analysis is integrated in DAQ, i.e. results of analysis are used to control the DAQ (B, C).

The Task

The objective is a replacement of GOOSY and PAW by one or more new systems. These systems shall be available by the end of 1999. The current systems must be maintained for a period of time after the delivery of the new system. New functionality may be required by new types of experiments, i.e. at the ESR.
In a first step we have to develop a roadmap for the development of the new system(s).
In the following sections we describe in a rather brief way the "user requirements", i.e. the key characteristics the new systems shall have. In this draft, the requirements are not assigned to the classes A, B or C yet.
Then we refer briefly to possible solutions and propose a process to realize the new system(s).


User Requirements

  1. New systems shall run on Unix, Windows and VMS to increase acceptance.
    The platforms are: Linux, NT, AIX, DECunix, and OpenVMS. The order of importance is currently not yet fixed.
  2. User Interface
    1. New systems shall provide a graphical user interface.
      A graphical user interface to operate the system improves the usability.
    2. New systems shall provide context sensitive help and/or assistance.
      This is normally provided together with a GUI. A tutorial and real-world examples are required.
    3. New systems shall be programmable through a graphical user interface.
      This would be like LabView or IrisExplorer.
    4. The graphical user interface shall be "compatible" with the GUI of MBS.
      Often the analysis is operated on-line together with the DAQ. Then the GUIs should have the same look & feel.
    5. New systems shall provide a script interface with full functionality.
      It is necessary for batch jobs, but also to execute predefined scripts interactively. All data elements and functions, i.e. graphics shall be available.
    6. Results of scripts/actions shall be accessible by subsequent scripts/actions.
      The output of scripts like fit results shall be storable in a way that they can be accessed by subsequent scripts.
    7. Analysis shall be controlled during execution.
      When an analysis is coupled to DAQ it might be necessary to execute commands in the analysis loop, i.e. to change parameters or to stop the analysis. This feature is required also offline when analyzing interactively large files.
    8. Analysis shall be able to run interactively or in batch.
      This is automatically achieved by a script interface.
  3. Data Management
    1. Analysis shall be independent of input source.
      The analysis software should be independent of the data input, i.e. online or offline, even if an online analysis has a different functionality as an offline analysis. Offline analysis from raw data tapes shall be possible.
    2. Analysis shall be able to get event input from DAQ servers.
      The DAQ systems provide various event servers. The new system shall implement clients for these servers.
    3. All systems shall be able to exchange relevant data.
      Systems must be able to process data, i.e. histograms and event or other data, as produced by DAQ, slow control, simulations and other commonly used systems. This is the GEF format for histograms, the MBS format for event data, and N-tuples for compressed event data. The system shall provide modules to read/write other event data formats.
    4. Systems shall provide a data management.
      Organization of data elements, IO and storage shall be supported by appropriate tools. All parameters of an experiment or analysis run should be stored in standard data bases. These include set-up parameters of DAQ, calibration parameters, filters, run specifications etc. The parameters must be accessible from the analysis.
    5. Data elements shall be arrays of aggregates.
      Histograms and other (user) data elements are referenced by names. When very many data elements of the same kind exist, it shall be possible to process multidimensional arrays of such elements.
    6. Systems shall automatically save accumulated data in case of termination.
      It saves a lot of time (CPU and human) if accumulated data are not lost in case of abnormal program termination. This means especially histograms.
  4. Analysis
    1. Systems shall provide easy to use programming interfaces to the event data.
      This means the "classical" user event routine doing all the work.
    2. Systems shall provide easy to use programming interfaces to the graphics.
      There must be an API to access graphical objects like polygons or scatter plot points.
    3. Systems shall provide tools to map event data to detector geometry.
      The data representation in the event data might not be suited for further processing. A representation fitting detectors or physical items should be supported.
    4. Systems shall provide complex projections in multidimensional data spaces.
      A mechanism like N-tuples, but also visualization of complex data and various kinds of filters (conditions). The mechanisms shall be fast and interactively configurable.
    5. Analysis shall provide statistic tools.
      Other methods besides fit functions needed for the analysis of statistic data shall be developed.
    6. Analysis shall have online access to DAQ control functions.
      Sometimes event data must be accumulated and analyzed online to steer some DAQ set ups.
    7. Some parts of the analysis shall optionally run online in the front-ends.
      When the online analysis is needed to control the DAQ it would be necessary to have direct access to the control hardware. In this case the analysis must run in the DAQ front end. Only a subset of the functionality is needed. The visualization might be done on a remote node.
  5. Display
    1. Display shall operate independently of analysis execution.
      When the analysis is running it is necessary to look at the data.
    2. Display shall provide visualization of complex and/or multiple objects.
      It should be possible to compose complex views of histograms or other data. This could be views of many histograms in one frame, 3D views of data and polygons etc.
    3. Display set-ups shall be savable.
      Often one wants to save all display parameters, i.e. boundaries and scaling, and apply them to different data.
    4. Display shall generate ready to publish paper prints.
      At least the system should make prints like WYSIWYG. Eventually a data export to other graphics packages would be necessary.
  6. Constraints
    1. Use existing software as base.
    2. Use software common to community.
    3. Keep external software unchanged except changes are accepted and implemented by authors.
    4. Add required features.



Constraint 1 makes it necessary to evaluate software packages which could be the base for the new system(s). Possible packages are:

  1. LabView/BridgeView
  2. LEA
  3. Root
  4. LHC++

Some features of these packages:









Class C


Easy to use.


NT only.


Could be standard for slow control


Class C, Control

Runs in MBS
GSI home made

GSI home made




Class B, Class A

Many platforms.



Does it survive?


Class B, Class A

Standard CERN.

Not yet proven
Offline only?




Feasibility Study Projects

We have to establish some projects to learn about the features of the packages under consideration.

  1. Labview/BridgeView
    1. Develop simple histogram display GUI
    2. Develop input channel to MBS
    3. Develop some simple VIs for analysis
  2. Root
    1. GUI development
    2. Input from MBS
    3. Multithreading
    4. Storage I/O
    5. Java interface
    6. Hades project
  3. LHC++
    1. Get up a running environment
    2. Iris Explorer
    3. Objectivity


GSI Helmholtzzentrum für Schwerionenforschung, GSI
Planckstr. 1, 64291 Darmstadt, Germany 
For all questions and ideas contact: J.Adamczewski@gsi.de or S.Linev@gsi.de
Last update: 27-11-13.