Gowdy, S J

Marsiske, H

Strother, P

CERN Document Server

Preprint - Server (20-September-1999)OPEN-99-227IC/HEP/98-06Object oriented reconstruction software for the BaBarcalorimeterStephen J. Gowdya, Helmut Marsiskeband Philip Strotherc1(a) Dept. of Physics, University of Edinburgh, Mayeld Road, Edinburgh EH9 3JZ,Scotland. SGowdy@lbl.gov(b) SLAC, P.O. Box 4349, Stanford, CA94309, USA. marsiske@slac.stanford.edu(c) The Blackett Laboratory, Imperial College, Prince Consort Road, London SW72AZ, UK. pd.strother@ic.ac.ukAbstractThe object oriented software used in reconstruction for the BaBar electro-magnetic calorimeter is described. The basic reconstruction objects and theirabstractions are presented. Techniques employed in the design of clustering,cluster division, track matching, particle identication and global calibrationsoftware are discussed in terms of their ability to provide a core interface whileallowing for improvements in physics capability.1 The BaBar CalorimeterThe BaBar Calorimeter is a high precision Thallium doped Caesium Iodide deviceconsisting of a 48120 crystal barrel and an 8 row forward endcap graded between 80and 120 crystals. The expected resolution is 1%=4qE(GeV ) 1:2%. The operatingconditions at the PEP-II asymmetric collider for which it is built are expected tobe harsh, with between 1{3 GeV of soft photon background (resulting from lostbeam particles) being deposited in the calorimeter per s. The combination of highprecision and dicult operating conditions creates the need for exible software withgood scope to allow for improvements in physics capability. The approach taken hasbeen to use the principles of object oriented design to give a C++ implementationthat denes the basic observables and reconstruction framework in such a way asto permit the external clients of the calorimeter software to code to a well denedinterface, whilst allowing for improved algorithms and implementations which donot force clients to recode.2 Basic ObjectsThe Digi class represents the most basic front end electronics output. Virtual ac-cessors to the energy and time are provided, along with a channel identier. Twosubclasses of Digi exist. SharedDigi overrides the energy function to provide aweighted energy. This concept is used in cluster division, which will be discussed1Contact author.1later. CalibratedDigi overrides the energy and time accessors to incorporate anindividual crystal calibration given at construction time.The Cluster class is designed to encapsulate the aspects of an energy deposit inthe calorimeter. The principal interface provides information on the energy, positionand error matrix associated with the cluster. Its implementation is in terms of acollection of pointers to Digi objects. Most clustering algorithms insist that thiscollection be contiguous, but this is not enforced at this level. More complicated in-formation on the distribution of crystals within the cluster, and dierent estimationsof the position of the cluster are provided by the derivatives of an AbsClusterProp-erty class, which are constructed by the Cluster on demand. This allows for theextension of the number of quantities so calculated without having to recompileexternal code which depends on the Cluster class.The Bump class is a derivative of Cluster and typically contains only one electro-magnetic maximum, although this is not enforced at the design level. A Bump isconstructed with SharedDigis, leading to re-use of the Cluster position and energycalculation code, and complete transparency between the two classes. A Bump willusually have as many SharedDigis as the Cluster from which it was formed.The Cand (candidate) class is intended to represent a generic particle observationin the calorimeter. It contains a collection of pointers to Clusters and also containsa pointer to a track object [1] which may be null. The functions of position, energyand error matrix provide calibrated forms of these quantities using information in aAbsCalibrator object handed to the Cand at construction time. Access to a PidInfoobject, discussed below, is provided.The PidInfo class allows for access to information regarding the compatibility ofa given observation to the expected observation for a given particle hypothesis. Theimplementation places no restrictions on the number of hypotheses tested, nor onthe number of of algorithms employed to identify a given particle type.2.1 Basic Object AbstractionThe Cand and Cluster classes, and consequently the Bump class, all inherit froman abstract base class AbsRecoCalo. This class is designed to provide uniformitywithin the calorimeter software and also in its use to describe reconstructed objectsin BaBar's instrumented ux return software, to provide cross system abstraction.Pure virtual position, four momentum and error matrix functions are provided, aswell as rudimentary genealogy for use in analysis software. Almost all externalclients of the calorimeter code make use of the AbsRecoCalo abstraction, and donot refer to specic implementations of calorimeter observations directly.3 Algorithm frameworkThe above objects are generated by a series of Modules in the BaBar Framework[2].These modules perform the basic sequence of cluster formation, cluster division,track matching and particle identication. With the exception of cluster formation2which is considered a suciently low level operation as not to necessitate complicateddesign, each of these tasks use abstract classes to dene the basic operation(s) ofthe algorithm in question. The Framework modules are then congured at runtime using particular subclasses of these. This approach is intended to provide avery simple method of algorithm upgrade and to minimise the coupling between theclients of the calorimeter Framework Modules and the specic algorithms employed.3.1 Cluster divisionIt is desirable to separate the clusters into regions containing one and only onelocal maxima. Two distinct operations are involved in this division: the location ofcrystals which are potential maxima, and the sharing of the energies of the crystalsin the cluster among these. These operations are mapped onto two abstractionswhich are implemented in a Strategy pattern[3]: rstly an abstract local maximander which takes a cluster as input and outputs a list of the crystal indices of thelocal maxima. Secondly an abstract bump splitter whose purpose is to take the listof local maxima, divide the cluster by the creation of Shared Digis, and return a listof newly created bumps. A Factory method [3] is used to congure the Frameworkmodule with a particular pair of maxima nder and bump splitter at run time.Two local maxima nders and three splitting algorithms have been implementedto date, the majority of these by non-expert C++ programmers. This seen as anindication that the abstraction is at the right level to achieve both decoupling andthe rapid deployment of new algorithms once new understanding is gained.3.2 Track{cluster matchingThe association of a given energy deposit to a track is not always unambiguous. Forthis reason it was decided that the default output should not be lists of \charged"and \neutral" calorimeter observations, but rather that the output for use in physicsanalysis should be associations between tracks and clusters at some condence level.Further, it is envisaged that several algorithms for track matching will be developedover the course of the experiment.The abstraction of the mechanisms used to match tracks to clusters is achieved bya class, AbsTrkMatchMethod which denes two pure virtual methods, one for match-ing tracks to clusters, and one for the reverse operation. These return associationmaps (see below) between the tracks, clusters and objects containing informationon the quality of the match to the event. It has not yet been demonstrated thatthe exibility of allowing dierent algorithms for the two dierent operations is nec-essary. A Framework module is again congured with diering algorithms by theuse of a Factory method. Three progressively more ecient algorithms have alreadybeen encoded in this way.Association map objects are used to provide links between clusters, tracks andTMinfo objects which contain information about the quality of the match, entry andexit points of the track and the track cluster separation. These are implemented astemplated three-way, many to many association tables based on hash dictionaries.3The exibility aorded by the use of such maps allows for decisions about the levelof match quality used to decide between neutral and charged to be determined atrun time. This exibility has been found to be useful, but not always wanted byanalysts. The provision of lists of calorimeter observations, divided into chargedand neutral at some condence level, and derived from the association maps, is alsoallowed for.3.3 Particle identicationThe central components of the design are the CandidateMaker class which is respon-sible for constructing the Cand objects that may be appropriate to the hypothesisunder consideration and the Identier class, an abstraction incorporating the con-cept of giving information about a given energy deposit pertaining to a certainparticle hypothesis. Derivatives of each are linked together by a Subject-Observerpattern which ensures that each Cand constructed is passed to every active Identiersubclass. In general Identier subclasses look at only one discriminating variable.In order to allow for multiple discriminating variable identication, and for neuralnetwork analyses, a specic abstract subclass of Identier, CompositeIdentier, isused, which employs a Template pattern [3] to allow the particular implementa-tion to look at the results of several dierent Identier derivatives and form a newconclusion based on this input.Again a Framework module is congured with specic CandidateMakers and Iden-tiers via Factory patterns. This, in conjunction with the extensibility of the PidInfoobject, allows for the extension of the number of particle types identied and thenumber of algorithms used to identify them with complete decoupling of all clientsof the code from this extension.4 Oine calibration frameworkThe energy deposits observed in the calorimeter will represent only some fractionof the energy of the incident particle at its point of creation. The experiences ofother experiments suggest that the correction for this will become a function of moreand more variables as knowledge of the detector improves. Furthermore, an analystrunning over a channel with a small branching ratio may wish to reprocess eventswith the best possible calibration, i.e. one that takes in all the known functionality,even if this were not available when the data were rst taken. A nal requirementis that the calibration system be such that the origin of the correction function beallowed to change such that the default is always the best most general purposecorrection, but that specic corrections remain available.The requirement then is for a system that supports multiple algorithms, is ex-tendible in its functional dependence and is retrospectively applicable. The coe-cients of the functions used for the energy correction must be stored in the object-oriented database used by BaBar|Objectivity/DB[4]. This does not allow for stor-age of the functional form itself. The approach is to store the coecients in thedatabase, along with knowledge of the name of a transient class which contains the4encoding of the functional form appropriate to those coecients. In addition, theusage of the database in BaBar dictates that the database be completely decoupledfrom client code.The AbsCalibrator class contains the pure virtual functions which take a Clusteras input and return the corrected energy or position of that cluster according to thecalibration information contained within the class. This class is then used by Candobjects to calibrate the Clusters they contain. The functional form of the calibrationis described by subclasses. Verication of new versions of a particular calibrator isperformed by means of a virtual function whose default implementation is to checkthat the new calibrator is of the same type, has the same length and the constantsare within 20% of the previous set. More complicated verication procedures maybe implemented by subclasses.The CalibratorP class contains a persistent array of coecients for a given cali-bration function, a persistent string which contains the name of the transient class(the AbsCalibrator derivative) to which these constants pertain, and a third stringto describe the algorithm used to derive the constants. Subclasses of CalibratorPpertain to dierent algorithms and dier from the base class only in the content ofthe algorithm name string.The interface between clients of the AbsCalibrator class and the database is pro-vided by the CalibProxy class2. The proxy mechanism is such that a given Abs-Calibrator subclass is held by the proxy and returned on demand until either thesubclass relating to a dierent source of calibration data (referred to as an algorithmbelow) is requested, or the event time indicates that the current set of constants isout of date. Under these circumstances, the constants for a new derivative are re-trieved from the database and a new transient AbsCalibrator derivative constructedappropriate to these constants, using the information stored along with them.A CalibratorDictionary class is used to provide a persistent map between algo-rithm names and the persistent CalibratorPs. This removes the need for clientsto know about the subclasses of CalibratorP. The CalibratorDictionary is respon-sible for returning the relevant AbsCalibrator derivative to the CalibProxy. Thestring contained within the CalibratorP derivative is translated into an AbsCali-brator derivative by means of a Factory. The dictionary then loads the constantscontained in the CalibratorP object into the transient AbsCalibrator derivative.There are two aspects to the permanent storage. One is the ability to store thecoecients of the functional forms encoded in the AbsCalibrator derivatives. Thisis a relatively trivial exercise. The other is the ability to keep track of available cal-ibration algorithms and of the default calibration. To this end, a persistent capableclass AlgDescription containing the algorithm name and a ag indicating whether ornot that algorithm is the default is stored in the database inside an AlgBank object,while the transient equivalent used by client code is an AlgList. These are nothingmore than persistent (Bank) and transient (List) vectors. They are retrieved byan AlgListProxy class is responsible which obtains from the database the relevantAlgBank object pertaining to the event time. This operation is essentially the same2The Proxy mechanism borrows heavily from an initial implementation for the Silicon VertexTracker geometry by David Nathan Brown of the Lawrence Berkeley laboratory.5as that of the CalibProxy class.Derivatives of the AbsCalibAlgorithm class is responsible for generation of theconstants to be stored in the database in the form of an AbsCalibrator derivative.This object is then passed to the singleton class StoreCalibrator which performs themechanics of translating the transient AbsCalibrator derivative into the appropriateCalibratorP derivative. Each subclass of AbsCalibAlgorithmmust register itself withCalibAlgRegister which is responsible for keeping record of the available algorithmsand an indication of the default.4.1 Oine calibration: summaryThe rather complicated design described above achieves several things at once.Firstly it separates the client code (coded in terms of AlgLists and AbsCalibra-tors) from the database implementation, as required. Secondly, in the form of theAlgList/Bank object, and the CalibDictionary's map between the AlgDescriptionobjects and the CalibratorP derivatives, the extensibility of the calibration schemewhen new and more complicated algorithms become available is achieved. Thirdly,since these algorithms make no reference to time, they are by denition retrospec-tively applicable providing the information on which they are based is recorded inthe database at the appropriate time. Fourthly, by providing diering implemen-tations of the calibration functions while retaining the external code's dependenceon an abstraction, new and more complicated calibration functions can be appliedwithout needing to change external code.References[1] S.F.Schaner and J.M. LoSecco, \Object oriented tracking andvertexing at BaBar" presented at CHEP 1997, to appear in pro-ceedings, and S.F.Schaner, \BaBar's Object Oriented TrackingSystem", in these proceedings[2] E. D. Frank, R. G. Jacobsen and E. Sexton-Kennedy, \Architec-ture of the BaBar Reconstruction System", presented at \CHEP1997", to appear in proceedings.[3] E. Gamma, R. Helm, R. Johnson and J. Vlissides, \Design Pat-terns", (Addision-Wesley, California, 1995)[4] Objectivity/DB, Object Oriented Database product supplied byObjectivity Inc., Mountainview, California6

Object oriented reconstruction software for the BaBar calorimeter

Abstract

Similar works

Full text

Available Versions

CERN Document Server