[Halld-unique] DBeamPhoton objects and beam photons in DSelector tree

[zihlmann]

Hi All,
attached you find a long write up of what I tried to find out about the 
information available
in the root tress for the DSelector with regards to beam photons.
This will explain why the IsGenerated flag for a beam photon sometimes 
will give the wrong
answer. And indeed the IsGenerated flag will not always mark the 
generated beam photon because
it can happen that there is no beam photon available that relates to the 
beam photon that generated
the event.


cheers,
Beni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-unique/attachments/20210709/c1b6832b/attachment.html>
-------------- next part --------------
Beam Photons and tagger hits understanding their relations.
------------------------------------------------------------
purpose of this: understanding "True" information/concept with regards to beam photons and how the objects
DBeamPhoton are created. There are four DBeamPhoton factories, the "nominal" one without a tag that creates
beam photon ojects from tagger data (or smeared data in case of MC) and three additional factores with the
tags "TRUTH", "MCGEN" and "TAGGEDMCGEN" all related to MC data.
All DBeamPhoton factories are in src/library/PID.

A) Tagger hits are not simulated in geant like other detector hits because there is no tagger magnet implemented
   in the geometry. What are generated are beam photons at the location just before the collimator and according
   to these beam photons the electron energy is defined and an appropriate hit is created in the tagger. However,
   since the tagger acceptance is not 100% even in the region where there is full coverage because for example the
   fibers do have cladding and the acceptance is therefore not the full 3mm by 3mm squre surface.
   In addition, because the electron flight path is not simulated there are also no simulations of mulitple
   scattering or shower processes in the exit window of the tagger manget.

B) As a consequence of A), in MC data all tagger hits (truth and smeared) are generated from beam photons and these
   beam photons are NOT keept and will be lost!

C) To prevent analyzers from using "truth" information the relation ship between the beam photon responsible for
   the reaction and the tagger hit resulting from this beam photon is hidden. Form this point of view the question
   which tagger hit is related to the "true" beam photon is not allowed.


1) DBeamPhoton standard factory creates beam photons based on tagger hits either from real data or
   for smeared MC data using the objects DTAGMHit and DTAGHHit

2) DBeamPhoton TRUTH: genrates beam photons based on tagger counter "Truth Hits". All tagger "truth" hits will
   be used to create Truth beam photons. Truth tagger hits are generated in hdgeant4 in GlueXPseudoDetectorTAG.cc
   Note that the MC tagger hits are generated from MC beam photons and the MC beam photons are NOT accessible
   (see A) and B)) at all!

3) DBeamPhoton MCGEN: This code will try to produce a list with a single Beam Photon that is responsible for the
   simulated event. This is based on the tagger hits if the tagger did have a hit or other wise from the
   DReaction data directely in which case system is set to SYS_NULL.
   The code will loop over all TRUTH BeamPhotons and for each of these photons will check the associated
   "reconstructed" tagger hit (NOT TRUTH) and test the variable hit->Bg if it is set to zero.
   This flag is set to zero if the tagger hit corresponds to the beam photon that generated the event.
   If the tagger hit can not be found (does not exist) the information is extracted from the DReaction
   for what the "true" beam photon energy is.
   so MCGEN provide the "Truth" BeamPhoton that caused the event.

4) DBeamPhoton TAGGEDMCGEN: This piece of code is used for REST data to identify the beam photon that is related
   to the MCGEN beam photon. At this point the tagger hits are no longer available. The code will return NULL
   if the dSystem for this beam photon is SYS_NULL which means there was no tagger hit for "true" beam photon, or
   otherwise, it loops over all BeamPhotons (reconstructed NOT true) this is 1) and finds the best match with the
   MCGEN beam photon. The match is based on same dSystem, same dCounter and smallest time difference.
   In case for a successful match the time difference is directly related to the "smearing" of the true tagger hit
   since the MCGEN beam photon is based on "true" hit while the default beam photon is based on smeared hit.
   However if there is no DBeamPhoton available that reflect the "true" tagger hit because there was no such tagger
   hit then the timing of this matched DBeamPhoton object can by off by several bunch times. (see example below for
   event 23)

mcsmeared and rest files:
Note:
A) in smeared file all four DBeamPhoton tags present
B) the DBeamPhoton:TRUTH and DBeamPhoton:MCGEN are always the same BUT DBeamPhoton:TAGGEDMCGEN is not quite the same
   as DBbeamPhoton:MCGEN because it is "smeared" data.
   HOWEVER!, SOMETIMES THE TIMING OF DBeamPhoton:TAGGEDMCGEN IS COMPLETELY OFF BY SEVERAL BEAM BUNCHES.!!!!

EXAMPLE:
================================================================
Event: 23
DBeamPhoton:MCGEN
   E(GeV): System: Counter: t(ns):
----------------------------------
 8.690804    TAGM       24    0.0 

DBeamPhoton:TAGGEDMCGEN
   E(GeV): System: Counter: t(ns):
----------------------------------
 8.686226    TAGM       24  -24.2 

DBeamPhoton:TRUTH
   E(GeV): System: Counter: t(ns):
----------------------------------
 8.690804    TAGM       24    0.0 


C) in REST file the DBeamPhoton:TRUTH is not available anymore, but DBeamPhoton:MCGEN and DBeamPhoton:TAGGEDMCGEN are still
   present.

   
Now we look at the DReaction code  that runs over the rest files to generate the root files for the DSelector to be used.
This code is in src/libraries/ANALYSIS
The code of DMCThrownMatching class is looking at truth information for beam photons.

Note that point 3) and 4) below will not result in any action since the DBeamPhoton:TRUTH objects are not in the  rest file.

DMCThrownMatching_factory::Find_GenReconMatches_BeamPhotons()
1) all four DBeamPhoton tags are requested. -> the DBeamPhoton:TRUTH will be empty as they are not available
   from the rest file.
2) the two  pointers are set according to 1)
   const DBeamPhoton* dMCGENBeamPhoton; //the generated photon that caused the event
   const DBeamPhoton* dTaggedMCGENBeamPhoton; //the reconstructed photon that matches the MCGEN photon
3) for each DBeamPhoton loop over all DBeamPhoton_TRUTH and get the associated taggerHit for the beam
   photon and for the beam-photon-truth. A possible match between DBeamPhoton and DBeamPhoton-TRUTH is
   recored in a map with the time difference between these two objects.
4) lastly a loop over all matched pairs searches for the one match with the smalles time difference.
   map<const DBeamPhoton*, const DBeamPhoton*> dBeamPhotonToTruthMap;
   map<const DBeamPhoton*, const DBeamPhoton*> dBeamTruthToPhotonMap;
   dBeamPhotonToTruthMap = locBeamPhotonToTruthMap
   dBeamTruthToPhotonMap = locBeamTruthToPhotonMap



In DEventWriterROOT.cc the "true" beam photon is idetified by using the DBeamPhoton:TAGGEDMCGEN object, see below:
   Bool_t locIsGeneratorFlag = kFALSE;
   if (locBeamPhotonTaggedMCGEN != NULL)
      locIsGeneratorFlag = (locBeamPhotonTaggedMCGEN->energy() == locBeamPhoton->energy() &&
                            locBeamPhotonTaggedMCGEN->dCounter == locBeamPhoton->dCounter &&
			    locBeamPhotonTaggedMCGEN->time() == locBeamPhoton->time()) ? kTRUE : kFALSE;
      locTreeFillData->Fill_Array<Bool_t>(Build_BranchName(locParticleBranchName, "IsGenerator"), locIsGeneratorFlag, locArrayIndex);
   }

that means the IsGenerator flag is set for the beam photon that matches the TAGGEDMCGEN beam photon which can be
off in time w.r.t. the true beam photon that generated the event by a lot! See above example of event 23.