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


GSI Object Oriented On-line Off-line System GO4

GO4 User Requirements Document

 

 

Version: 2.01
GO4_URD_201.DOC
January 11, 1999

H. Essel, N. Kurz, M. Richter; DV&EE
GSI
Gesellschaft für Schwerionenforschung mbH
Planckstr. 1
D-64291 Darmstadt

 

1       Summary

In 1998, GSI has started a project for the evaluation and implementation of a new software system for low and medium energy physics experiments. It will cover data acquisition, data analysis, and set-up control in on-line and off-line mode. The new system shall include features of currently used systems, like the GSI in-house software GOOSY [Ref. 2] and the CERN software packages PAW and CERNLIB. The data acquisition system MBS (Multi Branch System) developed at GSI [Ref. 3] will be integrated. But input data may also come from any other acquisition system.

The new object-oriented system (proposed name GO4: GSI Object Oriented On-line Off-line system) shall be available on various UNIX's and on Windows-NT. It might be based on software currently available like the CERN software packages ROOT or LHC++. But it would need several extensions to handle specific requirements of the low and medium energy physics experiments.

The first project phase has been used to acquire user requirements and to evaluate existing software systems.

The following list of requirements had been revised by most of the potential users of a new system. The users have made their comments to all points and this document takes into account these comments already. The users also have voted for the priority they would like to see in the implementation of the requirements.

     

2    Table of contents

1  Summary*
2 Table of contents *
3 Lists *
      3.1 List of requirements *
4 Introduction *
      4.1 Notes on this document *
      4.2 Abbreviations and definitions *
5 General classification of user environments for GO4 *
      5.1 Analysis Classes *
      5.2 Analysis Operation Modes *
      5.3 Target system users *
6  User Requirements *
      6.1 General Requirements *
      6.2 User Interface *
      6.3 Data Management *
      6.4 Analysis *
      6.5 Display *
      6.6 Data Acquisition *
      6.7 Constraints *
7 Various specifications *
      7.1 List of existing software *
         7.1.1 GOOSY *
         7.1.2 IDL *
         7.1.3 LEA *
         7.1.4 LHC++ *
         7.1.5 MBS *
         7.1.6 National Instruments *
         7.1.7 ROOT *
8 References *

3      Lists

3.1   List of requirements

    P x : priority defined by the users, 0 = no comment, 1 = lowest priority, 10 = highest priority

    Requirement 1: P 8 GO4 shall be simple to use and easy to learn *
    Requirement 2: P 7 User programming shall only be necessary in one place (analysis program) and in command lists *
    Requirement 3:
    P 7 All functions shall be provided by commands *
    Requirement 4:
    P 8 It shall be a portable data acquisition and analysis system including front-end, workstation or PC, and storage devices for experiments outside GSI *
    Requirement 5:
    P 7 New systems shall run on UNIX and Windows NT to increase acceptance *
    Requirement 6:
    P 7 The system shall have as few licensed software included as possible *
    Requirement 7:
    P 8 A new system shall provide a graphical user interface, GUI *
    Requirement 8:
    P 8 A new system shall provide context sensitive help and/or assistance *
    Requirement 9: P 5
    A new system shall be programmable through a graphical user interface *
    Requirement 10: P 7
    The graphical user interface shall be "compatible" with a to be built GUI of the MBS *
    Requirement 11: P 8
    A new system shall provide a script interface with a full functional script language *
    Requirement 12: P 7
    All user actions, graphically, command line, or script based, shall be logged *
    Requirement 13: P 7
    Results of scripts and actions shall be accessible by subsequent scripts and actions *
    Requirement 14: P 9
    The data analysis shall be controlled during execution *
    Requirement 15: P 9
    The data analysis shall be able to run interactively or in batch *
    Requirement 16: P 5
    The GUI shall run on more platforms than the analysis system runs. The user shall be able to add new or correct elements to an existing GUI. *
    Requirement 17: P 8
    The data analysis shall be independent of the input source *
    Requirement 18: P 8
    The analysis shall be able to get event input from DAQ servers *
    Requirement 19: P 8
    A new system shall be able to exchange relevant data with other systems *
    Requirement 20: P 8
    A new system shall provide a data management *
    Requirement 21: P 8
    Data elements shall be multidimensional arrays of aggregates *
    Requirement 22: P 8
    A new system shall automatically save accumulated data in case of termination *
    Requirement 23: P 8
    A new system shall provide easy to use programming interfaces to the event data *
    Requirement 24: P 7
    It shall also be possible to call most parts of the analysis package from user programs *
    Requirement 25: P 7
    A new system shall provide easy to use programming interfaces to the graphics *
    Requirement 26: P 6
    A new system shall provide tools to map event data to detector geometry *
    Requirement 27: P 7
    Efficient accumulation of many large matrices, e.g. 4k * 4k long words = 64 MB each shall be provided *
    Requirement 28: P 5
    The system shall optionally provide the symmetrical creation of multiple-dimensional spectra *
    Requirement 29: P 7
    A new system shall provide complex projections in multidimensional data spaces *
    Requirement 30: P 8
    The propagation of data errors shall be handled correctly *
    Requirement 31: P 8
    Other methods besides fit functions needed for the analysis of statistical data shall be provided *
    Requirement 32: P 5
    Connections to a Gamma line data base shall be provided *
    Requirement 33: P 5
    Interactive graphical analysis of gamma-ray coincidence data shall be provided *
    Requirement 34: P 6
    Analysis of time correlations between events (Alpha ray mother-daughter relations) in a time scale of ms to min shall be provided *
    Requirement 35: P 6
    A sort of trending storage of data, i.e. keeping events in a ring buffer for a given time window shall be provided *
    Requirement 36: P 8
    The analysis shall have online access to DAQ control functions *
    Requirement 37: P 7
    Some parts of the analysis shall optionally run online in the frontends *
    Requirement 38: P 7
    The analysis speed shall be equivalent to the data acquisition speed *
    Requirement 39: P 8
    The display shall operate independently of the analysis execution *
    Requirement 40: P 9
    Scatter plots of all data shall be possible *
    Requirement 41: P 8
    A simple set-up of scatter plots shall be provided *
    Requirement 42: P 8
    Color in scatter plots shall be used to distinguish different kinds of points, i.e. conditions or sources *
    Requirement 43: P 6
    Scatter plots with several points per event shall be provided *
    Requirement 44: P 5
    Any number of scatter plots shall run in the background *
    Requirement 45: P 8
    A "real" re-binning of spectra shall be provided, i.e. the transformation from n channels to m channels *
    Requirement 46: P 8
    The display shall be definable and savable by the user in a simple way *
    Requirement 47: P 6
    Mixed pictures with scatter plots and spectra shall be provided *
    Requirement 48: P 6
    The display shall generate ready to publish paper prints *
    Requirement 49: P 7
    Graphic dumps shall contain all details of a representation including data, scales, comments, errors, windows, etc. *
    Requirement 50: P 8
    Data links to commercial data analysis and presentation software shall be simple *
    Requirement 51: P 7
    The time dependent acquisition of single and multiple data shall be possible *
    Requirement 52: P 5
    Gamma ray input channels shall be sampled by fast flash-ADCs for further detailed analysis (e.g. pile-up) or for storing these data in ring buffers (equidistant in time) *
    Requirement 53: P 8
    Setting and controlling of the experimental hardware set-up and accelerator parameters by the data acquisition and/or the real-time data analysis shall be possible *
    Requirement 54: P 7
    A real-time analysis in the data acquisition processor connected with set-up control shall be possible *
    Requirement 55: P 7
    Constant fractions, amplifiers, high-voltage supplies etc. shall be set and controlled by the data acquisition *
    Requirement 56: P 8
    Set-up parameters shall be logged by the data acquisition *
    Requirement 57: P 7
    Existing software shall be used as a development base *
    Requirement 58: P 8
    Software common to community shall be used *
    Requirement 59: P 7
    External software shall be kept unchanged except changes are accepted and implemented by the authors *
    Requirement 60: P 7
    The required features shall be added to the existing software *

4    Introduction

4.1  Notes on this document

This document contains the description of components and behavior of a data acquisition and analysis software system used in experiments at GSI.
It has been created in conformance with the ‘ESA Software Engineering Standard for User Requirements Documents’ [Ref. 1]. The document is the result of a problem definition phase. It is the fundamental document for the entire project development of the GO4 system.
The document is of particular relevance to users and developers. It is to be used by the developers for the creation of the system definition document and by the users for the creation of test procedures for the acceptance phase.

4.2  Abbreviations and definitions

    Abbreviations Definitions
    ADC Analogue-to-Digital-Converter for current, voltage, or charge
    API Application Program Interface
    CAMAC Data acquisition, read-out and control bus system mainly used in nuclear and high energy physics experiments
    Crate Standardized bin system for power distribution and data bus , e.g. VME-Crate
    CVC CAMAC to VSB crate Controller. A GSI developed processor board based on Motorola 68030 with a front-panel VSB connector. This crate controller is supported by the MBS.
    DAQ Data acquisition system
    DSP Digital Signal Processor, very fast numerical microprocessor, e.g. Texas Instruments TMS 320C40 or Analog Devices SHARC
    E7 VME processor board EUROCOM 7 of ELTEC Elektronik GmbH, Galileo-Galilei-Str. 11, D-55129 Mainz based on Motorola 68030. This board is supported by the MBS. (http://eltec.de)
    FASTBUS Data acquisition read-out bus system used in nuclear and high energy physics experiments
    FTP File Transport Protocol of the TCP/IP protocol (data transfer method between computer nodes)
    GEF GSI Exchange Format. Histograms can be dumped in this standard format to text files and processed by GOOSY, SATAN-GD or PAW.
    GUI Graphical User Interface
    IRIS Explorer IRIS Explorer is a powerful yet easy-to-use sophisticated visualization system and application builder of NAG, The Numerical Algorithms Group Ltd, Oxford UK. (http://www.nag.co.uk/visual/IE/iecbb/Product.html)
    Java Java (tm) is an industry standard of Sun Microsystems, Inc., USA. The Java platform is based on the power of networks and the idea that the same software shall run on many different kinds of computers, consumer gadgets, and other devices. (http://java.sun.com)
    LHC++ In response to the requirements of the CERN LHC collaborations, a working group was set up at CERN in 1995 to investigate how the approximate equivalent of the current CERNLIB environment could be provided in the LHC era. (http://wwwinfo.cern.ch/asd/lhc++)
    LynxOS UNIX real-time operating system of Lynx Real-Time Systems, Inc., 2239 Samaritan Drive, San Jose 95124 CA, USA (http://www.lynx.com)
    MBS Multi-Layer Multi-Branch Data Acquisition System. The MBS is a software system for the acquisition of experimental data from various hardware setups like CAMAC, VME, VXI, FASTBUS. It is based on the LynxOS operating system. The MBS has been developed at GSI. (http://www-gsi-vms.gsi.de/daq/home.html)
    Minuit Minuit is a Function Minimization and Error Analysis software package from the CERN Program Library. Minuit is conceived as a tool to find the minimum value of a multi-parameter function and analyze the shape of the function around the minimum. (http://wwwinfo.cern.ch/asdoc/minuit_html3/minmain.html)
    NIM Nuclear Instrumentation Module. Standardized 19" bin, power supply and module system. Up to 12 modules can be plugged into a bin.
    Picture Ensemble of graphical display elements like spectra and scatter plot forming a complete screen picture. A picture can be designed and its structure and components stored individually by the users.
    POSIX Portable Operating System Interface. The ISO 9945-1 (= IEEE Std 1003.1-1990) software standard.
    RIO VME processor board of CES Creative Electronic Systems, 70 route du Pont Butin, CH-1213 Petit-Lancy, based on PowerPC 603e or 604e. (http://www.ces.ch/WelcomeCES.html). This board is supported by the MBS.
    ROOT The ROOT system provides a set of object-oriented frameworks with all the functionality needed to handle and analyze large amounts of data in a very efficient way. (http://root.cern.ch)
    RPC Remote Procedure Call. A protocol for the execution of procedures on remote computer systems. It includes parameter transmission in both directions.
    SAM DSP-processor VME-board for controlling and read-out (Steuer- und Auslesemodul) developed and built at GSI
    Scatterplot painting point by point in 2 dimensions, each point is specified by values of x and y coordinates, color, size, and shape. Normally painted event by event.
    TCP/IP Transfer Control Protocol/Internet Protocol (protocol for computer networks)
    VME Crate, data bus, and module system to connect data and processor modules. Standardized protocol, mechanics, power supply, and data bus. VME-Crates can contain up to 21 modules.
    VSB VME Subsystem Bus. Standardized separate data bus of the VME-standard

5      General classification of user environments for GO4

5.1  Analysis Classes

In the following the environment for analysis systems will be split up into three categories:

  1. Class A:
  2. Experiments with complex detector set-ups (geometry, tracks, reconstruction etc.) and high data volume. GSI examples are HADES and FOPI. The CERN experiment ALICE would fit here, too.

  3. Class B:
  4. Experiments with complex histograms, statistical analysis. GSI examples are KAOS, Euroball, FRS, ESR.

  5. Class C:

Experiments with low computing, not too many channels per event, statistical analysis. Examples are small test or laboratory experiments.

5.2  Analysis Operation Modes

Besides the analysis classes there are three analysis operation modes:

  1. Online:
  2. Analysis gets data from a DAQ (A, B, C)

  3. Offline:
  4. Analysis gets data from storage (A, B, C)

  5. Control:
    A subset of an analysis package is integrated in DAQ, i.e. results of analysis are used to control the DAQ (B, C)

5.3  Target system users

The following user categories are intended to become GO4 users (or requesters) although there shall be no principle limitation to very large, high energy physics experiments:

  1. all experiments of the following fields
    1. nuclear physics
    2. atomic physics
    3. plasma physics
    4. nuclear chemistry
    5. biology
  2. small size experiments, e.g. with laboratory set-ups, detector tests, or small beam experiments
  3. medium size physics experiments, like fragment separators, gamma spectroscopy, atomic physics experiments
  4. medium size physics experiments in connection with accelerator control
  5. detector tests or test experiments of medium or large scale experiments

6      User Requirements

The priority of each requirement has been requested from the potential users of GO4 at GSI. The following scale was used:

0 = no comment, 1 = lowest priority, 10 = highest priority

The result of all priority assignments is listed in this document. Each value has been calculated as the rounded mean value of all assignments without counting the "0" assignments for a requirement. The following graphics show the overall result of the poll.

wpe1.gif (25102 bytes)

 

wpe2.gif (23743 bytes)

 

6.1  General Requirements

These requirements define general features the GO4 shall have.

Requirement 1: P 8 GO4 shall be simple to use and easy to learn
GO4 shall take into account that its acceptance will depend on a compromise between an easy user interface and a full functional system. Many experiments at GSI and in other laboratories have short lifetimes, inexperienced and untrained users, and external users arriving only days before the start of an experiment. There will also be two levels of usage:

  1. Usage of the functions provided by the system, only (mainly inexperienced users).

  2. Implementation of new functions by the users (more sophisticated users).

Requirement 2: P 7 User programming shall only be necessary in one place (analysis program) and in command lists
Since most users have only poor programming experience the amount of specific code necessary to adopt the system to individual needs of each experiment shall be limited. Thereby possible errors produced by user code will also be limited.

Requirement 3: P 7 All functions shall be provided by commands
The whole system shall be accessible through a graphical user interface (GUI), programming interfaces (API), and commands. The command language shall be as close to the programming interface as possible, but simple enough to be used by inexperienced and untrained users. For experiments with fixed, limited functionality a simple (GUI) setup tool shall be provided.

Requirement 4: P 8 It shall be a portable data acquisition and analysis system including front-end, workstation or PC, and storage devices for experiments outside GSI
It is necessary to have a hardware and software system which can be carried easily to external experiments at remote institutes or which can be adopted easily by other institutes. Both, acquisition and analysis system shall be separated, i.e. shall run independently from each other such that each part will be exchangeable.

Requirement 5: P 7 New systems shall run on UNIX and Windows NT to increase acceptance
The platforms should be at least:

  • Linux
  • Windows NT
  • AIX

The order of importance is not yet fixed. The implementation should rely on standards, e.g. POSIX, Java, wherever possible.

Requirement 6: P 7 The system shall have as few licensed software included as possible
Since many users of the new system will be from university institutes or from other countries it would be of help to reduce possible license fees to an absolute minimum.

6.2  User Interface

These requirements define features of the interface to the user, i.e. graphical, procedural, and command interfaces.

Requirement 7: P 8 A new system shall provide a graphical user interface, GUI
A graphical user interface to operate the system improves the usability. It is necessary for all simple experiments run by individuals not well trained in programming languages, specifically not in object oriented methods.

Requirement 8: P 8 A new system shall provide context sensitive help and/or assistance
This is normally provided together with a GUI. A tutorial and many real-world examples are required.

Requirement 9: P 5 A new system shall be programmable through a graphical user interface
This feature would be like the graphical language of LabView or Iris Explorer.

Requirement 10: P 7 The graphical user interface shall be "compatible" with a to be built GUI of the MBS
Often the analysis is operated on-line together with the DAQ. Therefore the GUIs shall have the same look and feel.

Requirement 11: P 8 A new system shall provide a script interface with a full functional script language
A comprehensive script language is necessary for batch jobs, but also to execute predefined scripts interactively. All data elements and functions, i.e. graphics shall be available.

Requirement 12: P 7 All user actions, graphically, command line, or script based, shall be logged
For acquisition and analysis run logging, debugging, and recalling purposes the logging of all user actions is essential.

Requirement 13: P 7 Results of scripts and actions shall be accessible by subsequent scripts and actions
The output of scripts, like fit results, shall be storable in a way that they can be accessed by subsequent scripts, like UNIX pipes, when the result is not a referencable object.

Requirement 14: P 9 The data analysis shall be controlled during execution
More then one execution thread shall be running at a time, e.g. command interface, analysis loop, display, etc.

Requirement 15: P 9 The data analysis shall be able to run interactively or in batch
This is automatically achieved by a sufficient script interface.

Requirement 16: P 5 The GUI shall run on more platforms than the analysis system runs. The user shall be able to add new or correct elements to an existing GUI.
This can be achieved, e.g. by using Java together with Web interfaces. Possible incompatibilities of Java implementations (e.g. Microsoft J++) shall be avoided. The user shall be at least able to tailor the GUI to his needs.

6.3  Data Management

Requirement 17: P 8 The data analysis shall be independent of the input source
A general purpose data interface shall be provided to read events of arbitrary structure. The analysis software shall be independent of the data input, i.e. on-line or off-line, from anything like tape, disk, DAQ, storage, or other analysis.

Requirement 18: P 8 The analysis shall be able to get event input from DAQ servers
The DAQ systems provide various event servers, delivering the event data to various event clients. The new system shall implement individual clients for these servers.

Requirement 19: P 8 A new system shall be able to exchange relevant data with other systems
A new system shall 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, N-tuples for compressed event data, and various ASCII formats. The system shall also provide interfaces to implement the support of other event data formats.

Requirement 20: P 8 A new system shall provide a data management
Organization of data elements, I/O and storage shall be supported by appropriate tools. All parameters of an experiment or analysis run shall be stored in standard data bases. These include set-up parameters of DAQ, calibration parameters, filters, run specifications, etc. The parameters shall be accessible from the analysis software, from scripts, and from the GUI.

Requirement 21: P 8 Data elements shall be multidimensional arrays of aggregates
Histograms and other (user) data elements shall be referenced by names. If many data elements of the same kind exist, it shall be possible to process multidimensional arrays of such elements (name arrays).

Requirement 22: P 8 A new system shall automatically save accumulated data in case of termination
It saves a lot of time (CPU and human) if accumulated or calculated data are not lost in case of abnormal program termination. This is true especially for histograms. A well implemented exception handling will not only keep the data consistent but it will also ease restart procedures.

6.4  Analysis

Requirement 23: P 8 A new system shall provide easy to use programming interfaces to the event data
This means the "classical" user event routine is doing the analysis work, but the data handling is done by the analysis package, "hidden" to the user. This is called "implicit event loop".

Requirement 24: P 7 It shall also be possible to call most parts of the analysis package from user programs
It shall also be possible for a user's program to call routines like "get buffer", "get event", "skip event", etc. In this case the user may control the data flow directly. This is called "explicit event loop".

Requirement 25: P 7 A new system shall provide easy to use programming interfaces to the graphics
There shall be an API to access graphical objects like polygons or scatter plot points.

Requirement 26: P 6 A new system 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 shall be supported.

Requirement 27: P 7 Efficient accumulation of many large matrices, e.g. 4k * 4k long words = 64 MB each shall be provided
The main current problem is the memory limitation for the accumulation of many (50 – 200) large 2-dimensional spectra. It might be necessary to have fast disk accumulation routines.

Requirement 28: P 5 The system shall optionally provide the symmetrical creation of multiple-dimensional spectra
In case of 2-dimensional Gamma-Gamma coincidence spectra often the accumulation of just half of the spectrum is necessary, since it is symmetrical to the diagonal. This would save the use of memory and disk storage.

Requirement 29: P 7 A new system shall provide complex projections in multidimensional data spaces
A mechanism like N-tuples is necessary, but also visualization of complex data and various kinds of filters (conditions). The mechanisms shall be fast and interactively configurable.

Requirement 30: P 8 The propagation of data errors shall be handled correctly
Specifically time dependent event data need detailed error and dead-time handling. Also statistical errors shall be propagated correctly.

Requirement 31: P 8 Other methods besides fit functions needed for the analysis of statistical data shall be provided
Tools for the handling of Gamma spectra (multi peak spectra) shall be provided, e.g. peak finding algorithms, Gamma peak fit algorithms (not just Minuit), user defined fit functions, and background corrections.

Requirement 32: P 5 Connections to a Gamma line data base shall be provided
The analysis of complex Gamma ray spectra shall be supported through data from a Gamma line data base.

Requirement 33: P 5 Interactive graphical analysis of gamma-ray coincidence data shall be provided
Complex, two dimensional Gamma ray spectra need specific graphics tools to ease the analysis.

Requirement 34: P 6 Analysis of time correlations between events (Alpha ray mother-daughter relations) in a time scale of ms to min shall be provided
The analysis of time dependant data, e.g. nuclear decay or cooling effects, need special treatment of data and results. To find long term correlations the data shall be "labeled" with time stamps and sorted in a time dependant way.

Requirement 35: P 6 A sort of trending storage of data, i.e. keeping events in a ring buffer for a given time window shall be provided
This is needed for finding long-term correlations, specifically for the analysis of various decays.

Requirement 36: P 8 The analysis shall have online access to DAQ control functions
Sometimes event data shall be accumulated and analyzed on-line to steer some DAQ hardware set-ups, like stepping motors.

Requirement 37: P 7 Some parts of the analysis shall optionally run online in the frontends
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 shall run in the DAQ front-end. Only a subset of the functionality is needed. The visualization shall also be done on a remote node.

Requirement 38: P 7 The analysis speed shall be equivalent to the data acquisition speed
In many cases the complete on-line analysis of data is essential for controlling an experiment. In such cases the analysis speed may define the dead-time of the whole data acquisition. This requirement depends very much on the processor speed, the code efficiency, the code optimization, and other software and hardware environmental parameters.

6.5  Display

Requirement 39: P 8 The display shall operate independently of the analysis execution
Therefore the system shall be multi-threaded or a high performance data exchange between the histogram and the display tasks shall be available.

Requirement 40: P 9 Scatter plots of all data shall be possible
Therefore again the system shall be multi-threaded. A high performance data exchange between the analysis input and the display shall be available.

Requirement 41: P 8 A simple set-up of scatter plots shall be provided
The definition of scatter plots, i.e. the parameters and conditions defining a scatter plot, shall be simply declared by commands.

Requirement 42: P 8 Color in scatter plots shall be used to distinguish different kinds of points, i.e. conditions or sources
Scatter points could belong to different sources or different conditions (e.g. true/false). This shall be marked by different colors.

Requirement 43: P 6 Scatter plots with several points per event shall be provided

Requirement 44: P 5 Any number of scatter plots shall run in the background
It shall be possible to run several scatter plots simultaneously in the background of a currently visible data display. To fulfill this requirement independently of the X-11 backing store facility, one could think of bit spectra accumulated by the analysis loop.

Requirement 45: P 8 A "real" re-binning of spectra shall be provided, i.e. the transformation from n channels to m channels
An algorithm for the re-binning of data shall be available.

Requirement 46: P 8 The display shall be definable and savable by the user in a simple way
A collection of display objects shall be describable and - combined as a new object - storable and recallable.

Requirement 47: P 6 Mixed pictures with scatter plots and spectra shall be provided
Pictures as a conglomeration of different spectra and scatter plots shall be definable. These pictures can be called as a whole instead of a series of single plots.

Requirement 48: P 6 The display shall generate ready to publish paper prints
The quality of data graphics shall be as high as possible. This would allow the creation of publication ready pictures. Therefore the manipulation of graphic object shall be as extensive but also as simple as possible. As an alternative requirement 50 could be used.

Requirement 49: P 7 Graphic dumps shall contain all details of a representation including data, scales, comments, errors, windows, etc.
Thereby a data representation can be redone and even modified easily at any time.

Requirement 50: P 8 Data links to commercial data analysis and presentation software shall be simple
Data exchange with software packages like Origin, Mathematica, IDL, SATAN/GD (from GSI) shall be possible in a simple way. Such an easy interface would allow further detailed data analysis with commercially available or institute internal software packages.

6.6  Data Acquisition

The base of the data acquisition at GSI will be the Multi-Layer Multi-Branch Data Acquisition System, MBS [Ref. 3]. Nevertheless it shall be possible to use any other data acquisition system in connection with GO4. The following requirements are just extensions to the already existing system and to the parts just under development.

Requirement 51: P 7 The time dependent acquisition of single and multiple data shall be possible
The time dependence of accumulated data (counters, spectra, ...) shall be preserved by the data acquisition system. This feature is important for experiments like beam cooling ESR, laser experiments, production of rare isotopes or elements. The time intervals are normally not equal and the acquired data have a time dependent normalization.

Requirement 52: P 5 Gamma ray input channels shall be sampled by fast flash-ADCs for further detailed analysis (e.g. pile-up) or for storing these data in ring buffers (equidistant in time)
A detailed pulse analysis of certain input channels allow the detection and correction of abnormal situations like pulse pile-up. Thereby the efficiency and the resolution of detector systems can be improved.

Requirement 53: P 8 Setting and controlling of the experimental hardware set-up and accelerator parameters by the data acquisition and/or the real-time data analysis shall be possible
For many experiments (e.g. on the ESR) there shall be a close connection and feedback between the hardware set-up control, the accelerator control, the data acquisition system, and even the data analysis system.

Requirement 54: P 7 A real-time analysis in the data acquisition processor connected with set-up control shall be possible
The analysis of data already in the front-end processor allows the evaluation of early trigger conditions or the reduction of input channels. Feedback mechanisms also need such a fast analysis.

Requirement 55: P 7 Constant fractions, amplifiers, high-voltage supplies etc. shall be set and controlled by the data acquisition
In some cases, the time or temperature drift of the front-end electronics or power supplies can only be corrected after a more detailed analysis of the acquired data.

Requirement 56: P 8 Set-up parameters shall be logged by the data acquisition
The logging of the whole experiment set-up shall be done in a unified manner.

6.7  Constraints

Requirement 57: P 7 Existing software shall be used as a development base
There is no need and no time to develop a new system from scratch.

Requirement 58: P 8 Software common to community shall be used
The preferred programming languages shall be C++ or Java.

Requirement 59: P 7 External software shall be kept unchanged except changes are accepted and implemented by the authors
Good relations to the authors of external software used in GO4 are essential.

Requirement 60: P 7 The required features shall be added to the existing software
Required features shall only be added to existing software packages.

 

Various specifications

Currently no further request categories.

7.1  List of existing software

  1. GOOSY
    GSI On-line Off-line SYstem, GOOSY; http://www-gsi-vms.gsi.de/anal/home.html
  2. IDL
    IDL (Interactive Data Language) developed by Research Systems Inc., Bolder, CO, USA; http://www.rsinc.com
  3. LEA
    LEA LEan Analysis software; http://www-gsi-vms.gsi.de/anal/lea.html
  4. LHC++
    Libraries for HEP Computing - LHC++, Software package for the LHC experiments at CERN Geneva, Swiss; http://wwwinfo.cern.ch/asd/lhc++
  5. MBS
    Multi-Layer Multi-Branch Data Acquisition System MBS; MBS User Manual and MBS Reference Manual; http://www-gsi-vms.gsi.de/daq/home.html
  6. National Instruments
    LabView and BridgeView are software products of National Instruments Corp., Austin, Texas USA; http://www.natinst.com
  7. ROOT
    The ROOT System, NA49 experiment, CERN Geneva, Swiss; http://root.cern.ch
  8.  

8   References

[Ref. 1] ESA Software Engineering Standards, European Space Agency PSS-05-0, Issue 2 February

[Ref. 2] GSI On-line Off-line SYstem, GOOSY; http://www-gsi-vms.gsi.de/anal/home.html

[Ref. 3] Multi-Layer Multi-Branch Data Acquisition System MBS; MBS User Manual and MBS Reference Manual; http://www-gsi-vms.gsi.de/daq/home.html


Downloads-Manuals-References

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.