Difference between revisions of "Analysis Miscellaneous"

Revision as of 22:54, 15 September 2014

Tricks for saving time and memory

• Change the binning and/or range of the built-in histograms after constructing the corresponding DAnalysisAction object.
• Because there may be many DParticleCombo objects for an event, perform as many cuts as possible prior to kinematic fitting.
  • This includes extremely-loose cuts (well beyond the range at which your final cut will be) on all of the physical quantities of interest (e.g. mass peaks).
• To branch an analysis, create a new (but identical) DReaction object (with the same DReactionStep pointers), then simply repeat or change any of the DAnalysisActions.
  • If the DReactionStep objects are re-used, the framework will realize that the DParticleComboBlueprintStep objects will be the same, and will simply reuse them.
    • Note that the DParticleCombo objects will not be identical since they will contain a pointer to a different DReaction.
    • If the kinematic fit type is also the same, it will skip the kinematic fit of the new DParticleCombo objects entirely and just copy the previous results since they will be identical.

RF Beam Bunch Selection & PID Details

Discussion / Summary

• During experimental running, the event start time is not measured. We have the (excellent resolution) time of an RF beam bunch (DRFTime), but we don't know which bunch caused the triggered event. RF bunches from the accelerator arrive every 2.004 ns, so the time of the event-causing RF bunch is +/- N*2.004 ns from this number (N = some integer).

• To select the event-causing RF bunch (DEventRFBunch), the start-counter hit-times for all tracks with good tracking FOM (within +/- 5 sigma) are used. The tracks "vote" on an RF bunch, and the bunch with the most votes gets selected.

• The track and shower times are then compared to this DEventRFBunch time to calculate the PID FOMs.

• However, some junk and accidental tracks will vote, occasionally throwing off the event start time, and causing good events to fail PID cuts. Therefore, during an analysis, the RF bunch is re-selected separately for each particle combination, using only the tracks and showers in that particle combo (DEventRFBunch, "Combo"). The track/shower times from the BCAL/TOF/FCAL/SC are propagated to the beamline and are averaged to select the correct RF bunch.

• The charged track (DChargedTrackHypothesis, "Combo") and neutral particle (DNeutralParticleHypothesis, "Combo") PID FOMs are recomputed using this new RF time. It is these objects that are ultimately saved to the DParticleCombo "PreKinFit" object.

• To select the possible DBeamPhoton's for the particle combinations, their times are compared to the DEventRFBunch for each combo. The cut used is adjustable through the DReaction, but should be no smaller than +/- 1.002 ns. All DBeamPhoton's within this time window originated from the same RF bunch, and thus each could have caused the event. This multiplies the number of particle combinations.

RF- & Beam-Related Classes

For all of the objects below, the time & position are reported for when the beam (would have) reached the target center:

• Tagger Hits:

1. DTAGMHit: Hit-level tagger microscope objects.
2. DTAGHHit: Hit-level tagger hodoscope (fixed-array) objects.

• Beam photons:

1. DBeamPhoton: Now built from DTAGMHit and DTAGHHit objects, is smeared
2. DBeamPhoton, "TRUTH": True (unsmeared) photon energy/time data.
3. DBeamPhoton, "MCGEN": The true photon that generated the event (as opposed to the EM background photons)

• RF time:

1. DRFTime, "TRUTH": The true start time of the event (propagated to the target center) (same as DBeamPhoton, "MCGEN")
2. DRFTime: For MC data, the simulated "measured" value is ~0. The actual time is +/- 2.004*N this value.

• RF Bunch:

1. DEventRFBunch, "Thrown": The RF bunch that was selected
2. DEventRFBunch, "TRUTH": The reconstruction software's best guess for the RF bunch (time) that started the event.
3. DEventRFBunch, "Combo": The reconstruction software's best guess for the RF bunch (time) that started the event for each particle combination.

How (Default Tag) RF bunch selection works for an event

• In DEventRFBunch_factory: Use (in order of preference) (need at least one of):

1. Tracks with good tracking FOM: SC hits
2. Tracks with good tracking FOM: BCAL/TOF/FCAL hits
3. All Tracks: SC hits
4. All Tracks: BCAL/TOF/FCAL hits
5. All Neutral Showers (assume all PIDs = photon)
6. Use original DRFTime and set DEventRFBunch::dMatchedToTracksFlag to false

• Vote: select the RF bunch that matches the most times. The RF bunch times are the DRFTime +/- multiples of 2.004 ns.

How (Combo Tag) RF bunch selection works for each combo

• In DEventRFBunch_factory_Combo:

1. For each charged track in the combo, calculate its start time (from BCAL/TOF/FCAL hits)
2. For each photon shower in the combo, calculate its start time (use weighted avg vertex-z of charged tracks)
3. Calculate the weighted average start time from the above times.
4. Select the RF bunch that is closest to this time.

How DChargedTrackHypothesis PID FOM calculation works

• Determine the track start time:
  • Try: match the track to its RF bunch using the method described above.
  • Else try: use the DEventRFBunch RF time if it was matched to other tracks.
  • Else try: use the measured track t0 time (ST, CDC) (will fail if t0 time = t1 time (e.g. both CDC (e.g. no ST/TOF/etc. hits of any kind)))
  • Note: each track may match to a different RF bunch: this allows the correct PID to be determined for background tracks originating from nearby beam buckets.
• Propagate both the TOF/BCAL/etc. time and the RF time to the track vertex, and compare them to calculate FOM.

How DNeutralParticleHypothesis PID FOM calculation works

• Propagate photon shower times to the target center, compare them to the DEventRFBunch time. PID FOM is disabled for massive showers (e.g. neutrons).