ELSEYIER

Nuclear Instruments and Methods in Physics Research A 389 (1997) 99- 100 NUCLEAR

INSTRUMENTS & METHODS IN PHVStCS RESEARCH

Secfm A

Interactive event displays for the LHC

Lucas Taylor

Abstract The ability to visualise the LHC detectors and their response to physics events is of great importance, both in the

design, construction, and data analysis phases of the experiments. We discuss the visualisation requirements for the LHC and the current and future visualisation software, emphasising the difficulties faced compared to the LEP era.

Ke,l~uo&: Event display: Scientific visualisation; Computer graphics; LHC

1. Visualisation at the LHC

The LHC environment is considerably more demand-

ing than that of High Energy Physics experiments today. The number of readout channels will increase by typi- cally one or two orders to _ IO’. The event data will also be considerably more complicated. Each beam crossing will contain typically 20 minimum bias events, in addi- tion to the event of potential interest, such that each

crossing contains many hundreds of charged tracks. The beam crossing time of 25 ns is so short that signals from several crossings are present in the detector and the readout chain at any particular moment. To compound these difficulties, the events of interest are extremely rare. For example, prior to any trigger or offline selection, only

one event in z 10” is expected to contain an observable

Higgs boson decay. We advocate several strategies for producing meaningful displays from the huge amount of data available to the visualisation program as discussed

below. The event data should include raw information such as

hits and energy deposits, reconstructed objects such as tracks and jets, and information from the slow control system, such as dead or noisy detector elements. The engineers designing the detector need to see details of the mechanical construction, the readout cables, cooling system, etc. This level of detail is, however, less useful to the physicist. who would prefer to display highly simplified. yet accurate, representations of the detector components in order to place the event data into context. There are also many different ways of displaying the same quantity. For example. calorimeter energies may usefully be displayed as: uniformly sized markers, colour- coded according to energy; as volumes representing the

detector element hit, perhaps scaled or coloured accord-

ing to energy; or as histogram bars located at the point of deposition. The display program must have the ability to display arbitrary sets of data and support multiple visual representations of the same quantity.

The single most important view is the ?D Cartesian

representation of the detector and event data. with arbitrary magnification, offset, rotation, clipping, and visibility. The view is projected into 2D although the implementation of true 3D, for example using stereo views, is not precluded. Visualisation does not. however. consist merely of 3D Cartesian views. Transformed views of data play a crucial role in our ability to assimilate the important features of events. For example, hits on high momentum tracks are separated in X. y. : but are tightly clustered in the 4 versus 0 view. while jet structures are clearly seen in a leg0 plot of energy as :I function of (i, and pseudo-rapidity. The physicist may imagine many useful Euclidean, Lorentz, etc. transformations and a display program should be prepared to support the resulting views. The LHC beam crossing time of 2511s renders inter- and intra-event times crucial for triggering and reconstruction. This adds a “fourth dimension” which needs to be considered in the context of event visualisation.

The event display program should be more than just a viewing program. The program should serve as a bi-directional interface to the data and reconstruction code and support such actions as: application of selection cuts (e.g. energy, p7, event timing, trigger, etc.); plotting (e.g. hit residuals with respect to a fitted track, lego plots, etc.); re-reconstruction (e.g. track fitting. jet finding, etc.): kinematic analysis (e.g. invariant masses. Lorentz transformations. etc.): statistical analysis (e.g. fitting

016X-900?!97.‘$17.00 Copyright ‘I_‘, 1997 Elsevier Science B.V. All rights reserved PI/ s~~16x-9002~97)00053-? Ilc. INTERACTIVE ANALYSIS

100 L. TaylorlNucl. Instr. and Meth. in Phys. Rrs. A 389 (1997) 99-100

hypothesis testing, etc); database interrogation (e.g. trigger conditions, HV status, dead/noisy regions. etc.). Where appropriate, the results of any such action should trigger an automatic and consistent update of all views. Implementation of such features is probably the most difficult part of developing an event display program since it requires a compatible and coherent design of the data structures and the reconstruction code, and especially close collaboration of the various software

development teams.

from commercial companies. Commercial software will be used for rendering the graphical user interface [S]. and for the underlying graphics library functions. The rather obselete GKS and PHIGS standards will be superseded by more modern products such as Open GLTM, InventorTM, or VRMLTM. The display of the de- tector is likely to rely on the GEANT4 graphics software

[6] while the event display code will be largely developed within the collaborations [7. S]. Looking even further ahead one might imagine a unified physics analysis environment [9] based on new programming paradigms, such as Java.

2. Future software design

References The LHC collaborations each consist of several

thousand scientists around the world, working on a multitude of hardware platforms. Display programs should therefore run efficiently on networked platforms of different types. Neither expensive software nor dedicated hardware should be required. It is, how-

ever, desirable to be able to take advantage of the enhanced capabilities of more powerful graphics stations. The maintenance of the -lo6 lines of code poses

major problems. All codes will have to conform to well- defined software standards. Modularity facilitates the replacement and re-use of code as the software matures. Documentation is of paramount importance and should

be an integrated part of the software engineering process.

The typical LHC strategy is to migrate to an Object Oriented paradigm [l] for the complete offline software by the end of the century. At the core is a persistent object database storage system [2]. The physics software, writ-

ten in C + + , will draw heavily on HEP software such as GEANT4 [3] and the LHC ++ HEP library [4]. The software engineering, information system, and data pre-

sentation software is expected to come predominantly

[l] M. Marino and V. Innocente. these Proceedings (AIHENP’96, Lausanne, Switzerland, 1996) Nucl. Instr. and Meth. A 389 (1977) 26.

[Z] D. Duellamann. HEP Data analysis based on an ODBMS store. in: Proc. HEPVIS 96. eds. L. Taylor and C. Vandoni (CERN. Geneva 2%4 September 1996).

[3] S. Giani, Proc. AIHENPP6 Lausanne. Switzerland. 1996.

[4] Y. Adesanya, Ref. [l] p. 32. [S] GCosmo, Graphical user interfaces, in: Proc. HEPVIS 96.

eds. L. Taylor and C. Vandoni (CERN Geneva, 2-4 Sep- tember 1996).

[6] J. Allison, Graphics for GEANT4, in: Proc. HEPVIS96. eds. L. Taylor and C. Vandoni (CERN. Geneva, 2-4 Sep- tember 1996).

[7] J. Hrivnac, Event display in ATLAS. in: Proc. HEPVIS96, eds. L. Taylor and C. Vandoni (CERN, Geneva, 2-4 Sep- tember 1996).

[S] L. Taylor, Event display in CMS, in: Proc. HEPVIS 96, eds. L. Taylor and C. Vandoni (CERN, Geneva. 2-4 September 1996).

[9] J. Swain and L. Taylor, Data analysis a physicist’s perspective. in: Proc. HEPVIS96, eds. L. Taylor and C. Vandoni (CERN. Geneva. 2-4 September 1996).