Difference between revisions of "Photon Reconstruction in b1pi events 02/10/2012"
(→Two gamma invariant Mass) |
(→Cuts) |
||
(24 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | 50,000 b1pi events. No EM background. | ||
+ | |||
==BCAL== | ==BCAL== | ||
===Thrown photons=== | ===Thrown photons=== | ||
Line 13: | Line 15: | ||
[[Image:photonEvsZ_recon_BCAL.png]] | [[Image:photonEvsZ_recon_BCAL.png]] | ||
+ | |||
+ | z is the (extrapolated) position of entry into the BCAL, not the z coordinate of the cluster itself. | ||
[[Image:photonZ_recon_BCAL.png]] | [[Image:photonZ_recon_BCAL.png]] | ||
Where does each of these peaks come from? | Where does each of these peaks come from? | ||
− | * | + | * All peaks are from noise that cause garbage timing info. The odd structure is due to the fact that I am trying to plot z at point of entry into BCAL (at BCAL inner radius). |
− | + | ||
====Cuts==== | ====Cuts==== | ||
+ | [[File:PhotonTproj recon BCAL.png]] | ||
+ | |||
* A timing cut fabs(t_shower-t_flight) < 1 ns can be applied to remove many of the extra "photons". (Red curve below) | * A timing cut fabs(t_shower-t_flight) < 1 ns can be applied to remove many of the extra "photons". (Red curve below) | ||
* I don't think low energy showers are well understood at the moment, so remove clusters with E<60 MeV. (Green) | * I don't think low energy showers are well understood at the moment, so remove clusters with E<60 MeV. (Green) | ||
Line 32: | Line 37: | ||
[[Image:photonEvsZ_recon_cuts_BCAL.png]] | [[Image:photonEvsZ_recon_cuts_BCAL.png]] | ||
− | Number of "photons" decreases from | + | Number of "photons" decreases from 211,000 to 61,000. |
+ | |||
+ | ==FCAL== | ||
+ | ===Thrown photons=== | ||
+ | [[Image:PhotonEvsTheta thrown FCAL Feb12.png]] | ||
+ | ===Reconstructed photons=== | ||
+ | [[Image:PhotonEvsTheta recon FCAL Feb12.png]] | ||
+ | |||
+ | Way too many reconstructed. Clusters matched to charged tracks '''are''' vetoed, but this has some issues. | ||
+ | * Only one matching FCAL cluster per track is allowed with the current code. Frequently hadronic showers are grouped into multiple clusters. | ||
+ | * The match radius is hardcoded as 5 cm, but in the calib/PID/photon_track_matching this parameter is set to 15 cm. | ||
+ | |||
+ | After correcting these two issues: | ||
+ | |||
+ | [[Image:PhotonEvsTheta recon FCAL Feb12.aggressiveTrackMatching.png]] | ||
+ | |||
+ | Timing cut: | ||
+ | |||
+ | There is an issue that the FCAL hit time propogated thru the code is the time the hit was recorded (time at the back of the FCAL), while the DNeutral... class expects the cluster t to be the time to cluster position (x,y,z). After correcting for this issue, we have a timing distibution: | ||
+ | |||
+ | [[File:PhotonTproj recon FCAL.png]] | ||
+ | |||
+ | We can make a timing cut (t_shower-t_flight) < 1 ns: | ||
+ | |||
+ | [[File:PhotonEvsTheta recon FCAL Feb12.aggressiveTrackMatching.timingCut.png]] | ||
+ | |||
+ | Still have extra FCAL photons. Looking into this issue. | ||
==Two gamma invariant Mass== | ==Two gamma invariant Mass== | ||
+ | ===BCAL=== | ||
Look at pairs of 2 BCAL photons, subject to cuts described above. Using truth vertex information. | Look at pairs of 2 BCAL photons, subject to cuts described above. Using truth vertex information. | ||
− | |||
− | |||
Compare KLOE algorithm to GlueX algorithm. | Compare KLOE algorithm to GlueX algorithm. | ||
− | [[Image: | + | [[Image:Photon two gamma invariant mass 2BCAL.png]] |
+ | |||
+ | GlueX is in red, KLOE in black. | ||
+ | |||
+ | According to thrown data, ~15300 events should have both decay photons end up in the BCAL, with sufficient energy to pass cuts. | ||
+ | |||
+ | ===FCAL=== | ||
+ | Pairs of 2 FCAL photons, subject to cuts described above: | ||
+ | |||
+ | [[File:Photon two gamma invariant mass 2FCAL.png]] | ||
+ | |||
+ | According to thrown data, ~8500 events should have both decay photons end up in the FCAL. | ||
− | + | ~2000 are in the peak above. |
Latest revision as of 12:06, 27 February 2012
50,000 b1pi events. No EM background.
Contents
BCAL
Thrown photons
Look at the distribution of decay photons from the pi0.
For comparison with reconstructed data, useful to look at z rather than theta. This is the z that the photon would reach the inner radius of the BCAL, given its momentum and vertex.
Reconstructed photons
Spectrum of reconstructed "photons": exclude clusters that can be matched to a charged track.
z is the (extrapolated) position of entry into the BCAL, not the z coordinate of the cluster itself.
Where does each of these peaks come from?
- All peaks are from noise that cause garbage timing info. The odd structure is due to the fact that I am trying to plot z at point of entry into BCAL (at BCAL inner radius).
Cuts
- A timing cut fabs(t_shower-t_flight) < 1 ns can be applied to remove many of the extra "photons". (Red curve below)
- I don't think low energy showers are well understood at the moment, so remove clusters with E<60 MeV. (Green)
- Also, cut out a problem area at forward angles and lower energies (E<120 MeV && z>325 cm) (Blue)
More work needed to optimize cuts.
With all cuts:
Number of "photons" decreases from 211,000 to 61,000.
FCAL
Thrown photons
Reconstructed photons
Way too many reconstructed. Clusters matched to charged tracks are vetoed, but this has some issues.
- Only one matching FCAL cluster per track is allowed with the current code. Frequently hadronic showers are grouped into multiple clusters.
- The match radius is hardcoded as 5 cm, but in the calib/PID/photon_track_matching this parameter is set to 15 cm.
After correcting these two issues:
Timing cut:
There is an issue that the FCAL hit time propogated thru the code is the time the hit was recorded (time at the back of the FCAL), while the DNeutral... class expects the cluster t to be the time to cluster position (x,y,z). After correcting for this issue, we have a timing distibution:
We can make a timing cut (t_shower-t_flight) < 1 ns:
Still have extra FCAL photons. Looking into this issue.
Two gamma invariant Mass
BCAL
Look at pairs of 2 BCAL photons, subject to cuts described above. Using truth vertex information.
Compare KLOE algorithm to GlueX algorithm.
GlueX is in red, KLOE in black.
According to thrown data, ~15300 events should have both decay photons end up in the BCAL, with sufficient energy to pass cuts.
FCAL
Pairs of 2 FCAL photons, subject to cuts described above:
According to thrown data, ~8500 events should have both decay photons end up in the FCAL.
~2000 are in the peak above.