Current Status of the Tracking Trigger Software Andrew W. Rose

23/07/09Andrew W. Rose2 Summary Introduction What functionality currently exists? What is planned for the coming months? Who has responsibility for the code? Is the code 'public' (in CVS, documented) or private? Is more work required in performance? What will be the issues with a transition to 3_1? Conclusion

23/07/09Andrew W. Rose3 Introduction - Disclaimer What will be discussed? Track Trigger Primitive Formats Track Trigger Primitive Generation Associated Machinery What will not be discussed? Tracker Upgrade Geometries

23/07/09Andrew W. Rose4 Introduction – Software overview (i) stackedTrackerGeometry stackedTrackerDetUnit stackedTrackerDetId TrackerGeometry SimHitpixelDigi TrackTriggerHit LocalStub GlobalStub Tracklet Hit Matching Algorithm Clustering Algorithm

23/07/09Andrew W. Rose5 Introduction – Software overview (ii) The StackedTrackerGeometry, along with the StackedTrackerDetUnit and StackedTrackerDetId, define the elements of the stacked tracker and their relationships. This description is separate from and complimentary to the standard tracker geometry.

23/07/09Andrew W. Rose6 Introduction – Software overview (iii) Trigger primitives are constructed from standard CMSSW digis or simhits (to remove digitization effects). The additional TrackTriggerHit format allows for interface with custom simulations but can also be constructed from standard digis.

23/07/09Andrew W. Rose7 Introduction – Software overview (iv) LocalStubs are built directly from hits and are stored as lists of associated hits, as might be expected on-detector. GlobalStubs are built directly from LocalStubs and are defined as points in the global geometry, as might be expected in the trigger system. There is a one-to-one correspondence between LocalStubs and GlobalStubs but the two are kept separate to distinguish the on- detector and off-detector aspects of the trigger. Tracklets are track-like objects and are built from two or more GlobalStubs.

23/07/09Andrew W. Rose8 Introduction – Software overview (v) As it is currently unknown what clustering will be available or how hits will be paired, the functionality is included through ClusteringAlgorithms and HitMatchingAlgorithms modules. These modules are in the event setup and so the selection of algorithm is made by selection of the relevant producer in the user python configuration file. Separation of the implementation of algorithms from the object producer allows for multiple developers without risk of code incompatibility, version collision, (other general nastiness…) reduces the possibility of the introduction of errors

23/07/09Andrew W. Rose9 What functionality currently exists?  What has been introduced beyond the baseline detector / trigger simulation? Discussed previously – to summarise: A navigatable geometry equivalent to the tracker geometry Data formats to contain new object types Object builders  To what extent is the code tested / validated? WRT physics: Numerous tests run by different people with results which are both compatible and sensible. WRT Computing: Ordeal by large numbers - Many hundreds of thousands of events successfully created using fastsim & fullsim, different geometries, pixel architectures, etc. There is no procedure for formal unit-testing nor a software validation suite.

23/07/09Andrew W. Rose10 What is planned for the coming months?  Are there substantial changes or additions to functionality still required? As the upgrade is a work in progress, the software is, by definition, subject to change. Changes are now usually small – backend optimizations or corrections. User interface is stable. Frequency of changes getting lower.  Are you working to a formal task list, or are things still informal? Semi-formal list of tasks is completed Software tasks now performed on an ad-hoc basis only when change is required.

23/07/09Andrew W. Rose11 Who has responsibility for the code?  Is it a team effort? Primarily 1 person (myself) responsible Others starting to take responsibility (writing algorithms, etc)  How are code changes discussed and coordinated in your group? No formal mechanism for organising software changes (eg savannah, bugzilla) As developer base is small, usual method is via directly to the responsible Widely used hypernews forum Weekly software/production meetings  How is this foreseen to evolve? As the user base is limited there are no immediate plans for this to change.

23/07/09Andrew W. Rose12 Is the code 'public' or private?  Is the code 'public' (in CVS, documented) or private? All code is in CVS: SLHCUpgradeSimulations/L1Trigger/ SLHCUpgradeSimulations/Utilities/ SimDataFormats/SLHC/ No formal documentation but much informal information: Talks Hypernews Wiki pages  What / how large is the 'user base'? Experts only? Expert base:5-10 people User base:20-40 people

23/07/09Andrew W. Rose13 Is more work required in performance? Performance is dominated by combinatorials, ie physics, rather than by software! Choice of algorithm has major effect on running time! Several optimizations made so far to improve running time E.g. Linearization of data types (c.f. associated lists) improves storage and access time  If so, what are the bottlenecks? Running without clustering can make running time rise quadratically (or worse) with occupancy!

23/07/09Andrew W. Rose14 What are the interfaces to other components of upgrade simulations? StackedTracker UtilitiesTracking Trigger DetId.h, PXBDetId.h, TIBDetId.h, TOBDetId.h Plane.h, BoundPlane.h GeomDet.h, GeomDetType.h, GeomDetUnit.h TrackerDigiGeometryRecord.h, TrackerGeometry.h GeometricDet.h DetSetVector.h, PixelDigi.h, PSimHitContainer.h, CrossingFrame.h, MixCollection.h Handle.h, Ptr.h, Ref.h DetId.h, PXBDetId.h Plane.h, GlobalPoint.h, GlobalVector.h MeasurementPoint.h, PixelTopology.h, Topology.h TrackerDigiGeometryRecord.h, TrackerGeometry.h GeomDetUnit.h, PixelGeomDetUnit.h FastHelix.h, MagneticField.h, IdealMagneticFieldRecord.h PropagatorWithMaterial.h, FreeTrajectoryState.h, TrajectoryStateTransform.h, PTrajectoryStateOnDet.h Geometry and Detector Description Tracker Object Collections Tracking tools Electron Trigger, Tau Trigger, Jet Trigger, Barrel Muons, Forward Muons

23/07/09Andrew W. Rose15 What will be the issues with a transition to 3_1? None as far as I know! Transition from 1_8_4 to 2_2_3 required only changing one data label as few dependencies on existing code (although we took the opportunity to implement entirely new data formats).  What would be the issues with a convergence with mainstream CMS releases? Could upgrade code co-exist with mainstream CMS software? No issue with convergence or coexistence. No code is replaced, everything already coexists with the standard CMSSW. N.B. This is not true for the Tracker Upgrade Geometry project but that is beyond the scope of this talk  Is this a desirable goal? No opinion either way. 2_2_6 is working well & transition to 3_1_x should cause few issues. A very small minority are still using 1_8_4. This must be discouraged

23/07/09Andrew W. Rose16 Conclusion Software is structured to allow development without modification of the existing code Any changes being made are small, infrequent and hidden from the user Both expert and user base are growing: We are an active community. Communication is direct: Meetings, hypernews and . There is currently no need for this to change Optimizations have been made and timing is dominated by physical effects. Transition to 3_1_x should be simple if it is considered desirable