General comments

  • This is a list of raw inputs from users. No editing, filtering or duplicate-remivals where done.
  • It contains feedback, offers use-cases and requirements for event and geometry visualisation in CMS.
  • No relative priorities are assigned, beyond those offered by the individual user.
  • Requirements are organised in 3 sections:
    1. - specific needs on representing event and detector data in graphical foirmat:
    2. - general requirements on controlling the event viewing application
    3. - requirements on performance and support of the operational environment
  • Table Legend:
    • R_ID: requirement ID reflecting the Requirement Breakdown Structure
    • Date: day/month/year comment was offered
    • Priority: 0 - urgent (needed for Feb '10 start-up) 1 - Mandatory; 2 - Important; 3 - Desirable
    • Source: name of user providing requirement

1 - Representation of CMS detector and event objects in graphics format

R_ID Description Date Priority Source
1.1 Provenance      
1.1.1 Run No, event No, Data, Time, crossing, orbit, LS      
1.1.2 HLT Provenance      
  HLT menu version, L1 menu key, list of HLT paths, list of L1 seed conditions of paths, mapping of paths to streams, HLT prescales (per stream), perhaps other PSets such as module instance lists per path, or selected parameter settings such as cut thresholds. All of these are decodable at run time via provenance and are essential to diagnosing the trigger behavior for individual events. You could effectively have a GUI which looks very much like the HLT ConfDB browser. Alternatively, this could just be a link to the relevant ConfDb or L1 Key web page, however ideally this is all done with just the file. 29/1/10 1 Berryhill for TSG
1.1.3 add L1 bits that fired - as in event      
1.1.4 add L1 strings associated with them (when available in event)      

1.2 Detector Description      
1.2.1 Simulation Geometry (3D from GEANT4) including materials      
  Need ability to examine the detector geometry hierarchy as provided by DDD. Typical usage involves loading the geometry, then navigating down the hierarchy in the upper left window (activating children and/or Physical/Logical volume structure), and selecting certain volumes to display. The isometric (not perspective) view is most useful, as well as the ability to save eps files, or select the 3 standard 2D views, or insert the 3D axis into the frame. Need ability to zoom, rotate, translate the current view 17/6/09 1 Heltsey
The main usage of Monte Carlo has been examination of the geometry. Both isometric and perspective views are useful. One very useful feature which we had in the past (Geant3) is to have perspective views and then cutting open a region to see the inside portion. Choice of suitable colours to distinguish different components will be very desirable. 26/1/10 2 Banerjee
There used to be some tool to calculate weight of a logical volume and this we used to validate geometry. Also a tool to measure distance in the geometry is often useful for debugging purposes. 26/1/10 2 Banerjee
Summary: Able to look at a different version as quickly as possible. WAS: XML(DDD)->Geant4->Visualization - not have to generate manually a more compact geometry file from the XML for use in visualizing the geometry as it relates to describing the ideal detector. It may be possible to hide from the user the generation of such a file in the background as an option to one of the modern (iSpy and Fireworks) incarnations of visualization but most important is the ability to see ALL volumes and not just those with hits and to zoom in on any part to understand the finer grained details. 21/1/10 1 Case
Summary: Able to start from a set of XML files whether in a release or not so that the configuration for Simulation and Visualization are from the same Geometry. WAS: Physicists contact me when they are either migrating new geometry from Geant4 code into the CMSSW framework or when they are making changes to the existing XML files to make them more accurate by changing volume shapes or adding volumes to more accurately model the detector. In either case once they have integrated their changes they often have questions as to whether they put the parts together properly. Usually the questions are generated by physics plots that look different to them. Either the plots show more material effect than anticipated or that the materials seem to be in the wrong place and etc. In these cases my response is to pull up their set of XML files directly (whether checked in to CVS or not) and use Iguana to visualize the parts they are talking about. Often they have an "aha!" moment and solve the problem quickly themselves. Something related to dimensions of solids or positioning instructions (translation+rotation). 21/1/10 1 Case
See above. WAS:The second aspect is later in the process above, or when there is a need to look closely at a part's dimensions or position as the numbers are being modified in the XML files for some other reason. For example a run of Geant4's overlap detection tool shows an overlap. Iguana is then used to confirm the overlap. Then after each modification of numbers in the XML files Iguana is used to zoom in on the region of possible overlap to understand the effects of the changes and reasons for the overlap error or warning. 21/1/10 1 Case
  Summary: XML information should be available, such as dimensions, shape and material. WAS: Material checking. When you select/highlight a part in Iguana it tells you as much as possible about the original part. In most cases it tells you the dimensions of the part and it's material. Sometimes it can not give you dimensions because it is a composite part (i.e. union of two shapes in Geant4). 21/1/10 1 Case
  Summary: Slicing understood. WAS: Being able to cut along a plane in x-y or plane in y-z is very important for some of the dimension checking of parts and overlaps. If you know a part ends at 2 m. from the center in z of the detector, and you cut an x-y plane at 1.9 m you should see it and at 2 maybe and at 2.1 for sure not. 21/1/10 1 Case
This was required in the past for design, and is likely to be required again for upgrade design for SLHC. Less critical at present, but might become so if CMS decides simulation geometry must become more realistic than ideal (cf. recent approach of 'correcting' ideal simulation geometry shifting beam spot in MC to match relative position of Pixel detector and beam spot, because it is 'hard' to make the entire simulation geometry closer to real geometry.) 29/1/10 2 Cox
1.2.2 Reconstruction Geometry (2D and 3D)      
Outlines of chamber volumes (reco level) is essential for sensible interpretation of where detector hits and reco objects built from those hits actually occur. NOTE: in first collisions event displays produced with Fireworks, CSC community found it difficult to understand why most of their trapezoidal chambers appeared as rectangular. This severely degraded the impact and credibility of Fireworks displays as far as anyone working with the CSCs was concerned. 29/1/10 1 Cox
1.2.3 Magnetic Field      
  Ability to visualize a color plot of the field on a plane. The plane position and orientation should be configurable: ZX, ZY, and XY planes at different Z locations are the most used ones. It should be possible to choose the component to to be plotted, in particular, mod(B), Bz, Br, Bphi. The granularity and range of the color plot should also be configurable, because often an high-resolution plot of a small region is needed, and making a plot of the entire CMS with the required granularity would become very slow. It should also be possible to set the range for the plotted variable (color range).
The main use case for this requirement is the test and study of the field maps, especially for development purposes; therefore, the actual map should be used as input for the plot, rather than a pre-extracted set of data.
The "field lines" option not needed, at least in the way it is available in IGUANA.

19/1/10 1 Amapane
  Ability to visualize the magnetic field geometry. The MF geometry is loaded in CMSSW as a separate "branch" of the DDD simulation geometry. In Iguana, it is visualized with the same modules used to visualize the simulation geometry, with the trick of specifying the MF geometry's root node in place of the simulation geometry's one in the the XMLIdealGeometryESSource configuration for the visualization job. Providing that this is still possible, all other requirements are covered by those specified in 1.2.1 above. The use case for this point is to help the development of the field geometry itself; being a very specific use case, there is no need to have this functionality available to all users in the default application - being able to visualize the MF geometry with e.g. a hacked XMLIdealGeometryESSource configuration is enough.

19/1/10 1 Amapane
1.3 Tracking      
1.3.1 PixelDigis, SiPixelRecHits, SiPixelClusters, SiStripDigis, SiStripClusters      
It is important to be able to display clusters to see how many of them are connected to tracks and hence to study why some tracks are not reconstructed 19/1/10 2 Zito
| 1.3.1a | Need ability to select and draw/hide each hit from within a tree menu e.g. GeneralTracks/Track/Hit. | 19/1/10| 2 |Zito| || Need ability to select and draw/hide each hit from within a tree menu e.g. GeneralTracks/Track/Hit. | 19/1/10| 2 |Zito| | 1.3.2 | Tracks, GSFTracks | | | |
Need to make a refit in order to get a better representation of the true trajectories of tracks i.e. find hits assigned to a track and make a refit, as opposed to drawing a track from track parameters. Important for low pt tracks 19/1/2010 2 Zito
Need ability to select a track and dump data content i.e. track parameters 19/1/10 2 Zito
Tracks are typically drawn using a palette of several different colours. This helps to visualise those events that have very many tracks e.g. scraping events (see FROG display). Animation by slow rotation in 3D is also very useful 19/1/10 2 Zito
Need ability to select a track and view it in isolation in a separate window. Allows to see clearly hits on modules associated to track 19/1/10 2 Zito
It would be extremely useful to be able to use display to interactively debug tracking code in order to study why pattern recognition is failing. This implies building some interface between the tracking code and display code. Turning on LogDebug in tracking code is used to give status of pattern recognition code step by step. This could be sent to visualisation to interpret and display. 26/1/10 2 Vlimant
Need ability to display trajectory seeds. They are used to check whether they point to hits in the Tracker. Event Display has been useful in identifying problems where the seeds have been not pointing in the right direction (rotated or displaced) and therefore cannot be connected to the right pattern of hits. Have been using display recently to study scraping events and beam-halo events to answer questions such as 'are there enough seeds?' and 'do we manage to make tracks?'. 26/1/10 2 Vlimant
1.3.3 Detector volumes along tracks      
Need ability to select and draw each part of the detector piece by piece in order to provide a reference to guide the eye (see FROG). For example, draw Wheel 1 of Side 2 of TEC. Should be able to navigate down the hierarchy such that can display an individual Tracker Module (Module/Petal/Ring/Wheel/Side/TEC). This is typically used to view the position of a module that is known to be noisy and to check to what extent noise hits are being included in track fits. Components are always drawn in transparent mode so as not to obscure the data 19/1/10 2 Zito
It would be extremely useful to have access to Event Setup and Conditions Data information. Modules that are masked from the readout could be displayed in a different colour. Holes in the efficiency can be due to trying to seed from whole sections that are turned off. This could be made obvious by looking at the display 26/1/10 2 Vlimant
1.4 ECAL      
1.4.1 EBRecHits, EERecHits, ESRecHits      
Need ability to highlight the track/crystal/tower and gets its kinematic parameters 27/1/10 2 Virdee
Need ability to highlight the entry on L1 menu and see e.g. which ecal cluster/jet/ muon etc fired the L1, and its kinematic parameters 27/1/10 2 Virdee
Need ability to display the amplitudes of the times samples to look not only at the timing but also at the pulse shape for ecal/hcal crystals/cells 27/1/10 2 Virdee
Need ability to sort the individual energies (by crystal or by hcal cell) in a given trigger tower . The sorting in energy, eta and phi etc. is already there. 27/1/10 2 Virdee
Need a way of going between the visual display (of crystals, ECAL clusters, and reconstructed physics objects) and a detailed listing of the numerical values. For example: click on a cluster and have highlighted, in the numerical lists below, the object referred to. And the inverse: click on an object in the list and have the visualized object highlighted. 28/1/10 1 Seez
Concerning visual comprehensibility, using iSPY it is very difficult to see in the visualization which were barrel ECAL crystals and which were endcap. It is possible to display the detailed ECAL geometry, but this is unnecessarily complex. Far too complex. What is needed is the ability to draw a semi-transparent cylinder representing the ECAL barrel and planes representing the endcaps, on which the bins/towers/rectangles representing the crystal energies have their bases. i.e. to draw a simplified geometry to guide the eye. 28/1/10 1 Seez
It would be good to have some visual indication of a supercluster. The sub-clusters (called "basic clusters") are drawn but there is no visual indication of the supercluster object which may consist of more than one sub-cluster i.e. what is needed is a visual representation of the amalgamation - a border/boundary/surrounding line perhaps. 28/1/1/10 2 Seez
A simplified display of a region of the ECAL, into which one might descend, showing the crystals on an unrolled planar display (a "Lego" plot) would be useful rather than just using magnification of the region. 28/1/10 2 Seez
Working with RAW+RECO is a serious use case for debugging and it would, for the ECAL, be of benefit to be able to display the "timeframe" of timesamples of a selected crystal when working with RAW+RECO. This is the "pulse shape" that ECAL people draw as a graph (amplitude in ADC counts versus time) of 10 points joined by line segments. 28/1/10 2 Seez
Ability to see from the shape or color of rechits their timing with respect to the collision (early, in-time, late) 1/2/10 3 David
1.4.2 Preshower clusters      
1.4.3 Basic clusters, Super clusters (with detIDs & energy fractions)      
1.5 HCAL      
1.5.1 HBRecHits, HERecHits, HFRecHits, HORecHits      
It would make sense to show energy in HF's long and short fibers separately, depth 1's (longfibers') rec hits closest to the IP, and short fibers' rec hits next closest. This would avoid the problem of being unable to display negative energies, as when L-S <0. 4/2/10 2 Chlebana
Since HO rec hits hold a special place, both as tail catching and as they are treated differently from HB rec hits in many important physics objects, perhaps they should be shown as a separate collection, with a light blue, and placed "on top" of HB rec hits. 4/2/10 2 Chlebana
It would be useful to have the ability to highlight dead/hot rechits. We also flag anomalous rechits and it would be useful to be able to highlight these as well. You can have some switch to toggle the highlighing. 4/2/10 2 Chlebana
It would be useful to set the same color for the calotowers associated with a jet. 4/2/10 2 Chlebana
1.6 MUON      
1.6.1 DTDigis, DTRecHits, DTRecSegment (2D & 4D)      
Event display is used for investigating mapping problems in the chamber readout system. Need access to exact geometry of the detector and the ability to select and display chambers one at a time. Was used to debug geometry problems e.g. arbitrary rotations of some chambers 25/1/10 1 Cerminara/Bellan
Need ability to distinguish the different cells, at least in the 2D views. Need to retain the possibility to display Digis, 1_D hits and track segments, and in particular the ability to associate 1-D hits used in each segment. Associating hits to segments is sensitive to application of calibration corrections and is therefore very useful for spotting problems in the local reconstruction. 25/1/10 1 Cerminara
Would be nice to display time information, especially useful for identifying cosmics. Both in display e.g. using colour, and dumping information in table view 25/1/10 1 Bellan
Ability to access information from muon reco objects is very important. Would like to use in event selection (e.g. to have filters based on #tracker muons, #global muons etc.) and have dumped in Table view. 25/1/10 1 Bellan
Specifying colours used to display objects in configuration file is inconvenient - need ability to select/change them from the GUI 25/1/10 1 Cerminara
Would like to retain the possibility to turn-on labeling of cells (1 cell/layer) 25/1/10 2 Cerminara
1.6.2 RPCDigis, RPCRecHits, DTRecSegment (2D & 4D)      
1.6.3 CSCWireDigi, CSCStripDigi, CSCSegments, CSCRecHits      
Digis - Visualization of strip and wire digis has been essential for understanding detector behaviour, both real and simulated, as well as software modelling of the detector. We have been reasonably happy with IGUANA's display of these digis as the coresponding geometric strip(s) and wire-group(s) that fired. Strips are always radial and wires are usually orthogonal to the strip symmetry axis. But in ME1/1 the wires are tilted to compensate for the Lorentz force, and it took rather a long while for the wires to be correctly drawn like this. 29/1/10 1 Cox
Rechits - CSC rechits are 2D local x, y coordinates. Effectively 3D since the (global) z comes from the actual station (i.e. chamber position in z). We've been happy with the standard representation as points with local x and y errors as bars. 29/1/10 1 Cox
Segments (these are also formally rechits) - CSC segments are constructed from the 2D rechits on the 6 layers of a chamber, as straight-line approximations of the track segment passing through a chamber. They have a position (typically the centre of the parent chamber) and a direction. NOTE: in first collisions iSpy event displays, the segments were drawn parallel to the z axis, which was quite misleading. In general they really should be following the track, and in earlier versions of visualization packages, they were. 29/1/10 1 Cox
1.6.4 Stand-alone, Global and Tracker Muons      
  A proper display of the muon trajectory is important for debugging, physics interpretation, and PR event displays. Information stored with tracks is only limited, so access to the SteppingHelixPropagator and Magnetic Field (see 1.2.3) may be necessary to re-reconstruct a smooth muon trajectory. Extrapolation of the trajectory beyond the innermost and outermost hits on a track has proven useful to assess compatibility between inner and outer muon tracks, and between inner muon tracks and other deposits, hits or muon segments in the event. It should be possible to switch on/off the extrapolation of the tracks. 26/1/10 2 Mulders
It is essential to have some visualization to understand tracker algorithms and behaviour, and how detectors are responding and their data are being reconstructed. For example in first collisions visualizations of muon candidates it was clear the CSC segment building in ME1/1A chambers needed cleaning-up - spurious combinatorics led to too many 'impossible' segment candidates. Updates to the CSC segment-building code to address this have already been released in CMSSW_3_5_X. But this was a good example of the power of visualization to drive reco algo modifications. 29/1/10 1 Cox
1.6.7 Muon calorimeter energy deposit      
1.7 Particle Flow      
1.7.1 PF Reconstruction Objects      
  Need the ability to display the following PF objects PFSimParticle (Track), PFVertexObject, PFTrajectory points (associated to a track), PFRecTrack (Kalman Filter), PFGSF Rec Track (with vector of brems.), PFCalorimetry RecHits and Clusters, PFRecHit fractions used by clusters, PFBremstrahlung, PFConversion (list of RecTracks), PFJet. Important is a good display of the object connections and interdependencies to understand and debug the Particle Flow reconstruction. The position relative to detector surfaces is a necessary ingredient to understand showering. Examples of such displays can be found in CMS PAS PFT-09-001 and in the Workbook 26/1/10   Bernet
1.7.2 PFCandidate (hadron, e, mu, photon))      
  The PF high level objects are built out of the PF reconstruction objects by first creating PF blocks (using the link algorithm) and then by 'extraction' one by one of the muons, electrons, jets etc. from these blocks until the PF reconstruction is complete. The ability is needed to debug this high level reconstruction by looking at events for which the reconstruction has not worked as expected e.g. if the multiplicity of calo and PF jets is found to differ significantly. Starting with (prefiltered) input objects, the particle flow algorithm gets applied interactively in an iterative fashion with slightly changed parameters. This is a use case currently covered by a custom Root application (CMS.PFRootEvent). 22/1/10   Bernet
1.8 Physics Objects      
1.8.1 Photon, electron, muon, tau, lepton      
Like in image editors where you can interactively set threshold in color saturation, it would be really good to have the pt spectrum of tracks, superclusters, jets and muons and then be able to use sliders to only display tracks (etc) above a given threshold. 1/2/10 3 David
1.8.2 Calotowers, MET, Jets      
Need ability to look at JET momentum after the different levels of energy correction. Look at reconstructed jet and the one that has been jet-energy corrected 22/1/10 2 Autermann
1.8.3 Particle candidates      
Need ability to display simple candidates. If the particle candidates are a combination of other high level objects (e.g. representing event hypotheses), the 'decay tree' of combined objects should be visible 22/1/10 2 Hegner
1.8.4 Object associations and matching.      
The result of object associations should be displayable. One example is the matching of reconstructed objects to generator level particles or matching of trigger objects to reconstructed objects. To explore useful matching setups, an on-the-fly matching using the event display would be needed. Need to be able to click on an object and request 'display matching objects'. 22/1/10 2 Wolf/Malgeri
1.8.5 Simple computations      
Selecting two or more reconstructed objects, the physicist should be able to get the sum of the four momenta. A use case for this are possible resonance decays in the tracker. 26/1/10 3 Hegner
1.8.6 Event hypotheses      
A special case of the combined candidates of point 1.8.3 are event hypotheses (e.g. a Z -> mu mu). Need ability to display such event hypotheses. A possibility would be to have a flat display showing the 'decay tree' of a hypothesis and on selecting one final state object there, the corresponding object gets highlighted in the 3D-view. 26/1/10 3 Lista
1.9 Monte Carlo      
1.9.1 Generator and detector simulation provenance      
No features specific to generators are required 26/1/10 3 Cossutti
1.9.2 MCTruth (particle decay tree)      
1.9.3 Vertices of SimParticles (Tracking Vertices)      
Ability to visualise Tracking Vertices is needed for tracking studies 20/1/10 2 Cossutti
1.9.5 Charged particle trajectories (SimTracks + SimHits)      
A tool to superimpose the trajectory of MC track on reconstructed track would be nice. MC track can be drawn from a collection of points during the original track propagation or from the SimTrack kinematics. Both are useful to have. 26/1/10 2 Banerjee
1.9.6 CaloHit etc.      
Enabling distinction of signal and pile-up hits will be a useful tool. 26/1/10 2 Banerjee
1.10 Trigger      
General comment from Jeff Berryhill: A complete list of HLT and L1 features have been added to the twiki. It is a lengthy list of mostly "mandatory" features if one is to use the event display to interpret trigger behavior. To my knowledge not much currently exists in the way of implementation in the popular event display packages. The list effectively duplicates most of the capabilities of L1 and HLT DQM software, however, so we know in practice that all of this data can be extracted from the edm, in most cases rather easily. Vladimir and I are willing to help developers if that is required for a timely implementation. 29/1/10
1.10.1 Level 1 Trigger
For each L1 path, a list of conditions and prescales, and which ones passed. For those which passed, one should be able to selectively display path-wise or inclusively the L1 four-vectors (and object type, perhaps color-coded) of candidate combinations which caused the L1 path to pass. 29/1/10 1 Berryhill for TSG, Vlimant for Muon HLT
Display of primitive L1 data objects (TPGs, RCT/GCT cluster lists, RPC and TF muon lists) 29/1/10 1 Berryhill for TSG
More ambitiously, L1 4-vectors can be matched to their corresponding offline objects and to their more primitive counterparts (TPGs, RCT lists, muon TF lists, etc.) so one can more freely navigate between them, instead of merely superimposing them on the display. 29/1/10 3 Berryhill for TSG
Display the list of L1 global trigger algorithms, and which the event passed 29/1/10 1 Brooke
Display the final L1 trigger objects (muons, e/gamma, jets, sum/missing Et, sum/missing Ht, and possibly HF bit counts and ring sums) 29/1/10 1 Brooke
Display the intermediate L1 trigger objects (DT, CSC and RPC muon candidates, RCT region sums, RCT e/gamma candidates) 29/1/10 2 Brooke
Display the L1 trigger primitives (ECAL and HCAL towers, with fine grain bits, CSC and DT track stubs) 29/1/10 2 Brooke
Navigate between final L1 objects, intermediate objects and trigger primitives. Might require extensions to the L1 geometry/navigation code. 29/1/10 2 Brooke
1.10.2 HLT
List of HLT trigger paths and prescales, and which ones passed. For those which passed, one should be able to display path-wise or inclusively the four-vectors (and object type, perhaps color-coded: Muon, Jet, MET, etc.) of candidate combinations which caused the path(s) to pass. 29/1/10 1 Berryhill for TSG, Vlimant for Muon HLT
For all HLT paths, listing of the last filter passed. 29/1/10 1 Berryhill for TSG
For each HLT path, a list of L1 seed conditions (NB: these are NOT 1-1 identical to L1 paths) and prescales, and which ones passed. For those which passed, one should be able to selectively display path-wise or inclusively the L1 four-vectors (and object type, perhaps color-coded) of candidate combinations which caused the L1 seed condition to pass. 29/1/10 1 Berryhill for TSG
More ambitiously, HLT 4-vectors and L1 seeds can be matched to their corresponding offline objects (through simple DR matching, say) so one can more freely navigate the two, instead of merely superimposing them on the display. 29/1/10 3 Berryhill for TSG
For edm formats with non-trivial HLT object data (HLTMON et al.), display of certain intermediate candidate class 4-vectors ("L2" or "L3" lepton candidates, e.g.) 29/1/10 2 Berryhill for TSG, Vlimant for Muon HLT
1.11 BRM and Forward detectors
1.11.1 Beam Radiation Monitors
Display of BSC detector and data has been requested in time for startup in February. This use-case is unique in that the BRM data is completely independent of CMSSW. Following this other BRM detectors should be included. 20/1/10 2 Bell
1.11.2 Forward detectors
Information on CASTOR geometry and data is available and needs to be implemented. 13/1/10 2 Katsas
There are currently no visualization tools for ZDC. We would like to have a ZDC view. 4/2/10 2 Chlebana

2 - Tools for drawing and exploring event / detector data

R_ID Description Date Priority Source
2.1 Application Control      
2.1.1 opening/closing detector and event files, browsing directories (file system/web),saving selected events in new files      
  Need ability to pause/resume display in order save image of events 7/8/09 2 Acosta
  The ability to access any event in any run in some standard/centralized way 1/2/10 3 David
2.1.2 save/print graphics image file to printer      
2.1.3 edit/save/load displaypreferences (GUI layout , colour, visibility)      
  Need ability to start from a standard configuration 7/8/09 3 Acosta
  Need ability to customize views (persistence of configuration welcome, but should not be default for start-up) 7/8/09 2 Acosta
  Need ability to select from standard configurations for known conditions (splash, beam halo, collisions, outreach/publicity) 2/12/09 3 Cousins
2.1.4 other control features (quit, help, command line options, ..)      
  The ability to loop over events based on a set of criteria 1/2/10 3 David
2.2 Viewing detector and event data      
2.2.1 edit/save/load render styles for collections (default & custom)      
  Need ability to inspect in a user friendly way (e.g. right clicking on it) the characteristics ( eta , phi , energy/momentum ) of any given displayed object 7/8/09 2 Acosta
  Need ability to make a color-coded plot of times, analogous to Super-K plots 2/12/09 2 Cousins
  Need ability to zoom in on a calo hit and click on it, and have its characteristics dumped - would also be useful to have the reverse function: click on a line in the dumped list, and see that object highlighted in the picture. 2/12/09 2 Cousins
2.2.2 define cuts/scales on variables ( energy, ..)      
  A string selection feature is mandatory for setting cuts for all displayable objects such that they can be filtered from the display. A nice feature would be to define a minimum value and a maximum value and provide a 'slider' to change the threshold between the two ( min --------> max ) 26/1/10 1 Vlimant
  Need ability to adjust thresholds for shown objects (units should be clearly specified) 7/8/09 2 Acosta
  Need ability to adjust energy scale for calorimeters (ideally with ability to display scale, again with clear units) 7/8/09 2 Acosta
  Shifter needs to know thresholds/scale factors set for calo hits and to be able to change them 2/12/09 2 Cousins
  Need ability to display tracks with cut on pt, chisq and/or chisq/dof (important) 2/12/09 2 Cousins
2.2.3 filter events based on trigger, tracks, energy, etc      
  Need ability to filter on selected triggers (L1, technical trigger bits, HLT) 7/8/09 2 Acosta
Need ability to cut on the number of tracks in an event in order to be able to preferentially select complex events 19/1/10 2 Zito
2.2.4 Event selection > go to next/previous, specific (run#/event#), start/end of file      
Need to be able to make an arbitrary selection of events in a programmable way. Make a catalogue of interesting events and view them. Need fast access to an arbitrary list of events in a run. 19/1/10 2 Zito
2.2.5 Autoplay settings      
  Slideshow of online events with adjustable delay between (~5 seconds) fed from event server 7/8/09 2 Acosta
  Displaying events from circular buffers should be avoided as displaying events taken earlier is confusing for shift crew 2/12/09 2 Cousins
  Ability to choose a view and have only that view displayed (e.g. on big screen) for every event - rotating through all available views (e.g. lego plots) may not be disirable 2/12/09 2 Cousins
2.3 Viewers      
2.3.1 2D viewer (r-phi, r-z, η - φ ...)      
  In r-phi view, ability to turn off TEC/TID and look at curling tracks in TIB/TOB only. One would like to have a barrel view without endcaps superimposed. Also the reverse: display one endcap (only) at a time, without barrel. 2/12/09 2 Cousins
  In certain projections it would be useful to only display slices of the detector e.g. removing the endcaps in the r-phi view 8/1/10 2 Virdee
  η - φ plot is useful, particularly when used in conjunction with Particle Flow. Was missing from iSPY display. Need to use a single consistent font when annotating displays. 8/1/10 2 Virdee
In the r-z view would be better to project 1 sli ce of the DT chambers rather than the whole chamber. Currently in iSPY the view is distorted because of the projection 25/1/10 2 Cerminara
2.3.2 3D viewer      
  This is used heavily for monitoring events as they are collected to understand beam and detector conditions. For example 'scraping events' are very complex with many tracks not originating from the interaction region and Event Display is used to distinguish these events from collision events. It is extremely useful to have animation such that each event is automatically rotated slowly to get the 3D perspective. The other 2D views should also be visible so they can be looked at simultaneously. 19/1/10/ 1 Zito
2.3.3 Lego viewer      
  Add tracks to the lego plot, e.g. a vertical thin line at the location in eta-phi where the track intersects the front ecal face 2/12/09 2 Cousins
2.3.4 Synoptic viewer (BRM, unrolled calorimeter      
2.3.5 Specialised viewer (Tracker Map, CSCs, BRM, ..)      
2.3.6 Table viewer (nteractivity - picking, filters/cuts, actions on data etc)      
2.3.7 Viewer controls (translate/rotate/zoom etc.      
2.3.8 Need to be able to display histograms of selected quantities inside an event and across events 21/1/10   Hegner
2.3.9 General comments on viewers      
  Need to be able to display on a white background. Colours of displayed objects need to be adjusted accordingly 12/1/10 2 Govoni

3 - Performance and support of the operational environment

R_ID Description Date Priority Source
3.1 Environment      
3.1.1 Hardware and OS support (Linux, Mac OS, Windows)      
Machines in the CMS Centre have inadequate resources for running event display locally. Need to define a minimal configuration for cpu, memory and graphics card. 19/1/10 2 Zito
Need large screens in order to look at several views simultaneously. Also need screens/graphics cards with very good resolution. 19/1/2010 1 Zito
Was unable to run event displays locally in CMS Centre due to problems with the OS installation there. As a result always run remotely on lxplus machines. 19/1/10 2 Zito
It is very convenient to have the display run on Windows such that it can be easily installed and run on portables 19/1/10 2 Zito
3.1.2 tag, build, test, release      
3.2 Performance targets      
3.2.1 Startup time      
  Latency to start display of order a minute after a run starts, or less 7/8/09 2 Acosta
3.2.2 Time to process/display next event      
Should be of order 1 or 2 seconds max. Need to be able to scan large numbers of events quickly to look for patterns that are repeated. 19/1/10 1 Zito
3.2.3 Memory footprint      
3.2.4 Time to build release      
3.2.5 Latency from DAQ to display of event      
3.3 Operations and support      
3.3.1 Event display as an online monitoring tool in support of data-taking      
  Need ability to display HLT reconstructed objects - display of global reconstruction products also welcome (but must have at least HLT) 7/8/09 2 Acosta
  It is important to be able to display all raw data collected i.e. all hits must be displayed, not only those used in reconstruction. Raw hits give indication of cleanliness of conditions. 8/1/10 0 Virdee
  Need event display running continuously as data are being collected to provide instant feedback on quality of data. Extremely important visual aid for shift crew. Underlines why need all raw data to be displayable. 8/1/10 0 Virdee
  In cases where see something odd it is important to be able to play with thresholds e.g. changing #hits on track, #crystals add into tower/cluster 8/1/10 0 Virdee
  The shift crew must have sufficient training and familiarity with the display to be able to re-start it and to get high-level diagnostic information to unblock it when there are problems. Need to be prepared for start-up in February. Will need experts to be available on-call again 8/1/10 0 Virdee
  First experience showed that failures can occur in both displays due to a dependency on external factors. It is important to try to understand what dependencies can exist and how problems manifest themselves in the event display. An example was when only pixel hits were displayed by iSpy and Fireworks (but not FROG) even though the full detector was included in the readout. Was eventually traced to a database problem. 8/1/10 0 Virdee
3.3.2 Synchronisation of patches on-/off-line      
3.3.3 Installation and integration of software (control room, ROCs)      
Operationally whole chain needs to be configured correctly for event visualization to work properly. Displays run rather smoothly at the CMS Centre where experts have full access and control of full chain, from the stream definition and management of CMSSW installations down to DB and reconstruction configuration. Need ability to update database, restart processes as/when required in order to fix problems quickly. Need to put in place a similar infrastructure at P5 by deploying a server (reconstruction) and several cpus for running visualisation client. Need to understand how to connect to networks (private and/or GPN). Involves discussion with Online and Run Coordination. 15/1/10 1 Silvestris
  need to assign responsibilities for a) providing the infrastructure b) deploying/commissioning software in situ c) the day to day operation 6/1/10 1 Silvestris
3.3.4 Problem recovery      
3.4 Outreach and Education      
3.4.1 Live Web event display images for CMS and general public    
Event images from the current data taking should be made available via a fixed URL (Web page, e.g. in CMS-TV) that is auto-updating and suitable for displaying on large screens in CMS Centres, CMS Institutes, etc. The events should be filtered to show events of interest to physicist experts as well as outsiders so that a CMS person can watch the display for a dozen events and immediately get a sense of what is happening at P5. Several possible views should be supported (probably by zones on one page rather than switching between views). Colour settings hsould be the usual press-friendly set. The update frequency should be in the range 2 sec -- 20 secs. 18/1/10 0 Taylor
3.4.2 Event image repository      
Need a Web accessible repository of up-to-date event image repository for talks, papers, press 18/1/10 2 Taylor
3.4.3 Animated event displays for CMS Centres and Outreach (particularly for TV)    
Need ability to deliver on the Web for any arbitrary event. The animation should show the beams colliding, followed by an exploding event with tracker hits and tracks travelling out from the vertex, impacting on the calorimeters, etc. The animation should also include some smooth animation of the camera (zooming in/out, rotations, etc.). The result of the animations should be viewable in a standard Web browser with a single click (no special customisations required). A stream of such animated events should be available within CMS-TV so that a fixed outreach display plays a never-ending sequence of live animated events. Movie clips should be also available as seperate movie files in a format accpetable for inclusion in TV programs. 18/1/10 0 Taylor
  An animation example file was provided by FROG and has proved useful when discussing with TV crews - see this thread 8/1/10 2 Virdee
3.4.4 Event Display movies      
Event Display movie clips should be available as seperate movie files in a format accpetable for inclusion in TV programs. 18/1/10 1 Taylor
3.4.5 Interactive web client
4 Fireworks cleanup      
4.1 Use same proxy builders in 3D and projected view, if projection is trivial.
4.2 Base class for GL views
4.3 Magnetic field estimation. Done before new event build.
4.4 Optimise track propagation. Step size evaluation, propagation on demand. If time available muti-thread propagation.
4.4 Improve standalone build system. Not possible to build on SnowLeopard from cvs.
5 Windows support      

Responsible: JohnHarvey

Edit | Attach | Watch | Print version | History: r38 < r37 < r36 < r35 < r34 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r38 - 2011-05-03 - JohnHarvey
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback