[Halld-offline] Truth info from BCAL hadronic showers

[Paul Mattione]

In this particular event, are there any particles in DMCThrown that are shown as decaying from this pion?  Or are they truncated from the DMCThrown output?  Is it possible / would it be useful to re-enable their output for debugging purposes?  Do/would they have a time/location in DMCThrown that would correlate with the extra hits?  

 - Paul

On May 29, 2014, at 6:47 PM, Richard Jones wrote:

> Hello Will and all,
> 
> Once a primary particle has entered the BCAL and had its TruthShower recorded, it is marked with a spot of red dye (colloquially). Any secondaries that are generated from interactions by that particle inherit its red spot, even if they escape from that module and enter another one.  However, these late interactions typically are generated by delayed decays of muons from pi decays, aren't they?  Typically that is what makes late hits in a calorimeter, if my memory serves me correctly.
> 
> -Richard J.
> 
> 
> On Thu, May 29, 2014 at 6:32 PM, Will Levine <wilevine at andrew.cmu.edu> wrote:
> Hi offline,
> Following up on the issue of "late" energy deposition in hadronic
> showers in the BCAL.
> 
> There are two different ways that BCAL truth information from hdgeant
> is stored: these can be accessed in JANA from the DBCALTruthShower and
> the DBCALTruthCell objects. The code that stores this information is
> in hitBarrelEMcal() in
> sim-recon/src/programs/Simulation/HDGeant/hitBCal.cc
> 
> As I understand the code, DBCALTruthShower records every particle that
> geant tracks thru the BCAL (with energy greater than 1 MeV). One
> DBCALTruthShower for each unique particle in the BCAL. This includes
> all secondary shower particles. The particle type, initial energy, and
> initial position in the BCAL is recorded for each particle.
> 
> DBCALTruthCell just records the energy deposited in a given BCAL cell
> without recording which particle was responsible for the energy.
> (Again this is "truth" information, before any detector resolution or
> readout effects are incorporated).
> 
> These two sources of information are not always tremendously helpful.
> For example in one single-pion event that has some characteristic
> "late hits", we see the following DBCALTruthShower's:
> 
> DBCALTruthShower:
>  ptype: track: primary:    phi:      r:     z:     t:     p:     E:
> -------------------------------------------------------------------
>      8      1        1  -1.863  65.042  185.3  4.780  0.571  0.588
> 
> Only the primary pion is recorded. There is no record of any secondary
> tracks. But when we look at the TruthCell's in the same event:
> 
> DBCALTruthCell [truncated]:
>  module: layer: sector:     E:       t: zLocal:
> -----------------------------------------------
>      34      1       1  0.006    71.31    -6.0
>      34      1       3  0.027     4.87   -24.4
>      34      1       4  0.002     4.79   -26.5
>      34      2       1  0.006    33.59   -16.9
>      34      2       2  0.018     5.07   -19.6
>      34      2       3  0.013     4.98   -21.7
>      34      3       1  0.020    28.91   -15.4
>      34      3       1  0.005  4301.28   -19.1
>      34      3       2  0.023     5.19   -16.6
>      34      4       1  0.029     6.45   -13.1
>      34      4       1  0.019    73.07   -13.0
>      34      4       1  0.004  2219.77   -13.3
>      34      4       1  0.039  4301.12   -15.0
>      34      5       1  0.017     8.24    -9.6
>      34      5       1  0.001  4301.19   -17.1
>      34      7       1  0.011    10.44   -21.4
> 
> The time is in the second-to-last column. The "on-time" hits have t ~
> 5 ns. Where are all the late hits coming from? It is not clear. There
> must be some tracks that are not recorded in the TruthShower info.
> 
> Even in events with a more extensive record of secondary tracks it's
> not clear what is responsible for a late hit:
> 
> DBCALTruthShower:
>  ptype: track: primary:    phi:      r:     z:     t:     p:     E:
> -------------------------------------------------------------------
>      8      1        1  -2.072  65.042  186.4  4.812  0.572  0.589
>     13     22        0  -2.083  65.969  188.5  5.185  0.284  0.982
>     14     21        0  -2.083  65.969  188.5  5.185  0.040  0.939
>     13     20        0  -2.083  65.969  188.5  5.185  0.173  0.955
>      3     19        0  -2.081  65.814  188.1  4.879  0.005  0.005
>      3     19        0  -2.083  65.851  188.2  4.884  0.002  0.002
>      1     19        0  -2.083  65.852  188.2  4.884  0.001  0.001
> 
> Any ideas?
> 
> Will
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline
> 
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20140529/584259a1/attachment-0002.html>