New GSI Analysis System GO4  

1. Current Status

1. User Interface

LEA provides the same command line user interface as MBS, the standard data acquisition system at GSI. LEA is currently single threaded, i.e. no parallel I/O, display and command execution is possible. That means that I/O is started by commands and one has to wait until it is finished. Then the display menu can be called to look at the histograms. The display menu must be quit to enter line commands.

2. Histogramming

The standard part of the analysis program LEA includes the histogram manager from MBS, i.e. the handling of histograms, like create, show, clear, delete, etc. Histograms cannot be indexed. Histograms can be dumped and retrieved in standard GSI format (gef) to text files and processed by GOOSY, SATANGD or PAW. The histograms are organized in a piece of memory called base. A complete base can be dumped and restored. Currently the base is located in local memory and therefore lost on program exit. (However, an automatic dump on exit can be easily implemented). Additional functionality is in the data I/O, the graphics (peak find and fit) and the calling of user routines.

3. Data I/O

Data input/output is provided online from data acquisition system MBS, and from and to files. There are commands provided to inspect, analyse and copy raw data files formatted according the GSI event data format.

4. Display

Command display starts the display using the IDL graphics. The display is controlled by a GUI. The list of histograms is available. User defined pictures containing several plots can be displayed in the GUI.

IDL Commands

Once the display has been started, one may enter IDL input mode by LEA command display -loop. The prompt changes to idl> and IDL commands can be entered. Histograms can be referenced in IDL.

Callable Graphics

You may execute IDL commands from your routines by calling f_his_idl_exec(string), where string is an IDL command.

Plot Command

Besides the full graphics capabilities histograms can be displayed in LEA by command plot histogram.

Fitting

There is a simple tool for fitting Gauss shaped peaks in histograms. If there are two or more peaks a background can be optionally subtracted. The backround is fitted as polynomial (maximum order 2) to the reagions between the peaks. The peaks are searched. The minimum required distance between a peak and a valley can be adjusted. Fitting can be done in the display menu, by LEA command fit histogram or by LEA command plot histogram .. -fit.

Scatterplots

A display frame for scatter points can be created in the menu or by command scatter. IDL must have been started before. The command specifies the limits and letterings. Then in the analysis routine one may call routine f_his_scat(x,y,c,p) to plot one point in the specified color.

5. Standard Commands

Type Event

The type event command reads events from three input sources, MBS transport, MBS stream server, or file, and prints formatted data. This command works the same as the MBS command.

Type Buffer

The type buffer command is similar to type event but outputs differently formatted events to terminal.

Copy

The Copy event command copies events from the input sources into standard GSI formatted raw data files.

Analyze

The analyze event command gets events from the input sources and calls the user analysis routine. Optionally this routine may return new events, which are then written as GSI formatted raw data files.

Type File

The type file command dumps files similar to the VMS DUMP command.

6. User Analysis Function

The user must write his analysis function f_anal and an initialisation function f_anal_init. Typically both are kept in one file to be able to share variables. In f_anal_init the user also may define his own commands. Histograms are defined in a histogram definition file. From this file a procedure to create the histograms and include files for definition and initialisation are created. Accumulation can be done by macros.

2. Necessary Developments

To overcome the current shortcomings some work would be necessary.

1. Multithread

The program must be runnable in three threads. One for the display, one for the command interface, and one for the current executing command. The main thread does all the initialisation as before, i.e. defines the commands, calls f_anal_init, and executes the initialisation command procedure where the user can create data bases and histograms and execute user commands to initialise his analysis. Then the graphics is started in a second thread. It creates graphic output windows which can be filled in the analysis routine f_anal and the menu window. The main thread now waits for command input. When a command arrives (from terminal or a GUI), the command will execute in a third thread and the interface is immediately ready for commands. Some commands may execute in the main therad, i.e. to stop a running thread. Only one running command thread should be allowed.

2. Graphical User Interface

For convenience a graphical user interface is necessary. It can be written in any method, because it will communicate with LEA through TCP sockets. It would start LEA in the background or on a remote machine where the command prompter then waits for commands from a socket. All actions of the GUI will result in command lines sent to the prompter. Some prototypes of GUIs have already been built for LEA and MBS. One version uses the IDL widget library, the other Java. Java seems to be much more powerful and better suited because of the easy IP handling and the multithread support. There remains the problem that the look & feel of the GUI and the graphics would be slightly different. This problem can only be solved if one finds a package which is suited for GUIs and for graphics.

3. Messaging

One problem of remote execution frontends is to get status changes back into the GUI. In the MBS system this is achieved simply because most of the status information is located in shared memory and can be sent by server tasks to a GUI thread which can update the widgets. All messages generated by MBS pass one central task which again can send them to a GUI thread.

The whole multitasking system of MBS could be ported to other platforms like Linux. Then LEA could use the same mechanisms because it is written as an MBS task.

As an alternative one could implement feedback mechanisms exactly addressing the requirements of LEA.

4. Other GUIs including Graphics

To achieve a more uniform outlook it should be investigated if there are packages on the market providing good GUI building and graphics. It would be extremely nice, if that software would be PD. Candidates could be tcl/tk or free Java packages providing the graphics. The latter seems to be the most promising way, especially because the GUI for MBS is under way written in Java. This would allow for a uniform interface for MBS and LEA.

5. LEA running inside MBS

It can be very useful to run an analysis directly in MBS. This includes the possibility to filter events by software as well as to execute control functions as a result of event analysis. MBS already provides this functionality. Because LEA has been derived from MBS, it is only necessary to port it back. In MBS there is already a histogram server sending histograms on request to clients. The LEA display must get an interface to this server to access remote histograms.

6. More Functionality.

3. Conclusions

LEA could be serve as a small, easy to use analysis tool, well integrated in the MBS data acquisition system. It can run inside MBS, or on other Unix machines either online or offline. There could be a uniform GUI for both, MBS and LEA.

1. Remaining Restrictions

• It will be not possible to have indexed histograms.

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.