1. Tracker Upgrade Simulations Software Harry Cheung (Fermilab)

2. 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 H. W. K. Cheung (FNAL)

3. 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 H. W. K. Cheung (FNAL)

4. 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 H. W. K. Cheung (FNAL)

5. 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 H. W. K. Cheung (FNAL)

6. 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 H. W. K. Cheung (FNAL)

7. 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 H. W. K. Cheung (FNAL)

8. 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 H. W. K. Cheung (FNAL)

9. 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!
Trigger Upgrade Workshop, 23 July H. W. K. Cheung (FNAL)