CHEP 2000

1
North American Linear Collider Detector
Simulations

• Use New Tools for Analysis
• using Root for simulation analysis and FastMC
• using JAS for all phases
• see Tony Johnsons JAS talk
• Lessons learned

• Full Simulation
• flexible geometry specs within some constraints
• Gismo for simulation tool
• versatile output
• full MC record of digis
• platform support MC Farms

2
LCD Road Map
Generator(s)
fastMC (JAS)
Gismo
fastMC (Root)
Root parser
JAS parser
JAS parser
Root parser
Full Recon
JAS analysis
3
Gismo Full Simulation

• Reasonably full-featured full simulation package
  - C
• complex geometries
• EGS GHEISHA
• cutoffs set at 1 MeV
• multiple scattering, dE/dx, etc
• Generator input from /HEPEVT/ via FNAL STDHEP I/O
  package
• Digitization supplied by user
• tracking
• hit points at tracking/VXD layers
• calorimeters
• total energy per channel
• muon strips
• all digis have full MC record

• Output to ascii file (current)
• allows parsers to translate to JAS Root for
  further analysis/processing

4
Sample 5 GeV m
5
Full Sim Geometry Elements

• Most detector types are cylinders
• input by ascii detector file
• trackers and calorimeters can have inner/outer
  skins and endplates
• tracker/VXD layers can be individually positioned
  and sized
• user sets longitudinal cell composition
  (multi-materials allowed) and sensitivity for
  calorimeters
• special shapes added in with parameters to
  describe their variations
• conical masks configurable
• compound beampipe

6
Two Detector Designs

• Large (v. L1, L2)
• large!
• Large tracker
• optimal tracking resolution
• Large calorimeter
• optimal separation of clusters
• size limits B field
• may limit vertex detector inner radius due to
  ee- pairs

• Small (v. S1, S2)
• small!
• Small detector
• larger B field possible
• Small calorimeter
• allows high granularity (Si/W)
• Small tracker
• Si strips/drift
• large B field
• better containment of pairs, closer-in vertex
  detector

7
S1
L1
Pb-scint EMHAD cal
Coil
Fe Muon Sys
Cu-scint HAD cal
W-Si EM cal
Fe Muon Sys
Coil
144 lyr TPC
Pixel VXD
6-lyr Si drift
Pixel VXD
B3T
B6T
8
Small Detector Central Detector
3 Tracker Doublets 1.1 mm G10, 600 mm Si r 14,
42, 71 cm 5 EC Tracker disks z 31, 61, 91,
121, 149 cm inner r follows cosq0.99 Luminosity
monitor (Si/W) active from 30-116 mrad
9
Barrel/Endcap Region

• ltEgt 15 lower than barrel
• s/ltEgt 15 higher

B/EC
Small
(note different scales on plots)
Barrel
10

Small
EM Cal
ee- ZZ
Si Tracker hits
11
Large
ee- ZZ
TPC hits
EM Cal
12
What You Get from FullSim

• Tracking
• hit ID
• (x,y,z) of trajectory crossing layer
• layer DE
• ptr to MC parent
• hit smearing held off until recon
• Calorimeters
• hit ID (contains location)
• total energy deposited
• list of (MC parents, DE)

• MU Strips
• hit ID (contains location)
• list of MC parents
• Full MC Truth Table
• (x,y,z) at termination point
• initial (px, py, pz)
• type charge
• pointer to parent
• position momentum at Cal front face

13
LCD Event Class Structure
Event
TObjArray
Note all hits, tracks clusters have pointers
back to parent MC. Clusters have pointers to
constituent hits.
14
MC Farms Platforms

• MC Farms
• SLAC, Michigan, Colorado, Penn
• Code installed but yet to run production at
  Vanderbilt (DEC) FNAL (Linux)
• data repository at Penn
• push scripts for file transfer from farms
• server access via JAS
• ftp access for Root

• Timing
• 2 mins/event for udscb 500 GeV on 400 MHz
  Solaris
• Platforms
• AIX
• Solaris
• DEC Unix
• Linux
• call stack corruption compiler bug
• cannot optimize code
• Windows

15
Serial Input Output (SIO)
T.Waite

• The Objective
• Provide an alternative to ASCII files which are
  by nature
• Information lossy
• Non dense
• Enforce data versioning
• Easily readable from C and Java
• Not Part Of The Objective
• A full object oriented serialization engine (a la
  Root or Objectivity)

• Provides
• Architecture independent binary format (uses the
  xdr standard)
• High integrity, self checking data layout
• Multiple simultaneously open input and output
  streams
• Heterogeneous record types on each stream
• Pointer relocation (at record level)
• Data compression/decompression (per record).
• Does not provide
• Abstract data descriptions
• Pointer chasing

16
Input Why Use XML?
J.Bogart

• For 1st pass LCD used ad hoc file format,
  one-of-a-kind code for serial-only parsing of
  detector geom.
• XML is a standard meta-language for defining
  markup languages. Good free parsers exist, more
  tools coming.
• XML languages are plain-text, self-documenting.

• Appl. interface to data (XML document) may be
  serial or random-access.
• Avoid growing private file formats or, worse,
  hard-coding parameters.
• Make it easy (well, easier) for several programs
  to use same input.

17
Detector Description in XML
J.Bogart
Start subdetector description
ltlcdparmgt ltglobal filelargeParms2.xml /gt
ltphysical_detector topologylarge id L2
gt ltvolume idEM_BARREL gt lttubegt
ltbarrel_dimensions inner_r 196.0
outer_z 322.0 /gt ltlayering
n40gt ltslice material Pb
width 0.4 /gt ltslice material
Tyvek width 0.05 /gt ltslice
material Polystyrene width 0.1 sensitive
yes /gt lt/layeringgt
ltsegmentation cos_theta 300 phi 300 /gt
lt/tubegt ltcalorimeter type em
/gt lt/volumegt ...
Geometry, materials
function
End subdectector description
18
So far...
J.Bogart
To come...

• Parser (XML4C) a good choice but multi-platform
  headaches. Java version also exists.
• Wrote a thin layer of utilities to provide more
  appropriate API. So far used by (but separate
  from) simulation only. Easy to port to Java.
• Benefits of standard format, pre-existing (free!)
  tools already apparent.

• Bigger, better utility layer
• Support for other forms of input, e.g. analysis
  cuts
• Evolving specs in the XML family (DOM Level 2,
  Schemas,...) bear watching.
• Other HEP (e.g. Atlas) and astrophysics (e.g.
  GLAST) experiments are doing similar things.
  Should coordinate efforts, aim for common XML
  DTDs/schema and supporting utilities.

19
Beam Backgrounds Overlays
G.Bower

• 4000 Beamstrahlung particlesin the Small
  detector(A normal event will have 88,000/bunch
  x 95 bunches/train)

• Background particles from Guinea Pig machine
  simulation
• We plan to create a separate library of
  background events to overlay on top of the
  generator events.
• Will have to apply cuts to the GP output to allow
  a reasonable particle count
• large fraction dont get to the beampipe because
  of the B field (by design!)
• Then must overlay beam backgrounds, physics
  backgrounds and noise on top of true physics
  event

(white lines are neutrals)
20
Gismo?

• In 96. Gismo was the only OO C simulation
  package on the market
• GEANT4 only available to public in past year
• Gismo does do full simulation with complex
  geometries
• so whats the problem?

• Gismo has bugs/features that need fixing
• bug handling loopers
• MC particle chain not optimal for bremms
• no fluctuations on E loss
• and a few others
• Gismo support is down to one person in GLAST
• not so much interest in support as tool for HEP
  in general
• little or no documentation
• Future will need to include GEANT4

21
Lessons Learned

• Provide Full MC parentage for understanding
  algorithms
• Gismo sufficed for startup of project prior to
  G4, but should switch
• Hard to fully support more than one framework
• tried to support JAS and Root
• could not share code between them
• had to write everything twice
• was divisive
• should have (and will) support one fully and the
  other only as able to take output from the other.

• ee- detectors look pretty similar (except RICH!)
• not hard to define user interface (ascii file) to
  describe important features
• specialty items can be added as designs start to
  focus on details
• XML does the job nicely
• Flexible I/O needed
• must be easy to read from different analysis
  interfaces (eg C, Java)
• ascii is bad for numeric precision
• ended up with xdr-based binary I/O