New GSI Analysis System GO4
Lean Analysis LEA v1.2
LEA has been developed at GSI for analysis of accelerator beam in the framework of the therapy project. It turned out to be a multi purpose, versatile and easy to use analysis tool which may be useful for small experiments. LEA runs currently under OpenVMS, AIX.,and Linux. Other Unix platforms could be supported in the future. The visualisation is done by IDL (Interactive Data Language) developed by Research Systems Inc.. A developer license is required. The software is written entirely in C.1. Current Status
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.
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.
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.
Commanddisplay 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.
Once the display has been started, one may enter IDL input mode by LEA commanddisplay -loop. The prompt changes to idl> and IDL commands can be entered. Histograms can be referenced in IDL.
You may execute IDL commands from your routines by callingf_his_idl_exec(string), where string is an IDL command.
Besides the full graphics capabilities histograms can be displayed in LEA by commandplot histogram.
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 commandfit histogram or by LEA command plot histogram .. -fit.
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.
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.
The type buffer command is similar to type event but outputs differently formatted events to terminal.
The Copy event command copies events from the input sources into standard GSI formatted raw data files.
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.
The type file command dumps files similar to the VMS DUMP command.
The user must write his analysis functionf_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.
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, callsf_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.
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.
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.
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.
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.
Besides the modifications to the LEA kernel and the GUI, there are some other features currently missing which might be necessary even for small analysis tasks.
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.
GSI Helmholtzzentrum für Schwerionenforschung, GSI