Tracker data quality monitoring based on event display

M.S.Mennea,G. Zito
Bari Cms Tracker Visualization Group
Presentation done at the Software meeting on "On-line Event Display and Monitoring" Tuesday 26 April 2005
The problem is that of presenting large amounts of information in a way that is compact, accurate, adequate for the purpose, and easy to understand. Specifically, to show cause and effect, to insure that the proper comparisons are made, and to achieve the (valid) goals that are desired.
Graphics and Web Design Based on Edward Tufte's Principles

The tracker map

Possible use of tracker map for monitoring in the control room

Possible use of the tracker map to give fast information to experts outside the control room

The same image has the following interesting feature that makes it useful for another purpose: it can summarize the information content of hundreds of events or thousands of histograms and as such, is the quickest way to inform experts eveywhere in the world, without any special Internet connection, about the tracker situation.

This has been tested with a Java program i.e. the computer where the expert sits, has no CMS software running on it, but only this Java program. In a few minutes the programs connects to a data server in the control room and informs the expert ,using this image, about the situation in the control room regarding the tracker. Here again the expert can use the interactive features to diagnose the cause of a problem.

Sending an interactive image in SVG+Javascript from the control room

We are also,right now, testing another interesting variation of the previous scenario. Instead of sending the information to the expert as data for a Java program, we can send directly the tracker map in SVG format with the interactive features implemented in Javascript.

Here again the results are promising: in a few minutes you can get the image using a normal browser with the Adobe SVG plugin.

We are now working on the best way to update the image with new data.

(An alternative to this approach is the technique used by Google Maps where image chunks are sent.).

Monitoring in a specialized Tier2 centre and sending a fast feedback in the control room using this tracker map.

In the control room we have of course access to all raw data, but the computing resources my be scarce. So why not to ship a sizeable amount of tracker raw data: at least 10% steadily through an high bandwidth connection to a specialized Tier2 center (a Tier2 should have enough resources). This center can analyze the data as they arrive on a cluster of many computer in parallel doing a quasi-online monitoring and sending back to the control room the result of this analysis summarized as a tracker map so the operator has also this further check of tracker data quality.

How to access tracker data relevant for monitoring

In order to have this high level user interface to monitoring data working , fast and standard access to all data relevant to tracker monitoring is essential. Fast because the map needs data for all the detector , standard since we don't want to use a different api for each data source. And we have many possible data sources:
  1. Online raw data
  2. Raw data stored on dataset on the Grid
  3. the construction database
  4. the conditions data base
  5. the histogram database
  6. other ...
The solution found is to access these data sources using Web services. We have defined a unique data format (in xml) for tracker data. When the tracker map needs new data it has only to build the URL addressing the relevant Web service and the data is sent back in this format. The access to the data source itself using the appropriate api is done by the data server implementing the Web service itself. This means:
  1. we must have a data server for each data source
  2. each monitoring data chunk must have a unique URL
. (This is exactly how Google Maps works: in this case the data chunks are parts of the map at different resolutions, paths between two adresses, etc). We have tested this scheme and seems to work without problems. A Web service implemented in Axis+Tomcat is also very efficient in handling the data since it has automatic caching. This feature can be of much help to us since for most of the data the access is sequential and/or the data changes slowly.

What to represent with this map

(Here are some random ideas).

Present status

What we have now in Iguanacms

Iguanacms is a generic display for CMS data. We have added a "CustomTracker" part with three main features that can be useful for tracker monitoring.
  1. Numbering of each tracker module. So, when you click on a module, you know for example that it is the third stereo module in the second ring of Tib1.
  2. Easy way to select each detector part down to the module level. Stereo pair modules can be selected separately.
  3. A first implementation of the tracker map.Represents all 17000 tracker modules with the following schema. This map cannot be zoomed (it is intended to be shown in a single computer screen). Instead if you want to go to the level of the single channel, you have to select a single layer . The layer will be zoomable in future and can represent the information down to the level of the single channel.

Example of use to study a single stereo module behaviour.

Iguanacms runs on lxplus but is too slow there. You have to install it on your desktop with a suitable graphics card. This is now relatively easy using XCMSI ( a few hours needed if no problems).
We didn't introduce any change from the previous version. Our main task now is to support this "CustomTracker" part through new releases of Iguana/Iguanacms. A first use of CustomTracker has been to check the tracker description in the DDD. This can give an idea on how "CustomTracker" can be used to debug tracker software and hardware.

Light visualisation implementation

Built a prototype (Java program named Tmon) that implements the same tracker map that we have in Iguanacms.Tested by using web services implemented with Tomcat+ Axis+Castor. Set up a specialized Tomcat server running all the time since June to do our tests. For example tracker description in xml provided by the server.
The tests were done with data taken from construction database and from Montecarlo events dataset.
Example of Montecarlo event(around 100000 rec hits overlayed view) represented by Tmon.Same event but separated mode view.
Results encouraging:we can read and display the data in the tracker in around 10 seconds.The same time is needed to load the xml tracker description.
N.B. We don't use directly the DDD : this is too complex for our purposes and also incomplete. We use a simpler tracker description with the data extracted (once for all) from the DDD and saved in a single XML file. The table below gives some examples of response time with events of different sizes.(We don't do any optimization, compressing, etc or use any trick to decrease this time).

# rechits in eventxml file size(MB)response time(sec)
66001.03
100001.64
36000610
860001421
1000001625

The code of the Java client is available online. It can be used for doing tests but is REALLY a prototype!

SVG image+Javascript : first tests.

Tracker map with overlayed modules and with separated modules (to see these you must have the Adobe SVG plugin installed). In addition to the normal interactivity of SVG images (zoom and panning) we added through Javascript functions:

Work to be done

Requirements for online monitoring software
Pagina curata da Giuseppe Zito: zito@ba.infn.it
ultimo aggiornamento: