From ajw@cithe305.cithep.caltech.edu Wed Nov 15 17:42:30 1995 Date: Wed, 15 Nov 1995 17:39:28 -0800 From: ajw@cithe305.cithep.caltech.edu (Alan Weinstein) To: cleo3-tracking@lns598.lns.cornell.edu Subject: Organizational thoughts on CLEO III OOP tracking code Hi CLEO III tracking enthusiasts, Now that Paul Kunz' lectures are over, I know you're all psyched to put your OOP knowledge to the test by getting involved in cleo iii tracking code! ____________________________________________________________________ Here's a long note with "organizational" thoughts on CLEO III OOP tracking code. I invite your comments and participation! Contents: A) Definitions of basic classes/structures/relationships B) Institutional memory C) component projects D) calibration _______________________________ A) Definitions of basic classes/structures/relationships Begin by taking the Big picture approach: specify the *kinds* of objects, algorithms, and data structures that define the problem, and the relationships between them, before even defining the objects themselves. A1) Eg: tracking objects (a brief outline, to stimulate discussion): TrackingSystem Detector (DR or SVD) Layer Element (wire or wafer/strip) RawDataEvent Hit - pointer-to-element, TDC, ADC, status-word ReconTrackEvent TrackFinder TrackFitter TrackSegments Track TrackProjection (to RICH, CC, MU) Vertex PrimaryVertex VeeVertex SecondaryVertex (eg, D -> Kpipi) ReconParticle (Eg, D -> Kpipi0) GraphicsPicture GraphicDetectorElement GraphicHitElement GraphicTrackElement Constants Geometry FixedGeometry Corrections (pitch/yaw/roll, squash, etc) TimeDistanceRelation FixedTDR Corrections (PH, attack angle, z-dependent, etc) dE/dx FixedDEDX Corrections (temp/pressure, attack angle, z-corr, etc) A2) To proceed, we need to decide, at least provisionally, on one set of objects that we can begin to work with, and put them into cvs in /cleo so that we all have access to them. They should be accompanied by thorough DOCUMENTATION, so that we know how to use them without reading every file. At this point, we need not worry too much about implementation, eg, what track parameters we want to use, etc. We need only know how to use the objects. We can change their internal guts, for better optimization, at some later time. A3) I know of 4 different efforts: - Work by Mike Marsh at Illinois, for which these objects have been defined. See, eg, http://www.hep.uiuc.edu/cleo/tracking/index.html - Work by Mike Ogg & students at UTA... - Work by Steve Schaffner, and by the BaBar tracking group. Steve, any chance you can make your code available for perusal? - Work by Nobu's student Michael Smyth on a C++ library for SVD tracking. Nobu has his very interesting master's thesis. The code is in: /home/axp/nk/dlib/mscl area; The graphics part does not compile well... I gather that Ogg will be visiting Illinois in the next week. I propose that we do our homework before then. I'd like to talk with them by phone during that visit (anyone else interested?). Then have a meeting shortly thereafter, maybe in the contecxt of CSSC, to discuss the objects and decide on a provisional set. A4) Important principles relevant to our task From Frank Wuerthwein: -- Monte Carlo generation, event reconstruction, event display, detector monitoring, etc. all should ideally use the same framework. The geometry information, for example, is owned by a fixed set of animals no matter where it is used. -- Generalized abstract classes E.g.: A superclass Hit should be the same for all tracking devices. Similarly for Layer and TrackingSystem. Why? You should be able to do tracking without having to know what device the hit is on, or the layer is in. And you should be able to swim a MC generated "track" through the detector layer by layer without knowing what the layers are. The layers do then do the work of generating the interaction between particle and detector (actually, the stuff the layer is made of will do that for you). There are many other examples of the utility of abstract superclasses in the tracking problem. From Mike Ogg: -- reconstruction code (not just tracking) shouldn't have compiled-in data, or go get a calibration constant. There should be a calibration distributed object (owned by a calibration service), and anyone who needs it, subscribes to that object. So now your class libraries should be CORBA aware where necessary. A5) Class libraries: Mike Ogg advocates the use of STL (Standard Template Library) to aid in the design. STL is expected to be a part of the ANSI/ISO C++ Standard, and so could be used by us with impunity. Info: http://www.nile.utexas.edu/Nile/components/software/C++.html http://www.cs.rpi.edu/projects/STL/htdocs/stl-new.html Another commonly used class library is CLHEP. Header files can be perused in /usr/local/include/CLHEP. One might also begin by using Gismo classes (ftp://ftp.slac.stanford.edu/pub/sources/gismo-5.0.0.tar.Z) to set up the detector geometry. And then learn from there while adding onto it. This is dangerous, however, if we find, after a while, that we don't want to use or support Gismo! A6) An aside on C++ dogma: C++ allows you to do both top-down and bottom-up development. It's useful to proceed on both fronts. The strength of top->down OOA/D is that you end up with a logically-designed system with little wasted time. The danger of top->down OOA/D is that you have little to show for your work during the long lead time. Furthermore, I contend that one learns things during IMPLEMENTATION that are difficult to anticipate during analysis/design, so that implementation should proceed in parallel, even if it only produces throw-away code. So, I propose we approch the problem from both ends. People who are already C++ savvy can help define the objects and write a driver, like List i; while ( i.FindNextTrack(); ) (FindNextTrack() can be any algorithm you like; the algorithm is a base class inherited by FindNextTrack; the algorithms should be plug 'n play); while those of us who are still learning can write (throwaway) code to implement and test algorithms, such as a Kalman fitter (or a wrapper around Anders' Fortran code). _______________________________ B) Institutional memory: I propose that we assign, as homework to members of our group, the tasks of interviewing CLEO-II tracking wizards AND members of the larger HEP community (incl BaBar, LEP, CDF...) to accumulate (and fully document) info on: - pattern recognition algorithms: - dictionary techniques ("digital" segment finding, ala trigger) - "analog" segment finding - segment clustering in parameter space - segment association in real space (SLD, link-tree, BLT, road, etc) - separate segment clustering in A,U,V, versus "global" clustering - neural net approaches - road method and other non-segment-based methods - algorithms for curler detection, merging of curler tracks into one track - algorithms for the detection of kinks, bad tracks, etc - track fitting algorithms. I believe one can assume that the Billoir Kalman filter approach is optimal for the treatment of multiple scattering, which dominates our curvature resolution. Variations or alternatives should be explored. - Vertex fitting algorithms - elements of offline calibration (see below) - display technologies (Paul Avery has that one covered) - elements of performance monitoring (see, for example, /home/ajw/cssc/billoir.ps) - data & geometry representation (by which I mean the OBJECTS discussed above) - Anything else? Please volunteer for these tasks. Otherwise, I will find volunteers (mainly, me). IT IS ESSENTIAL that the results of these interviews be documented, to maintain institutional memory! _______________________________ C) Component projects We will shortly want to divide up into small groups specifically for writing tracking code. We need to concentrate on all relevant tasks; I encourage you to volunteer! I'd like to see names attached to all tasks within a month!! - pattern recognition This is the fun part; everyone wants to do this. Perhaps we'll have 2 or more parallel efforts. I'm sure that Illinois will want to pursue the dictionary approach, maybe for segment finding AND segment linking (BLT). I would like to pursue "analog" segment finding and clustering in parameter space, separately for A,U,V. We should explore clustering methods such as link-tree, BLT, or maybe some general code that we can find in a c++ library, as Nobu did for CCFC. - Track fitting (Billoir, other) Perhaps we could begin with a simple FORTRAN->c++ translation of the RydFitter. It would be a good way to learn c++ (bottom-up); one might have to throw it away when the class structure is further defined... - calibration - lots of homework needed, here. See /home/ajw/cssc/calibration.ps - performance evaluation. See /home/ajw/cssc/billoir.ps - display - Paul Avery is into this - interface to CLEOG for testing c++ code. This needs to be developed ASAP. - Vertex finding/fitting (primaries, Vees, mass-constrained fits, etc). - Others? _______________________________ D) Calibration: I will do some homework and interviewing, and assemble a document intended to THOROUGHLY outline the elements of offline calibration we'll need, including all relevant formulas and techniques. An evloving document can be found in /home/ajw/cssc/calibration.ps.