Background Frames

This is the plan to deal with background frames.

 G4 produces six collections that are part of this discussion.  I will give you an overview of what we do now, mostly just to establish language.  Then tell you my proposed solution.

   The first three collections are produced by G4.

ToyGenParticleCollection
 - particles that come from the event generators.
 - they do not have mother daughter history since we have no generators that have that.
   ( although we might want to add it for future proofing. ).
ToyGenParticle.hh

SimParticleCollection
  - Information about particles that were touched by G4
  - The first n particles are "copies" of the n generated particles.
  - Other particles were added by G4.
  - This collection is actually a map since there are allowed to be missing particle identifiers.
  - This includes starting point, momentum and time; ending point, momentum, time, proper time;
    codes for the production process and stopping process; mother daughter info:
  - By default we keep everything ( with limits imposed to deal with inifinite memory footprint ).
  - This class has its full mother-daughter history and it has an index back to the ToyGenParticleCollection
    if a track came from that collection.
SimParticle.hh

StepPointMC -
  - This is information about a point that is on a track and inside a senstive volume.
  - This class knows which SimParticle made it.
  - We make separate collections of these for points in the tracker, points in the calorimeter, points in the
    virtual detectors and so on.  We have even instrumented the target foils.
  - This is information available from one G4 step.  We record the position and momentum at the start of the step.
StepPointMC.hh

The StepPointMC information is processed by HitMakers/src/MakeStrawHit_plugin.cc to make data-like hit objects plus the associated MC truth information.  This is stored as three collections, all of which are the same length
and which are indexed in lock-step.

StrawHitCollection
 - The data-like object: strawId, time, energydepositiion and delta_time ( between two ends).
 - If many stepPointMC objects are in the same straw and within an appropriate time window, they
   become one StrawHit.
 - It is possible for one straw to have several hits within one event.
 - The hit maker assumes constant drift velocity over the full drift time.
 - Times are reported relative to t0=protons hitting the production target
 - The hit maker computes true point of closest approach for each StepPointMC. Drift times are computed
   relative to that point - ie no ionization stats and no diffusion.
StrawHit.hh

StrawHitMCTruthCollection
 - The truth information about the matching StrawHit
StrawHitMCTruth.hh

DPIndexVectorCollection
 - This is really part of the MCTruth information.
 - It contains "indices" back to the StepPointMC's that contributed to the corresponding StrawHit.
 - The "indicies" have two parts: a data product Id and an index within that data product. See the
   discussion of DPIndex below.  This uniquely
   identifies each StepPointMC.  It also anticipates that one day we might have multiple StepPointMC Collections.
 - We broke this off as a separate data product in case we wanted to same disk space by keeping the the
   StrawHitMCTruthCollection and dropping this collection.
DPIndex.hh

The net result is that to navigate back from a StrawHit to the conversion electron that created it you need to:
- look up the DPIndexVector object for this strawHit
- From there look back to one or more StepPointMCs.
- From there look back to one or more SimParticles
- From there look back to zero or more generated particles.

--------------------------------------

About DPIndex.
- This is the class that holds an identifier of a unique object within an arbitrary data product within the event.
- The first data member unqieuely identifies the data product.  The second data member is an index into
  that data product.
- Once we get to the new framework (named art) we will typedef DPIndex to art::Ptr. A Ptr holds the same two
  pieces of information but it also holds a pointer to the target object.  That pointer is reconsituted on
  the fly when objects are read back from the data file.  I am pretty sure that the algorithm always reconstitutes
  all pointers on readback - not cpu time efficient but definitely programmer time efficient at this stage of
  the experiment.

--------------------------------------

What do we need to do:

1) Right now the hit maker looks for exactly one collection of StepPointMC objects.  It should look for
  all of the StepPointMC collections that hold points in the tracker.  This is a fairly easy fix.
  We just need to write one outerloop around existing code.
2) The StepPointMC currently just has an int to say which SimParticle it came from. This presumes we will only
  ever have one SimParticleCollection.  We should change  this to a DPIndex/Ptr so that we may have
  multiple such collections.

3) The SimParticle class currently just has an int to say which ToyGenParticle it comes from.
  It should also become a DPIndex/Ptr.

4) Modify the Geant4 interface code to look for more than one ToyGenParticleColleciton.

5) Perform the same change as 1) for the code that makes calorimeter hits.

6) Maybe we also need to extend the GenId enum to distinguish these generated particles from various
  FastSim processes.

When those changes are in place, the overlay job becomes:
a) In each event, create additional ToyGenParticleCollection, SimParticleCollection and StepPointMCCollections
   to hold the overlay hits
b) We can do this several times for several independent background sources,
c) Tell the hitmakers to use all of the available StepPointMCCollections.
d) Deal with any file IO issues related to accessing the background hits.

One can imagine several short cuts but if the time scale is a few weeks to a month we should just do it right.

Security, Privacy, Legal