Tracker Upgrade Simulations Software Harry Cheung (Fermilab)

Software Methodology Goals for Tracking Upgrade Simulation Software (Re)use as much of the code in CMSSW as possible Cause zero disturbance (or confusion) for mainstream CMS code Low maintenance for upgrade code (releases) Enable upgrade simulation studies by non-code experts Common code base for meaningful comparisons of studies from different people/working groups Manage upgrade code through CVS branches Possible due to limited number of packages/files modified E.g. Hybrid B 2_2_6: changes to 16 CVS packages, 28 files total E.g. Long barrel 2_2_6: changes to 14 CVS packages, 23 files total Start CVS branch (each time!) at a stable release E.g. Strawman A and B 1_8_X branches at 1_8_4 trunk E.g. Strawman A 2_2_X branch at 2_2_6 trunk E.g. Strawman B 2_2_X branch at 2_2_0 trunk (trunk chgs merged to br) Upgrade-only files in separate SLHCUpgradeSimulations/Geometry CVS package E.g. geometry XML files, other data files, python files Trigger Upgrade Workshop, 23 July 2009 H. W. K. Cheung (FNAL)

Experience with Software Manage upgrade geometry through (limited) configurability Changed some code hardwired to standard geometry to be configurable Enabled some common code for all upgrade (conceptual) geometries Enabled (limited) configurability through job file (e.g. layer radius, pixel granularity) Changed (some) standard parameters through python job file E.g. geometry data file locations, which rechit error routine to use Use simulations in “unsupported” mode Fast Simulation studies use Fast Simulation for simhits but then proceed with normal digis, rechits and full track pattern recognition (allows correct granularity) Overall a positive experience so far with current method of working PRO: Can use all new CMSSW code and features easily Much less effort than keeping a separate copy of CMSSW for upgrades Direct connection to standard geometry code for comparisons Easier to get help from experts (Thanks to all experts for all help so far!) Surprising how much of the software can be used (thanks to Offline!) CON: needs recompile (change to e.g. data format need care) CON: Need to create new branch for each stable release Can have many changes between stable releases; even stable releases can have many revisions Continue with CVS branches at least until we have only a single geometry Now need to also work with upgrades for other subdetectors and trigger Trigger Upgrade Workshop, 23 July 2009 H. W. K. Cheung (FNAL)

Status of Simulation Software First version of Phase 1 BPIX, FPIX geometry Okay to start some studies Urgently need detailed/“real” Phase 1 geometry (is coming) Versions of Phase 2 Geometries Both Long barrel and Hybrid layouts implemented Need to get material “correct” in both geometries Need to implement detailed/“real” Phase 1 geometry Need some extra features to do robustness studies Detector Inefficiencies Extra occupancy (delta rays and in-time pileup) Configurable rechit position and position errors Trigger Upgrade Workshop, 23 July 2009 H. W. K. Cheung (FNAL)

Phase 2 Geometries We are still working on putting in the right material in these geometries StdGeo John Ellison, Avdhesh Chandra, Ivan Reid Hybrid Long Barrel Trigger Upgrade Workshop, 23 July 2009 H. W. K. Cheung (FNAL)

Tracker Simulation Software What functionality currently exists? What has been introduced beyond the baseline detector / trigger simulation? Two strawman (family of) geometries: Long barrel and Hybrid Configurable layout (# and location of layers, layer length) and granularity Fast simulation with full sim digis and full pattern recognition for tracking To what extent is the code tested / validated? Each “release tag” run through a small validation for 1K to 10K events Runs dimuon for 1K (pileup) to 10K (no-pileup) and produces good hits MultiTrackValidator efficiency and fake rates is as expected Not yet a systematic package; Not run over a large sample What is planned for the coming months? Are there substantial changes or additions to functionality still required? Implement detailed (real) Phase 1 FPIX and BPIX geometry & materials Update material budget for outer and pT layers, and fill missing support material Implement inefficiency for layers for fast sim with digis Improve hit position and errors with configurable binary or X-bit ADC readout Make occupancy more realistic (include delta rays and out-of-time pileup) Trigger Upgrade Workshop, 23 July 2009 H. W. K. Cheung (FNAL)

Tracker Simulation Software What is planned for the coming months? Are there requirements coming from users or other subsystems? From Tracking Trigger Task Force (pT layer geometry) From Layout Task Force (# for materials for layers and support/inactive) From MC Production Group (reduce memory and CPU resources) Are you working to a formal task list, or are things still informal? We have a task list posted on a twiki. The list and the work is managed by co-coordinators of the Tracking Upgrade Simulations and Performance WG. Who has responsibility for the code? Is it a team effort? How are code changes discussed and coordinated in your group? Team effort: Tracking Upgrade Simulations and Performance WG + others Coordinated by Tracking Upgrade Simulations and Performance WG co-coordinators. Members propose changes; present work/results and discuss changes at weekly technical meeting. Put in CVS after converging and testing How is this foreseen to evolve? Keep it fairly informal as long as group is small enough Implement a systematic validation process step (and default configuration) Implement a global tag for “public release” tracking upgrade packages Trigger Upgrade Workshop, 23 July 2009 H. W. K. Cheung (FNAL)

Tracker Simulation Software Is the code 'public' (in CVS, documented) or private? What / how large is the 'user base'? Experts only? Code is public, in CVS, and tagged Object of and how to use the code is documented in the WG twiki page Actual upgrade code technical details is not yet documented (Memo is planned) User consists of general users and experts from different upgrade WGs Is more work required in performance? If so, what are the bottlenecks? Memory for tracking with high PU Memory for TrackingTruthProducer and MTV with high PU CPU usage for TrackingTruthProducer and MTV with high PU Will fundamental changes (perhaps to components not touched so far) be required in the future? Reducing the above resource bottlenecks The way PU is simulated (and added) in the fast sim (for in-time pileup) What are the interfaces to other components of upgrade simulations? Interface to tracking primitive generator code Trigger Upgrade Workshop, 23 July 2009 H. W. K. Cheung (FNAL)

Tracker Simulation Software What will be the issues with a transition to 3_1? Stable enough release (3_X_X, e.g. 3_2_X?) Manpower resources (start porting at least after September 2009) Deal with iterative tracking What would be the issues with a convergence with mainstream CMS releases? Such that upgrade code could co-exist with mainstream CMS software Conflicting geometry code cannot coexist within a mainstream CMS release Conflicting geometry code can coexist in mainstream CMS code repository (CVS) as separate CVS branches Need separate release for each geometry layout (Long barrel, Hybrid) Is this a desirable goal? No, due to conflicting geometry code, and likely push-back from mainstream CMS code package admins (but separate CVS branch is okay) In isolated instances, if changes considered a fix it is included in mainstream Any other issues? Just look at task list and volunteer please! https://twiki.cern.ch/twiki/bin/view/CMS/SLHCTrackerSimuTasks Trigger Upgrade Workshop, 23 July 2009 H. W. K. Cheung (FNAL)