14th ieee-npss real time conference 2005, 8 june stockholm

20
14th IEEE-NPSS Real Time Conference 2005, 8 June Sto ckholm

Upload: calvin-park

Post on 11-Jan-2016

218 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

Page 2: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 2

Why SVG SVG (Scalable Vector Graphics) W3C specification is slowly becoming a standard way to show graphically information on the Web in 2D. SVG is already being used in visualisation tools to export 2D graphics.

Online geographical maps show how sending a SVG file plus some Javascript code may allow an user with a SVG enabled browser to display and interact with the information sent in many ways:

SVG images can be zoomed and panned exactly like a postscript images.

Have the possibility to pick a part of the image getting information about part represented in the detail.

Have the possibility to connect the image to web services that will provide new data refreshing the image.

Page 3: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 3

CMS Tracker

16540 modules

more than 100 people from 10 labs distributed worldwide

the availability of the Grid computing environment

Data taking will start in 2007

more than 50millions of electronic channels

Page 4: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 4

Our approach (1)Is possible to monitor a complex HEP detector like CMS tracker from the Web? (i.e. from a Internet cafe' in Mumbai)

We have experimented with two recipes:

Recipe 1:

SVGDetector MapWeb Services

Recipe 2:

Java ClientDetector MapWeb Services

Recipe 2 is described in the following paper:

[1] “Monitoring CMS Tracker construction and data quality using a grid/wes service based on a visualization tool “– Maria S.Mennea, A. Regano, G. Zito - Proceedings of IEEE Nuclear Science Symposium, Roma 2004

We describe here Recipe 1

- Web services implementation is the same in both. You can find the details in [1] - At the end of this presentation we compare the two recipes.

Page 5: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 5

Our approach (2) To implement the recipe:

we have already developed a detector map of the tracker in CMS visualization software

send this map and data coming from control room in SVG to the client

the expert uses this map to know if the detector is ok. In case of problems the expert by using the SVG interface of the detector map requests other monitoring data made available by web services

SVG

Computers running CMS display software in the control room create and update constantly an image to show how the tracker is behaving (tracker map)

The image is saved every few seconds in SVG format on a disk seen by a web server

Experts everywhere in the world can look at the image on their computer without any special software and request additional data provided by web services

Page 6: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 6

Web access to monitoring data - Should be provided by web services

- requires access to the following data sources: last events read from detector

construction data base

(single database containing for example list of dead channels in the

module)

DDD (Detector Description Database - description of detector geometry)

conditions data base (working conditions for each module: voltages, temperature, etc)

events from a Grid dataset

histograms data base

Page 7: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 7

The tracker map (1)Why a detector map?

In the past the main visualization tool for monitoring was a histogram presenter that would show a set of histograms and tables updated regularly.

The CMS tracker has more than 50 millions channels organized in 16540 modules each one being a complete detector. Its monitoring requires many thousands of histograms to be computed every few minutes.

An histogram presenter is not enough: people in charge for monitoring need a representation that would show all modules at once in a single computer screen with single modules information coded in some way. This (“tracker map”) is the representation implemented in the SVG image.

Page 8: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 8

This "tracker map" is obtained disassembling the whole tracker and assembling it again on a flat surface putting the single modules in

positions which are connected to their spatial position.

The tracker map (2)How to build a detector map!

Page 9: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 9

The tracker map (3)How to use a detector map

Integrated signal from 50 events

Page 10: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 10

The tracker map (4)Advantages of a detector map

1. Data from each one of the data sources seen before can be represented on the map. For example the single module can show coded with a colour:

number of dead channels from construction database

total number of rechits hitting the module in the last 100 events readout

result of a comparison between the last histogram and a control histogram 2. Holes or hot spots in the map can pinpoint detector problems.

3. May be used to request more data by using its interactive interface

and the possibility to zoom

4. In this use for Web monitoring, the map has the additional advantage of minimizing data transfer. You don't have to transfer 50 events but only a single image!

Page 11: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 11

Implementation: System Architecture

we must have a data server for each data source each monitoring data chunk must have a unique URL

Page 12: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 12

Implementation: the SVG map interface

When the user requests data to the service, the first time he gets an SVG image of the tracker containing Javascript code. This image is built using the geometrical data of the detector and can be of two different types:

Tracker map with overlayed modules

Tracker map with separated modules

In addition to the normal interactivity of SVG images (zoom and panning) we added through Javascript functions:

The thumbnail at bottom left makes more

easy the panning since it allows the selection with the mouse of the zone to view.

Special buttons are present to zoom in, zoom out and return to initial image.

When you move the mouse on the image you get information about which tracker part you are.

web_link

web_link

Page 13: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 13

Implementation: the SVG map interfaceTracker map with overlayed modules

Page 14: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 14

Implementation: the SVG map interface

When the user requests data to the service, the first time he gets an SVG image of the tracker containing Javascript code. This image is built using the geometrical data of the detector and can be of two different types: Tracker map with overlayed

modules

Tracker map with separated modules

In addition to the normal interactivity of SVG images (zoom and panning) we added through Javascript functions:

The thumbnail at bottom left makes more

easy the panning since it allows the selection with the mouse of the zone to view.

Special buttons are present to zoom in, zoom out and return to initial image.

When you move the mouse on the image you get information about which tracker part you are.

web_link

web_link

Page 15: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 15

Implementation: the SVG map interfaceTracker map with separated modules

Page 16: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 16

Implementation: the SVG map interface

When the user requests data to the service, the first time he gets an SVG image of the tracker containing Javascript code. This image is built using the geometrical data of the detector and can be of two different types: Tracker map with overlayed

modules

Tracker map with separated modules

In addition to the normal interactivity of SVG images (zoom and panning) we added through Javascript functions:

The thumbnail at bottom left makes more

easy the panning since it allows the selection with the mouse of the zone to view.

Special buttons are present to zoom in, zoom out and return to initial image.

When you move the mouse on the image you get information about which tracker part you are.

web_link

web_link

Page 17: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 17

Implementation: real time update of the map

Further requests of data are done using Javascript

different API for Adobe plugin and browser with native support (Mozilla / Firefox)

tests were done using a Adobe plugin

access to data not yet implemented in the SVG interface: the tests were done by using some temporary code

the Adobe API uses the geturl function to request data. If the XML file is successfully received, we use the parseXML function to parse the file attaching it to the DOM document containing the SVG map. Then we can traverse the tree updating the SVG with the new data

in the Mozilla API the XMLHttpRequest object is used to contact the remote server. It has many methods that allow to contact the data server, to receive the data asynchronously and to extract them directly from the document's DOM tree (no need to do parsing).

Page 18: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 18

Performance (1)

PC test PENTIUM IV CPU

Operating System LinuxSVG Plugin 3.01

WindowsSVG Plugin 3.02

SVG map file size 3MB

Number of nodes in the DOM tree

100,000

Response Time 20 sec

Real time update too slow7 min - Linux 5 min - Windows

For this reason it is a lot faster to send new data directly in SVG format

and update the SVG image by loading a new one which replaces

completely the previous image (because this only requires 20 seconds).

Page 19: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 19

Performance (2)

Does this limit the use of SVG in our application? Not necessarily but you need to develop an interface that minimizes the number of operations on the SVG image tree.

To get more detail:

have a special area reserved for such detailed zoom

when one requests it by clicking on a module only the data about the module is sent by the server and displayed by updating the content of this window

this zoom area can also be used to represent others types of information like histograms.

Page 20: 14th IEEE-NPSS Real Time Conference 2005, 8 June Stockholm

14th IEEE-NPSS Real Time Conference, 8 June Stockholm 20

Conclusion

COMPARISON OF THE PERFORMANCES BETWEEN SVG AND JAVA CLIENT

SVG Java client

Real time update 5 min 10 sec

Software developmentvery easy (software mostly copied from the web)

difficult

Requirement for the user

Plugin installation Java runtime installation and java client download

Graphics performance very good sufficient

Interactivity sufficient sufficient

No clear winner

The results show that monitoring a detector like CMS tracker from

Internet should be feasible but with some limitations due to poor

performance of Javascript in the browser.