Revision as of 12:42, 13 October 2011

Things to do and learn from tracking

• Need to define input and output data structures for tracking code
  • Output from tracking should be standardized so we can easily compare

• Algorithms to try
  • Xin's progressive tracking
    • 3D (present)
    • 2D (track x,y separately and combine)
  • Tree search
  • Mindy's code
  • Others

• Condiderations
  • With and without magnetic fields
  • With field, is there p dependence
  • GEM clustering dependence
  • Calorimeter and other detector information
  • Potential improvements
  • Dead areas in GEMs

• Benchmarks
  • Tracking rate
  • Tracking efficiency (#of real tracks reconstructed/# of real tracks)
  • Effect of noise in fits (hits replaced with noise)
  • Pure noise tracks (ghost tracks)
  • Multi-track reconstruction efficiency
  • Helicity dependence of reconstruction (efficiency *and* quality)
  • Noise correlation between planes effects

• Benchmark conditions to map
  • Background rates 0 - x5
  • Background rate derivatives (for helicity dependence)
  • Uncorrelated - correlated backgrounds
  • Readout strip configuration: x/y vs. r/phi

Tracking Roadmap

• Input and output
  • Develop GEMC banks output standards
  • Create implement GEM hit <-> banks interface for digitization code
  • Create library for loading banks output, clustering for tracking code
  • For library, interface with Hall A analyzer, ROOT output

• Can be done in parallel:
  • Implement other algorithms
  • Evaluate benchmarks

Xin's comment on 2011/09/21

http://hallaweb.jlab.org/12GeV/SoLID/download/tracking/for_Nilanga.pdf

GEM module's geometry and material

SBS code is at http://www.iss.infn.it/cisbani/atmp/gemc/code/

The GEM module construction is borrowed from SBS mc code as described below.

 * Describe the single GEM Chamber module (similar to COMPASS)
 * see: "Construction Of GEM Detectors for the COMPASS experiment", CERN Tech Note TA1/00-03
 *
 * HoneyComb
 *  0   NEMA G10 120 um
 *  1   NOMEX    3 um
 *  2   NEMA G10 120 um
 * Drift Cathode
 *  3   Kapton 50 um
 *  4   Copper 5 um 
 *  5   Air 3 mm
 * GEM0
 *  6   Copper 5 um
 *  7   Kapton 50 um
 *  8   Copper 5 um
 *  9   Air 2 mm
 * GEM1
 * 10   Copper 5 um
 * 11   Kapton 50 um
 * 12   Copper 5 um
 * 13   Air 2 mm
 * GEM2
 * 14   Copper 5 um
 * 15   Kapton 50 um
 * 16   Copper 5 um
 * 17   Air 2 mm 
 * Readout Board
 * 18   Copper 10 um
 * 19   Kapton 50 um
 * 20   G10 120 um + 60 um (assume 60 um glue as G10)    # not implmented yet
 * Honeycomb
 * 21   NEMA G10 120 um
 * 22   NOMEX    3 um
 * 23   NEMA G10 120 um

GEM response

For background study, I use FLUX bank which records every single hit,

The FLUX ID is like 1x000yy where x of 1-6 or 1-4 is for the GEM plane number, yy of 01-23 is for GEM module layer number.

Then I use the approach Evaristo Cisbani used in SBS code as following

the idea is basically the following:

 1- a particle that releases energy (at least able to generate a
ion-electron pair) in the drift gap (layer 5 in JTrackGEMModel.cc) is
assumed to produce a hit in the GEM detector plane and to give a
detectable signal.

 2- you can also consider deposited energy in the first GEM-GEM gap (the
closest to the drift gap, is layer 9 in JTrackGEMModel.cc); in this case
the ionized electrons miss the first GEM multiplication however signal
could be large enough to produce a detectable hit if the primary
ionizations are enough (say at least 5 ion-electron pairs)

Therefore, particles that have: Edep>W in drift or Edep>5*W in first
GEM-GEM gap provide a hit signal and can be considered as background; W
is the effective average energy needed to produce one ion-electron pair
(e.g. 26 eV for Argon).