SEDUX: Simple Event Display Using Xslt

A simple SVG event display for the Atlas experiment at CERN


Abstract


The Atlas detector [1] at CERN is due to start taking collision data at the Large Hadron Collider in 2008. The inner detector of that experiment is used to provide tracking information, and is conventionally displayed in a Java™ application which allows full navigation of each event, however there is a need for lightweight application which allows one to quickly display tracking information event by event.

The author has developed a simple one-step XSLT transform which allows one to display the event information (in XML) as an SVG graphic directly in web browser, without downloading additional software, or alternatively allows one to thumb through event displays in a given directory by inserting the appropriate XSLT , CSS and SVG files in that directory. To accommodate the display of cylindrical geometry in existing browsers, trigonometric functions were written entirely in XSLT 1.0 as series expansions. Pan and Zoom of the display are accomplished by the injection of javascript from the XSLT. Example displays taken with real data from cosmic rays are presented, deriving from the commissioning tests for the inner detector in 2006 [2]. Future plans to incorporate status information about the detector from an environmental database are described


Table of Contents

Introduction
Aims and Constraints
Primary Data Sources
Detector Geometry Description
The Event File
Processing the Input Files
Preparing the Geometry File
The Event Data Transform
Zoom and Pan Functionality
Extensions to the Concept
A Purely Web Based Display
Endcap Display
Future Plans
Conclusion
References

In 2008 the Large Hadron Collider (LHC) will commence operation at CERN, colliding proton beams at 14TeV in the centre of mass frame and enabling physicists to probe many unanswered questions in our understanding of matter and the origins of the universe. The Atlas detector is the largest of four detectors on the 27km LHC ring, at 45m length and 25m height.

The Atlas detector consists of several subdetectors as shown in Figure. 1, which perform different functions: calorimeters provide precise energy information about particles originating from collisions, whereas the trackers provide precise position information. The tracker also allows one to infer the particles' momenta, as they bend in the magnetic field which permeates the detector.


The application described in this paper specifically presents a tracking display for the inner detector, which is shown in greater detail in Figure. 2. This consists of a pixel detector, silicon microstrip detector (SCT) and transition radiation straw detector (TRT). A particle traversing these detectors ionizes the medium (silicon for pixel and SCT, xenon and carbon dioxide gas for the TRT) and the charge is collected on an electrode and subsequently amplified to provide a 'hit'. The hits are combined with geometrical information to give space points which trace the particle's trajectory.


During 2006 and until the present day, the inner detector has been tested by reading out tracks caused by cosmic rays traversing the detector. An existing Java™ application for displaying the events, Atlantis [1], is a full featured event navigator with functions for revealing the different physics behind a given collision event; however its interface reflects this functional complexity and a number of users expressed the need for a simpler event display for use during detector commissioning. Atlantis uses an XML representation of events as its input (so-called JiveXml files), and the author decided to leverage this standard to provide an SVG representation of events via XSLT, providing a web display for JiveXml files with no intermediate software other than a web browser. The interface is kept deliberately simple, providing only zoom and pan functions on the event. Building on the event format and geometrical description provided by the Atlantis developers in XML form, the author developed a Simple Event Display Using Xslt, SEDUX.

The computing environment in the Atlas experiment is based on GNU/Linux and a variety of open-source software in several languages (principally C++, python and Java™). In a 2007 survey of operating systems and web browsers conducted on one of our main TWiki pages [4], almost 93% of users were using an natively SVG-capable browser (see below) with an in-built XSLT engine. The application described here is thus targeted at a user base of Firefox and Safari browsers and should provide an accurate representation of the r-Φ view of a cosmic ray event in under 10s of rendering time i.e. somewhat less time than it would take the Atlantis program to launch and the user to select and open the same file.


The data sources for building a static event display consist of:

  1. Detector geometry description

  2. Event description

  3. Geometry interpretation

Of these, the first two are available in file format but the last, the interpretation, is not uniformly well documented and finally this knowledge is in fact embedded in the program or XSL transform which creates the graphic representation.

The coordinate system used throughout is shown in Figure 2.

The geometry description file is in XML format and distributed with each Atlantis release as a package in the official Athena analysis code, in CVS. The geometry file in turn derives from the Atlas geometry database, GeoModel [5]. This relational database stores an idealized as-designed geometry for the detector. The misalignments and detailed geometrical deviations which arose during construction are also in this database and are applied as corrections to the primary numbers when performing real data analysis and comparative Monte-Carlo simulation. For display purposes, however, the design numbers are sufficient and allow one to take advantage of the intrinsic rotational symmetry of the detector to simplify the code.

The geometry XML file (AGeometry.xml) is distributed with an in-file DTD for validation, but the essential features of the file format are best represented by the examples below for a pixel layer, SCT layer and TRT layer.

 
<AGeometry>
<ABarrelSiliconDetector c="PIX" n="Pixel" layer="0" length="6.08" width="1.64" thickness="0.306424" tilt="-19.9962" nz="13" nphi="22" r0="5.10491" phi0="7.78997" zMin="-40.5702" zMax="40.5702" />
.
.
<ABarrelSiliconDetector c="SIL" n="Silicon" layer="0" length="12.609" width="6.144" thickness="0.844888" tilt="11.0351" nz="6" nphi="32" r0="30.134" phi0="3.2" zMin="-74.8272" zMax="74.8272" />
.
.
<AEndcapTRTDetector c="TRT" n="TRT" layer="0" nphi="32" rMin="64.67" rMax="100.1" phiIn="0" phiOut="0.292969" zMin="84.425" zMax="97.125" />
.
.
</AGeometry>
 

The format shown clearly takes advantage of the fact that the interpreting program 'knows' about the rotational symmetry of the detector, the units used and the basic form of the detector element, and essentially presents information about the unit cell to be represented and how it is to be duplicated at specific radii and angular offsets. For the silicon detectors, the barrel detectors are represented as rectangular boxes with a given tilt about the z-axis; the number of detectors at a given radius (r0) is given by nphi, starting at phi0. In the longitudinal z axis, the number of detectors is given as well as the minimum and maximum z dimensions for the layer.

The TRT detector is somewhat more complicated, being a quadrilateral cross section with a radial edge specified in terms of minimum and maximum radii (rMin, rMax) and minimum and maximum phi (phiIn, phiOut).

The event file, also referred to as a JiveXml file, presents essential information about a given single event in several forms. Any given event contains spurious hits in the detector due to electronic 'noise' as well as hits which are deemed to build tracks. The analysis program, Athena, takes the raw hits in a detector and may build space points with a precise x,y,z position. These hits are passed through a track-finding filter and may then be associated with tracks which are found.

The JiveXml information reflects this successive filtering, presenting hits, space points built from these hits (where possible) and finally tracks. The hits are given integer 'barcodes' to identify them uniquely. In addition, some detector specific parameters are given, and measures of the quality of the tracks along with physical quantities which might be inferred, such as the particle momentum.

An example of the space points from this file is shown below. Not all the reference data is filled for every event, and particularly for running with cosmic rays (which we have done without magnetic field, and so far without the pixel detector) some parameters cannot be inferred from the data.

                
 <S3D count="15" storeGateKey="">
        <barcode> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 </barcode>
        <clusters multiple="2"> 168512904 168511850 168513133 168512099 170049997 170051045
            170050203 170051250 170082433 170083479 170775158 170776156 170775257 170776274
            170775266 170776274 170775274 170776274 172213478 172212443 172213565 172212528
            172213657 172212618 173069441 173068435 174342230 174343261 175329663 175330675 </clusters>
        <etaModule> 3 3 2 2 2 4 4 4 4 2 2 2 4 2 4 </etaModule>
        <phiModule> 22 22 5 5 6 27 27 27 27 7 7 7 33 8 38 </phiModule>
        <x> -9.808979 -7.996168 24.583413 23.176761 22.379122 -13.450560 -12.680121 -12.613973
            -12.551715 26.821852 26.190418 25.515184 -17.471010 32.997142 -20.881114 </x>
        <y> -28.093757 -28.358218 27.876986 28.735610 30.365820 -34.422605 -34.606149 -34.621908
            -34.636740 35.695123 35.978239 36.280993 -41.291724 40.313217 -47.165986 </y>
        <z> 36.022580 32.086557 23.600728 23.432253 22.893846 37.440609 41.358268 39.659175
            38.060028 20.829506 21.015146 21.499875 38.969130 19.912280 40.171093 </z>
    </S3D>

                

It can be seen that the space points and other data are presented as text lists where each ith space point takes its data from the ith item in each list.

The geometry described above is unchanging for all events, it therefore makes sense to pre-process the SVG representation for the geometry as a background to be merged with an event representation. The processing time and method is thus free of constraints. By contrast, the self-imposed constraint that users should simply be able to open a JiveXml file in their web browser and see an event display strongly restricts the choice of technologies; effectively dictating the choice of XSL for this intermediate step.

Rather than use an XML parser within a standard procedural language, the author chose to use XSLT 2.0 as a transform for the geometry file. The time taken for the transform was not a constraint, and XSL is code-efficient (in terms of lines-of-code) for manipulating XML. The choice of XSLT 2.0 allows one to use the sequence generators as shown below

<xsl:variable name="phiSequence" as="xs:integer*">
      <xsl:sequence select="for $i in 0 to $lastPhi return $i"/>
      </xsl:variable>

These are useful for generating the repetitive rotational elements required by the symmetric design of the detector. The overall codeline efficiency is demonstrated by the fact that the geometry presentation is achieved (including the javascript described later) in under 300 lines of code. The use of true node sets (instead of result tree fragments) as variables, exclusive to XSLT 2.0, also proved to be useful.

Styling of the detector representation is provided by an associated CSS file.

One of the principle difficulties in transforming the geometry was the absence of trigonometric functions in standard XSL to translate from the cylindrical coordinate system used in the geometry file to the Cartesian coordinate system of SVG. Using Saxon as an XSLT engine, this was solved simply by using Extended XSLT functions; the problem becomes more acute in the next step. The geometry file, transformed to SVG, is depicted below. Coloration was achieved by associating the SVG built in the browser with a CSS file. This allows the user to edit display colours to his or her preferences. The buttons used for zoom and pan are also shown and will be discussed later; the darker blue areas of the TRT cross section indicate those portions of the detector which were providing data during the 2006 cosmic ray test.


Current SVG-capable browsers implement, at best, XSLT 1.0 with no access to extensions such as trigonometrical functions. In order to address the problem of transforming cylindrical to Cartesian coordinates, the author introduced an approximate function based on Taylor expansion of the sin() function taken to the fifth term, on the interval 0<Φ<π/2 and used trigonometric identities to map other angles and the cosines onto this domain. The accuracy of this approximation can be seen in figure 5, and is nowhere worse than 3.5×10-6. The intended default display size has a 10cm radius, and if we insist that a straight line specified in cylindrical coordinates should be nowhere more than one pixel away from its true value, the required accuracy can be roughly specified as r σ < pixelSize. A typical modern LCD display pixel size is of the order of 0.2mm, so the maximum error in sine or cosine should not be more than 2×10-5. For comparison, a four term expansion results in a maximum error of 1.5×10-4

<!-- Taylor expansion for sin -->
  <xsl:template name="approxSin">
    <xsl:param name="rad"/>
  <xsl:variable name="a" select="$rad mod (2.0* $pi)"/>
    <xsl:variable name="pi2" select="$pi div 2"/>
    <xsl:variable name="phi0">
      <xsl:choose>
        <xsl:when test="$a &gt; ($pi + $pi2)">
          <xsl:value-of select="$a - (2 * $pi)"/>
        </xsl:when>
        <xsl:when test="$a &lt; -($pi + $pi2)">
          <xsl:value-of select="$a + (2 * $pi)"/>
        </xsl:when>
        <xsl:when test="$a &gt; $pi2">
          <xsl:value-of select="$pi - $a"/>
        </xsl:when>
        <xsl:when test="$a &lt; -$pi2">
          <xsl:value-of select="- $a - $pi"/>
        </xsl:when>
        <xsl:otherwise>
        <xsl:value-of select="$a"/>
        </xsl:otherwise>
      </xsl:choose>
    </xsl:variable>
    <xsl:variable name="phi2" select="$phi0 * $phi0"/>
    <xsl:variable name="term1" select="($phi0 div 6.0) * $phi2"/>
    <xsl:variable name="term2" select="$phi2 * $term1 div 20.0"/>
    <xsl:variable name="term3" select="$phi2 * $term2 div 42.0"/>
    <xsl:variable name="term4" select="$phi2 * $term3 div 72.0"/>
    <xsl:value-of select="$phi0 - $term1 +$term2 -$term3 + $term4"/>
  </xsl:template>


A second difficulty in the event format was that the individual space points are not represented as x,y,z triples but as a list of x coordinates followed by lists of y and z. In order to combine these, and without access to the xpath 2.0 tokenize and sequence facilities, a recursive list 'chomper' was written which progressively cuts the lists on the first encountered whitespace and combines the three 'chomped' numbers from each list into a single space point in the SVG, placing a predefined marker at the resulting position.

<!-- Collect x,y coordinates together and put markers there -->
  <xsl:template name="mergeHitCoords">
    <xsl:param name="xList"/>
    <xsl:param name="yList"/>
    <xsl:param name="marker"/>
    <xsl:choose>
      <xsl:when test="contains($xList,' ')">
        <use xlink:href="{$marker}" x="{substring-before($xList,' ') * $unit}"
          y="{substring-before($yList,' ') * $unit}"/>
        <xsl:call-template name="mergeHitCoords">
          <xsl:with-param name="xList" select="substring-after($xList,' ')"/>
          <xsl:with-param name="yList" select="substring-after($yList,' ')"/>
          <xsl:with-param name="marker" select="$marker"/>
        </xsl:call-template>
      </xsl:when>
      <xsl:otherwise>
        <use xlink:href="{$marker}" x="{$xList * $unit}" y="{$yList * $unit}"/>
      </xsl:otherwise>
    </xsl:choose>
    </xsl:template>

Different marker types were defined in the SVG for single hits and hits which could be made into three-dimensional space points. The styles (colours, line thickness) of the points were controlled by the geometry CSS styles, allowing user preferences. Typically during analysis many JiveXml files can be produced in the analysis directory, only a few of which may be interesting. In order to allow browsing of these files with a minimal number of additional steps, the background geometry SVG can be externally referenced by the browser from a remote url using the XSLT 'document' element. The XSL thus tries to reference a local file first and if it fails to find it, downloads the file to the browser from an external site. With the event transform XSLT placed in the same directory as the JiveXml files, the user may now open each JiveXml file in an SVG-capable browser. A screen shot of the final image is shown below, depicting one of the first cosmic ray events seen in the combined SCT and TRT detectors. Space points are shown in black, hits in yellow. The track finder in this case found two slightly displaced tracks, shown in red.


The SVG produced by the XSLT mentioned above represents the detector in units of mm; the viewbox coordinates are configured to depict a coordinate range of -1000, 1000 in both directions, within a 20 cm square. A clip path determines the visible portion of the detector, and the overall detector graphic is initially scaled by 80% to fit well within the clip path. This offers an immediate and simple solution to magnifying the picture: change the overall scale of the detector by manipulating the DOM from Javascript. The Javascript function which achieves this and the DOM fragment it manipulates are shown below.


var scale0 = 0.8;
var dx0 = 0;
var dy0 = 0;
function changeScale(multiple)
{
    var picture = document.getElementById("detectorPicture");
    var newScale = scale0 * multiple;
    scale0 = newScale;
    newTransform = "scale("+ newScale + ", -" + newScale + ") translate(" + dx0 + "," + dy0 + ")";
    picture.setAttribute("transform",newTransform);
}

<g style="clip-path:url(#clip);">
      <g transform="scale(0.8,-0.8)" id="detectorPicture">
         <g id="BarrelPixel0Layer">
            <use xlink:href="#BarrelPixel0" x="50.57799762705943" y="6.9193039279374515"
                 transform="rotate(0,0,0)"
                 title="Φ= 0"/>
            <use xlink:href="#BarrelPixel0" x="50.57799762705943" y="6.9193039279374515"
                 transform="rotate(16.363636363636363,0,0)"
                 title="Φ= 1"/>
.
.
.

The actuators for the Zoom In/Out function are the '+' and '-' buttons, SVG graphics with an associated 'onclick()' event:

      
      <g id="ZoomIn" class="buttons" onclick="changeScale(1.25)">
         <circle r="30" cx="0" cy="0"/>
         <path d="M 0,20 L 0,-20 M -20,0 L 20,0"/>
      </g>
      <g id="ZoomOut" class="buttons" onclick="changeScale(0.8)">
         <circle r="30" cx="0" cy="0"/>
         <path d="M -20,0 L 20,0"/>
      </g>
        

Discrete fractional changes (0.8 and 1.25 for Zoom out/in respectively) were chosen rather than quasi-continuous zooming (with a possible slider control) so that the user could easily reproduce a given magnification with discrete mouse clicks. A similar solution was adopted for the panning function, by using the SVG 'translate' transform:

function pan(dx, dy)
{
    var picture = document.getElementById("detectorPicture");
    dx0 = dx0 + dx;
    dy0 = dy0 + dy;
    newTransform = "scale("+ scale0 + ", -" + scale0 + ") translate(" + dx0 + "," + dy0 + ")";
    picture.setAttribute("transform",newTransform);
}
.
.
.
.
<g id="GoLeft" class="buttons" onclick="pan(200,0)">
         <rect width="40" height="40" x="-20" y="-20" rx="5" ry="5"/>
         <path d="M 10,10 L -10,0 L 10,-10"/>
      </g>
      <g id="GoRight" class="buttons" onclick="pan(-200,0)">
         <rect width="40" height="40" x="-20" y="-20" rx="5" ry="5"/>
         <path d="M -10,-10 L 10,0 L -10,10"/>
      </g>
      <g id="GoDown" class="buttons" onclick="pan(0,200)">
         <rect width="40" height="40" x="-20" y="-20" rx="5" ry="5"/>
         <path d="M -10,-10 L 0,10 L 10,-10"/>
      </g>
      <g id="GoUp" class="buttons" onclick="pan(0,-200)">
         <rect width="40" height="40" x="-20" y="-20" rx="5" ry="5"/>
         <path d="M -10,10 L 0,-10 L 10,10"/>
      </g>
      

The Zoom In/Out and directional panning functions are thus implemented in about 20 lines of Javascript injected during the background geometry transform and subsequently merged in with the event transform. The final result can be seen athttp://sroe.home.cern.ch/sroe/display/example.xml.

The initial displays were introduced in 2006-2007 when elements of the detector were being tested one at a time. The inner detector is now installed in the Atlas pit, ready for data in September 2008. The combined events from both barrel and endcaps are more complex and require the endcap geometry to be incorporated in such a way that they do not obscure the barrel geometry. This will be achieved by use of transparency and layering the endcaps with the barrel geometry, with a selector to emphasize the hits in the desired detector subsystem.

In addition to the event data readout from the Atlas detector, the structure is instrumented with many sensors to indicate and control parameters such as temperature, voltage and humidity. These Detector Control System (DCS) conditions are read in a separate data stream and stored in a database. A subset of the parameters are replicated to a second database which may be accessed during offline analysis, and used to assess the quality of the data. For example, the endcap picture above shows a noisy module which is most likely due to a high voltage power supply fault on the detectors; the fault could be detected during analysis and the module's data stream excluded from track reconstruction.

The author has made a RESTful [6] interface to the DCS conditions database using a CherryPy [7] server to return conditions data in XML form in response to a query on the time and unique module identifier (based on its position in the detector). It is intended to incorporate these data such that a 'click through' on a problematic module reveals the conditions data which could cause the problem. This is currently under development.

In a high energy physics environment, the presentation of SVG (particularly with XSLT) as a data visualization medium never fails to produce a 'wow!' effect, and yet the technology has yet to achieve wider acceptance. As our experiment approaches data taking, and with increasing desire to produce 'web immediate' results, I hope I have demonstrated the power and simplicity of SVG to a wider audience such that it is considered at least on an equal footing with more prosaic methods currently in use, which generally involve converting some intermediate format to a bit mapped image and serving the image. The absence of scientific functions on the XSLT side is a serious but not insurmountable problem, and modern server-side XML libraries in any case provide an alternative route to producing SVG.