An Event Display for ATLAS H8 Pixel Test Beam Data
Centre de Physique des Particules de Marseille and University of Illinois
April 17, 1999
An event display program is now available for use with H8 test beam pixel data. The program is intended more as a data viewer than anything else, and is meant to allow physicists on shift to notice sudden changes in the data coming from the silicon strip telescope and pixel detectors. The event display can be launched by the data acquisition program, and is then controlled separately by users on shift through a mouse-driven interface. There is a pdf version of this document available.
You can jump directly to descriptions of:
Here is how a typical 1998 test beam event looks.
Figure 1. A typical event, from run 4275 (September, 1998).
The display screen can be resized in the usual way by dragging its boundaries, but you may need to click on the screen to refresh the window.
The screen is divided into four principal areas: x-view and y-view representations of the telescope are drawn above a row of control buttons; a message area is drawn below.
Hits in the strip and pixel detectors are drawn as blue lines whose length is proportional to the ADC signal from each strip, or time-over-threshold from struck pixels. Strips (or pixels) which have been identified as noisy will have their tick marks drawn in red. To zoom in on part of the telescope, left-click on the Zoom control button, then left-click twice on one of the telescope drawings as shown in Figure 2.
Figure 2. Defining a zoom area.
If the zoom area is small enough, strip hits are labeled strip-number:ADC-value, while struck pixels are labeled column,row:time-over-threshold, as shown in Figure 3.
Figure 3. After zooming.
Right-click on the zoom button to reset the zoom area.
The phi, psi, theta angles indicated in some of the buttons may be changed by clicking on the buttons. These are not Euler angles: phi corresponds to rotations around the lab frame y axis, psi around the lab frame x axis, and theta around the z axis. You can use these to reorient the pixel planes in order to better view the hit information. The angles are reset each time a new event is loaded.
The area in which detector and hit details will be drawn are indicated by marks near the corners of the x and y plots. The H8 frame (z,x) and (z,y) coordinate values of the marks are shown in millimeters.
Clicking once in the x-view (or y-view plot) causes the program to write the H8 coordinates of the click (also in millimeters) in the message area.
...back to the beginning
Interaction with the Data Acquisition Program
The event display program is launched by the data acquisition software after a request by a user. The program may be launched with a string of (optional) arguments which specify the IP address of the display, whether the job is running at CERN or not, and the x, y alignment constants of the last three strip planes and the pixel detectors. A positive value for an alignment constant indicates that the center of the detector is displaced in the positive direction with respect to the center of the first strip plane. Since the first strip plane is used to define the coordinate system, its alignment constants are zero, by definition, and ARE NOT entered as arguments to the program. As with PAW, an exclamation point (!) informs the program that it should use the default value of an argument.
The job generates no "printer output" when it runs normally, but will try to write a small amount of diagnostic information to standard output if it runs into problems. It probably makes sense to redirect standard output to a file.
The Unix command
nohup event_display.exe_cern marrant.in2p3.fr:0.0 CERN 2.626 -.645 \
1.630 3.196 ! 3.774 .710 1.970 > event_display.log &
will launch the program with the following arguments:
|DISPLAY IP address||marrant.in2p3.fr:0.0|
|Strip plane 2 x offset (mm)||2.626|
|Strip plane 2 y offset (mm)||-.645|
|Strip plane 3 x offset (mm)||1.630|
|Strip plane 3 y offset (mm)||3.196|
|Strip plane 4 x offset (mm)||! (use default value of zero)|
|Strip plane 4 y offset (mm)||3.774|
|Pixel demo 1 x offset (mm)||.710|
|Pixel demo 1 y offset (mm)||1.970|
|Pixel demo 2 x offset (mm)||(not specified; use default of zero).|
|Pixel demo 2 y offset (mm)||(not specified; use default of zero).|
|Marebo x offset (mm)||(not specified; use default of zero).|
|Marebo y offset (mm)||(not specified; use default of zero).|
|Module x offset (mm)||(not specified; use default of zero).|
|Module y offset (mm)||(not specified; use default of zero).|
Any diagnostic information written to standard output by the program will be redirected to the file event_display.log.
Handshaking between the DAQ and event display routines is simple: upon launch, the event display creates a control file named /PixData/event_display, and then looks for data from a single event in the file /PixData/event_dump. If /PixData/event_dump doesnít exist, the event display waits for it to be created, repeatedly checking for the file roughly once per second. After reading the eventís data, the display program deletes the file. When the user clicks the "Next event" button the display program opens (or waits for) another event_dump file.
The DAQ can signal the event display to stop by deleting the control file. Because of some fine points concerning the queuing of mouse events, this is the only graceful way to stop the event display while it is waiting for event data. At other times, the event display can also be stopped by double-clicking on its STOP button.
The DAQ creates /PixData/event_dump if it detects the existence of the control file /PixData/event_display and sees that the event_dump file does not exist. The first line in the control file /PixData/event_display contains a number used by the DAQ to determine how many events to skip before creating a new event_dump file. A value of 1 indicates that the DAQ should create the file using the next available event.
When asked to stop, the event display program deletes /PixData/event_display and (if it exists) /PixData/event_dump.
...back to the beginning
The event display program is written in Fortran. Here is a list of the routines, along with the descriptive comments at the start of each routine. Links to the "include files" for common blocks and the Makefiles follow the routine descriptions.
Makefile for compiling fortran and linking object modules on Mardigra (a CPPM machine), and then to create an executable to be run on Mardigra.
Makefile for compiling fortran on Mardigra, but to create object modules which will be used on Mardaq2 (which does not have a fortran compiler)
Makefile for linking object modules on Mardaq2 which had been created on Mardigra....back to the beginning