Photon Reconstruction in b1pi events 02/10/2012

From GlueXWiki
Jump to: navigation, search

50,000 b1pi events. No EM background.


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.

PhotonEvsZ thrown BCAL.png

PhotonZ thrown BCAL.png

Reconstructed photons

Spectrum of reconstructed "photons": exclude clusters that can be matched to a charged track.

PhotonEvsZ recon BCAL.png

z is the (extrapolated) position of entry into the BCAL, not the z coordinate of the cluster itself.

PhotonZ recon BCAL.png

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).


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)
  • 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.

PhotonZ recon cuts BCAL.png

With all cuts:

PhotonEvsZ recon cuts BCAL.png

Number of "photons" decreases from 211,000 to 61,000.


Thrown photons

PhotonEvsTheta thrown FCAL Feb12.png

Reconstructed photons

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:

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:

PhotonTproj recon FCAL.png

We can make a timing cut (t_shower-t_flight) < 1 ns:

PhotonEvsTheta recon FCAL Feb12.aggressiveTrackMatching.timingCut.png

Still have extra FCAL photons. Looking into this issue.

Two gamma invariant Mass


Look at pairs of 2 BCAL photons, subject to cuts described above. Using truth vertex information.

Compare KLOE algorithm to GlueX algorithm.

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.


Pairs of 2 FCAL photons, subject to cuts described above:

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.