Presentation done by Giuseppe Zito to the CMS WORKSHOP ON
b/tau PHYSICS
held in Bari 28.05 - 01.06 2004
Introduction
The main use of Iguanacms for monitoring will be as an event display. Looking
at the last events taken is one of the best ways to check that everything is ok.
Taking for granted this use of Iguanacms, I will speak here about using it
as something completely new: as a monitoring data display.
Tracker Visualisation: a nightmare
Too many data : 17K modules, 50M channels(strips+pixels), ...
The detector is like a russian doll with around ten cylinders one inside the other.
Overlapping between nearby modules. In stereo pair we have a module
on top of the other.
Step 3 Take care of module overlapping and stereo pairs by
slightly moving the modules and by representing each module in a stereo
pair with a triangle.Endcap layer, barrel layer
Step 4 Assign to each flattened layer a different place that
keeps nearby layers which are near in space.
The tracker map
The final result with:
overlayed, separated modules. This is a 1360x2800 image that can be saved on disk(ps format) or printed without
losing information on a A1 sheet.To see this image now you need to scroll it
but you can assume that in the control room we can afford a high resolution monitor that shows the complete image(in landscape format).(On my 21" monitor the maximum resolution is already 1920x1440)
This image is a kind of map of the tracker where you can display any
information concerning the tracker.
The simplest way to use it is to display the last few events overlayed:this will show immediately if there are holes or hot spots. The same display can be done plotting the signal in their position as a set of points(in this case the simhits).
Other information that can be shown at this level: dead/busy strips, temperatures,results of periodic checks on all modules(for example comparison with a reference histogram for each module)...
Possible use of the tracker map in control room
Big problems will be checked by computer programs that give alarms ...
If no alarms, one or more displays with this map running all the time and constantly
updated give the operator a feeling that everything is ok.
Can help in early spotting of problems.
(For example temperatures slowly raising in some part of the detector,
pedestals changing,..)
In case of alarms the same map can localize immediately the position and
number of faulty modules and help in the diagnosis by allowing fast access
to more detailed monitoring information...
Going to the level of the single channel
The tracker map needs some optimization.Your help for this is essential.
There are some parts where the modules are not seen clearly. Using a triangle
for stereo modules is the best solution?Which color is best?
Anyhow it can be thought as a scatter plot with an entry for each module.
Up to now we have not implemented a zoom of this map
(and we don't know if this is necessary). Instead if you want to go to the
level of the single channel, you have to select a single layer:endcap;
barrel
. The layer will be zoomable in future and can represent the information down to the level of the single channel.
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' (not yet available) 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).
Accessing non event data in Iguanacms
We are implementing this software in Iguanacms integrating it with the normal
3D/2D event display. The tracker map is only one of the ways of representing the event. So you can compare the 2D view with the 3D view.
My suggestion is that some monitoring data(non event data) could be feeded to Iguanacms presenting this
data with the same format of event data: like "fake events".
So you can think of a fake event with dead strips, another with
temperatures , etc Also it is necessary to access histograms.
Perhaps we can implement one or more data servers that could read the monitoring data from sensors and/or database and format them as event data.
And now ,out of the control room, in a Internet Cafe somewhere in the world...
The same 2D representation produced by a light Java client.
Light since it knows nothing about Cms software and hardware,
it only implements the Gui. When this program needs the tracker description
and the data to display, it sends the request to data servers
using normal URI.
The data is transferred with XML+SOAP+WDSL : i.e. using Web services
protocol.
We are working on this but we plan to have for Chep04 a working prototype.
By now I can show you the schema of the tracker description and the full tracker description in xml The program accepts any detector description that follows the schema:
so it can be used also for test beam and to follow the construction tests.
I have used Castor to automatically generate the Java classes implementing
the tracker model. The data server is created using Axis+Tomcat.
We are planning to use the data in the Construction DB for a first test and
then try with normal events.Data from the construction DB will be presented
as "fake events". The events themselves are described by a schema and should
travel in xml(!?).
Web Services in the control room?
(I don't know if what I say here makes sense:anyhow ...) Perhaps implementing web services
access for monitoring is not our biggest priority, but I think that the
"Web services approach" can be very helpful in planning the detector
monitoring services.
This means ,in my opinion, the following:
each quantity to be monitored should have a unique URI .This should
apply to any resource and also to collections of resources(events, etc).
We define our interface to the monitoring resources as a web api.
This approach should have the following benefits:
client software completely decoupled from implementation. It has
only to know the adress of the resource. The resource itself will be made available by
"servers" that can change in time and use different techniques of
providing the resource(for example: with or without database,
with different database systems)
the same client software could work in the counting room and remotely on
the Web.
we can exploit the possibily offered by web services (and grid
services) to access distributed resources and to scale as we need
more computing power or other resources.
Conclusion
Tracker map already available in Iguanacms.Need feedback to improve it and
also to understand what are the priorities.
If the online group is interested in this use of the tracker map, we have
also to add to IguanaCms the access to monitoring information different
from events.
By formatting some of these monitoring data as "fake events" we can
transform Iguanacms from event display to monitoring display(for example have
a 3D representation of all temperature sensors).
Basic idea of tracker map :represent all subdetector parts in a single scatter plot.
Can be used by other subdetectors but need to be tailored to each subdetector's
needs.Anyhow I have tried to translate the trackermap features to software requirements specifications for online monitoring.
Question: there is
any other way to use Iguanacms (or perhaps only Iguana) in monitoring?
For example, the Iguana capability to store 3D objects in iv files, can be
useful for monitoring purposes? Should we integrate a histogram viewer inside
Iguanacms?
Tracker map is being implemented also in a Java program to check the
possibility to access monitoring data outside the control room via web
services.Working prototype and results of tests in 3 months.
I hope this presentation has shown how useful a tracker map can be in monitoring : of course this is low priority and in any case we have to wait for most
of the basic infrastructure to be working before such an application can start to
be developed. We may decide to wait the end of 2006 before we take a decision
on what, where and when. Another possibility that I see is to decide right
now to integrate IGUANA and or IGUANACMS in COSINE to be run on the Filter Farm and wait until 2006
to decide how to connect it to the monitoring data. The last possibility is that
we consider a tracker map to be a priority for our monitoring defining right now all the details.
