Tracker Iguana-based monitoring and visualization
Future plans
Our goal
We would like to have at the beginning of CMS data taking:
-
Iguanacms running in the control room as a general purpose event display
to look at the last event read and cross-check tracker data with other
detector's data.
- Iguanacms should have an "accumulate events " option to make a fast check
for hot spots or holes.
- A specialized representation of the tracker (tracker map) should
run all the time on computer screens and be constantly updated.
This will allow a fast overall check and an additional cross-check of "normal"
automatic monitoring procedures that send alarms in case of problems.
This can also be used to summarize the information of the thousands of histograms needed to monitor the tracker and can make more easy the access to these.
- This tracker map should run both in the control room in Iguanacms
and on Internet by using a light client (Java program or Web browser
). The Internet connection should allow to reach the experts everywhere and give feedback on the control room situation in a reasonable time(a few
minutes).
- To make more easy the task of providing the data for IGUANACMS and this tracker map it would
be advisable but not necessary to define a unique and standard interface to
all information needed for tracker monitoring:
- construction data base
- DDD
- conditions data base
- events
- histograms
- ...
By unique we intend that you don't have to learn a new API for each item,
by standard we intend web services protocols
Tracker map : going to the level of the single channel
We would like to see if this tracker map,that can be thought as a scatter plot with an entry for each module,can be zoomed in order to represent the single channels and what kind of information we could show at this level.
At this level it should be possible to check for example the position of the
signal with the position of faulty channels. At this level of detail we can introduce many different representations of informations: for example drawing fired strips ,writing the value of the information represented,... A popup menu' should allow the
user to tailor the representation to his needs.At the module level it should be possible also
to look directly at normal histograms using this map only as a convenient way
to access the relevant histograms (you click on the module and get all module's
histograms).
Possible uses of the tracker map
- Display event in tracker.
- Display last few events accumulated
- Display temperatures,voltages and other data from conditions data base.
- Display dead strips and other data from construction database.
- Display result of global check of tracker by comparing last module
histogram with reference histogram
- ...
Present status
What we have now in Iguanacms 1.10.0
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.
- 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.
- Easy way to select each detector part down to the module level. Stereo
pair modules can be selected separately.
- 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 event | xml file size(MB) | response time(sec)
|
| 6600 | 1.0 | 3
|
| 10000 | 1.6 | 4
|
| 36000 | 6 | 10
|
| 86000 | 14 | 21
|
| 100000 | 16 | 25
|
In the future we would like to check also if it is possible to replace
this Java client with a web browser with the Adobe SVG plugin.
Instead of sending the event we send directly the tracker map in SVG.
The code of the Java client is available online.
It can be used for doing tests but is REALLY a prototype!
Conclusion
- Tracker map and other features that can be useful in monitoring already available in "CustomTracker" part of Iguanacms. Try them and let us know what you think.
We will support them and (slowly) modify them following your suggestions.
- Prototype of light visualisation client developed to test access of monitoring
data from Internet.We have spent a few months implementing it (steep learning curve) but now we
can proceed more quickly doing other tests and trying to consolidate the code.
If everything OK , a first possible use can be as a graphics interface
to the Construction Database.
- Concerning this light visualisation client: we have used well known technologies and the results are promising. Should we start exploring the use of the new
Grid technologies(Clarens,gLite,Monalisa,...).My opinion is no: let's first
wait for the dust to settle. Web services as used here are more than enough
for our needs( we have very few internet users and can drastically limit the amount
of data to be sent out of the control room by using the tracker map).Instead an interesting option to explore is maybe the use of ROOT for both
local and remote data analysis for monitoring.
- What we
are trying to do is a kind of high level monitoring that will require
all the low level monitoring working to be of use. For this reason it is
not
urgent matter but it must be working in the control room by start of data
taking. So I don't see any problem developing this kind of monitoring
since we have most of the pieces already working . This kind of high level
monitoring (essentially one or more tracker maps updated all the time
and showing on a screen in the control room that complements "normal"
monitoring with histograms and automatic checks) could be made a lot
easier if we develop a standard interface (of the web service type or
other(Clarens?)) to all data and services necessary for monitoring.
This kind of interface would make more easy the access to data from
both Iguanacms and the light client.
More details in our tracker visualisation page.
Pagina curata da Giuseppe Zito: zito@ba.infn.it
ultimo aggiornamento:
