Efficiency for StGammaPointMaker

The question of why the pion maker is so inefficient came up this morning in the photon group.  I'm posting this to try and shed a little light on where these inefficiencies arise.
For this study, each gamma has exactly one pion associated with it.  So the inefficiencies stemming from turning thrown pions into gamma candidates is ignored.  Ross assures me that the GammaMaker is very efficient at turning pions into candidates (at the level of 98% or so.)

For this first study I look at 33,565 single pions thrown at the barrel; flat in eta between 0 and 1, phi between 0 and 2 pi, and Pt between 5 and 25 GeV.  Other cuts are as follows.

cluster finding parameters:
mSeed = .4
mAdd = .01
no total energy threshold
no max strips

point making parameters:
minimum points assumed
best points determined by minimizing the cluster energy asymmetry

Pion Cuts:
Pt > 5.2
Zgg < 0.8

First, here are the multiplicities for clusters and points, along with a 2-d cluster histogram


Right away it is evident that the biggest problem is failing to distinguish two photons in one of the planes.  Since this uses the minimum point assumption, if there is less than two clusters in either plane, the gamma is essentially tossed.  Pions are only reconstructed for gammas where there are at least 2 clusters in each plane.  More than 25K events have less than two points.

The resultant mass distribution (after we lose another 800 gammas from the pion-specific cuts) looks like this:


We get 6,975 pions back from the 33K thrown, or about 21% efficiency.

For the next study we keep everything the same except now we assume the maximum number of possible points.  Then we take only those events with exactly two points.  This tosses any event where there are more than two clusters in either plane, but keeps those events with 2 + 1 clusters, which would have been tossed under the original algo.  The multiplicities are...


The first three plots are the same (as expected) but the point multiplicity is much more heavily weighted towards 2, with about 16K events having two points.

The new mass distribution (after we lose 400 from pion cuts--remember we already lost those events with more than 2 points):


We get back 15709 pions; around 47% efficiency.  Again, I'm sure that in this framework, we are getting more background events (false positives) but we are obviously getting more real pions as well.  This sort of change might be worth implementing into the BEMC point maker.