ddd size

Document Sample
ddd size Powered By Docstoc
					           Muon’s hopes for the DDD

               Tim Cox (University of California Davis)
                    DDD Workshop, CERN, 08-Jul-2002
Thanks to Pawel Zych, Rick Wilkinson, Paolo Ronchese, Stefano Lapacrara, Giacomo Bruno.
                        Muon

• What IS ‘Muon’?
     - A lot of iron and a few gas detectors
• How is geometry currently described?
     - tz files (CMSIM/GEANT3)
• Where is the geometry used?
     - Simulation
     - Reconstruction
     - Trigger
     - Alignment (reconstruction & trigger)
                                            Rick Wilkinson



                        Muon Subdetectors
For precise position measurements:
• Drift Tubes (DT)
    – barrel
• Cathode Strip Chambers (CSC)
    – endcaps

For precise time measurement:
• Resistive Plate Chambers (RPC)
    – barrel and endcap
    – Primarily for triggering
                            Rick Wilkinson


Drift Tubes (DT) - Barrel
                                Rick Wilkinson



Cathode Strip Chamber (CSC) - Endcaps
                             Rick Wilkinson



Resistive Plate Chambers (RPC)
            Geometry in CMSIM

• Describes the sensitive detector volumes for
  GEANT3:
  muon.tz–materials and overall volumes
  mf.tz–forward CSCs & RPCs
  mb.tz–barrel DTs & RPCs
• Must be ‘easy’ for humans to modify.
• Contain non-geometrical parameters too.
Endcaps in ORCA(IGUANA)
   white=absorber,red=CSCs,blue=RPCs
Endcaps in ORCA(IGUANA) no iron
          red=CSCs, blue=RPCs
Barrel + Endcaps in ORCA (IGUANA)
Barrel + Endcaps in ORCA (IGUANA)
                Geometry in ORCA

• Translation matrix + Rotation matrix for each
  sensitive detector volume from
  CMSIM/GEANT3 (specify centre of volume)
  e.g. trapezoidal gas layer for CSCs
  Allows transformation between local & global coordinates
• Dimensions of component detectors
  …and so on
         CSC ORCA Geometry 1

• Each trapezoidal chamber contains 6 gas layers
• Each layer is specified in the CMSIM geometry
  so each MuEndLayer is a DetUnit for local hit
  reconstruction, and handles transformations
  between local and global frames.
• Each MuEndChamber is also a DetUnit for local
  reconstruction of track segments.
• There are 540 chambers, 3240 layers.
                                                                            Rick Wilkinson
                 CSC ORCA Geometry 2
• MuEndcapSystem
• MuEndcap (2)
• MuEndStation (4)
• MuEndRing (4 in ME1, 2 in other stations)
• MuEndChamber (18 or 36)
   • Stores MuEndSegments
• MuEndLayer (6 per chamber)
   • Stores SimHits
   • Stores MuEndWireDigis
   • Stores MuEndStripDigis
   • Stores RecHits (clusters)
• CmsMuonEndcap
   • Groups chambers into tracking DetLayers

MuEndChamberSpecs (10 types)
   • Information common to a type of chamber (gas gains, shape, wire grouping...)
MuEndLayerGeometry
   • Handles the math of tilted gangs of wires crossing trapezoidal strips
                                                                           Rick Wilkinson


         DT and RPC ORCA Geometry
                      (note the different design philosophies)

• MuBarChamber                             • MRpcDetector
   – Stores SimHits,                         – MRpcGlobalReader
   – Stores Digis                                     – stores all Digis
   – Stores RecHits (segments)
                                           • MRpcChamber
• MuBarSL
                                           • MRpcDetUnit
   – 2 superlayers measure f
                                              – 1, or sometimes 3 per chamber
   – one measures r
• MuBarLayer                                  – Stores SimHits,
   – 4 layers in a superlayer                 – Can fetch Digis
   – RecHits to be added here                 – Stores RecHits (clusters)
• MuBarWire
• CMSMuonBarrel                            • CMSMuonRPC
   – Groups into tracking layers              – Groups into tracking layers
                                                                Rick Wilkinson

                              DetUnits
          DetUnit is the detector class where the data are stored.

                                     Det



                                   DetUnit


      MRpcDetUnit     MuBarChamber         MuEndLayer    MuEndChamber


LocalPoint toLocal(const GlobalPoint &);
GlobalPoint toGlobal(const LocalPoint &);
SimDet * simDet(); // can be used to get SimHits
DetUnit::RecHitContainer recHits();
        Digitization of CSCs in ORCA
• Digitization requires Strips & Wires be implemented –
  geometry is not described in tz.
  Typically 80 strips per layer. The wires are read out in groups.
• Many parameters required
  e.g. strip & wire description and bundling, physics modelling,
  electronics behaviour…
  Currently, some are
       - in mf.tz
       - SimpleConfigurable’s
       - hard-wired in code
       - in stand-alone files
  We hope to rationalize this using the DDD.
Paweł Zych for CMS Warsaw                                       RPC and DDD

                        Present RPC geometry
 ¯ simplified comp. to real one, but good and fast enough for the RPC trigger

 ¯ RPCs placed inside MUON volumes

 ¯ the whole view of RPCs (sensitive volumes in pink):




8 July 2002                           1                       DDD Workshop
Paweł Zych for CMS Warsaw                            RPC and DDD




       Present RPC geometry - details in the barrel
 ¯ RPCs in the barrel made of :BOX volumes




 ¯ RB1/0in : XY view:                   ZX view:

 ¯ sensitive volumes in pink



8 July 2002                         2              DDD Workshop
Paweł Zych for CMS Warsaw                                     RPC and DDD




     Present RPC geometry - details in the endcaps
 ¯ RPCs in the endcap made of volumes :TUBE, :TUBS, :TRD1




 ¯ RE1/1: XY view:                     ZR view:

 ¯ sensitive volumes in pink



8 July 2002                        3                        DDD Workshop
Paweł Zych for CMS Warsaw                                        RPC and DDD




         RPC geometry in OSCAR (OO simulation)
 ¯ Geant4 geometry (OSCAR) constructed from CMSIM’s .fz files (Geant3)

 ¯ some bugs found:
      RE1/2 chambers visible only in one half (problem with offsets in :TUBS)
      different construction of - endcap comp. to CMSIM

 ¯ at present everything solved

                 Hints for RPC geometry in DDD
 ¯ be careful with division of :TUBS volume into pieces in
   (offsets different in G3 and G4)



8 July 2002                           4                        DDD Workshop
             RPC geometry and digitization
                                   Giacomo Bruno

        Weak points currently                            Developments

•   Single gap detector (consequences on      •   A prototype for a more realistic RPC
    efficiency and cluster size)                  has been Implemented in GEANT3
•   No spacers (10 cm pitched grid of              – Double gap
    cylinders covering 1-2% total active           – All material simulated in correct
    surface. Still an open question whether            amounts
    it is worth implementing them.)           •   Preliminary results show significant
•   In the barrel chambers there is no RPC        differences in the distribution of
    subdivision into separately readout           secondaries.
    modules – splitting of DetUnit            •   Digitization code based on recent
    hardwired in the digitization                 test-beam results for this “new”
•   Wrong distribution of material and no         DetUnit will be ready soon.
    external aluminum bars.
     RPC reconstruction and digitization
                                 Giacomo Bruno
    Info used in current code              Additional info nice to have

•   Local to Global transformation      For each chamber:
•   Chamber dimensions                  • Map of spacers
•   Number of strips per chamber        • Active gaps
                                        • FE location (which end)
•   Only for digitization: one global   • Dead strips
    value for:                          • Efficiency
     – (Average) Efficiency             • Cluster size
     – Cluster size                     • Noise
     – Time resolution                  • Noisy strips
     – Noise                            • Applied HV
                                        • FE thresholds
           What DT want from DDD
                       Paolo Ronchese


• Avoid hard-coded numbers when possible.
• Three classes of information, describing:
  (i) global characteristics of Barrel DTs,
  those not depending on specific part.
  (ii) parts of the detectors.
  (iii) detector behaviour.

  All Muon subdetectors have similar concerns…
            DT global characteristics
                       Paolo Ronchese


• Wire separation (to compute position of each wire.)
• I-beam thickness (to account for dead material between
  cells.)
• Signal propagation speed along wire (add to drift
  time.)
• ‘Other things’ not yet thought of…
                         DT parts of detector
                                        Paolo Ronchese
•   For storage & retrieval, parts identified by a numbering schema or string:
    the 250 chambers are rigid objects labelled by wheel id, station id, sector id.
    Each chamber is assembled from 2, 3, or 4 superlayers.
•   Chamber: described by
    dimensions (3-vec), position (3-vec), orientation (3x3 matrix), superlayer no (2,3,4)
•   Superlayer: described by
    position (3-vec), orientation (3x3 matrix), 's.l. type identifier' (number or string)
•   Superlayer Type: type id specifies a set of superlayers with common specs.
    Described by dimensions (3-vec), theta/phi type, no. of layers (4 for all superlayers)
•   Layer: described by wire length, position (3-vec), orientation (3x3 matrix), no. of wires,
    position of first wire (a number).
•   Possible in future: cell-by-cell data store, with each wire identified by 6 numbers: wheel
    id (-1 -> +1), station id (1->4), sector id (1->12), s.l id (1->ns), layer id (1-> nl), cell id (1-
    > nc) (ns, nl, nc depend on previous params.) e.g. mean tof from beam crossing to cell
•   Possible in future: 'other things’…
       DT detector behaviour information
                                  Paolo Ronchese

• Information for functions returning drift time and resolution
    depending on distance of hit from wire, angle, magnetic field, ...
    The functions account empirically for various effects affecting the drift time.
•   IMPORTANT: The   functions themselves may change when a
    different description of the detector behaviour becomes
    available. So just writing coefficients of a polynomial function into the DDD
    may not be the best way to handle things. The functional forms may change
    so the whole description needs to be included.
•   Seems most logical to hard-code parameters with the algorithmic
    representation since they only make sense together.
•   Do other subdetectors have similar problems and if so how are they
    handled?
       Summary 1 - Muon Geometry
• We (= DT, CSC, RPC) are basically happy with
  existing geometry for digitization and
  (simulated) reconstruction.
• But we all expect to make some modifications
  and additions to improve modelling.

  The DDD should allow us to improve detailed modelling.
       Summary 2 - Muon Alignment
• How does this mesh with existing geometry?

 e.g. Endcaps should be independently (mis)alignable.
 Currently -z is a mirror image of +z so we need looser
 constraints on nominal symmetry.
 Stations (disks) probably positioned to a few mm precision?
 Chambers to better than 1 mm?

 The two endcaps probably require independent geometries.
          Summary 3 - Muon Trigger
• Can the existing geometry suffice?

  We don’t have a way of entering alignment corrections to the
  nominal geometry. This will be required by L1 CSC Track
  Finder hardware: designed to handle shifts up to about 1 cm.
  Required precision is 1mm or better for required pT resolution
  and rate reduction (Darin Acosta)

  We need a mechanism to handle alignment corrections.
      Summary 4 - Muon Parameters

• All muon subdetectors have numbers, constants,
  parameters, variables…which seem to belong in
  DDD.
  How to access these values without coupling unrelated modules
  together? Careful layering?
• Can algorithmic information be stored in DDD?
  e.g. Barrel Muon DT drift-time functions. How do other sub-
  detectors handle this?