At one time I had new groups in the code, but things were becoming clunky. At some point these multiple cluster groups had to be added back together, so after some trials I decided to remove the extra groups and make the code more flexible. One goal was to make the process transparent, since I'm sure everyone is sick of hearing about it by now. Adding another group would have required code changes down the road while filling GROUP_PHOTONS, which doesn't seem to match the philosophy of the existing corrections, and would move the "switch" of splitoff_reclaim usage to a less appropriate location. Keeping everything in make_lgd_clusters seemed appropriate.
I'd like to get rid of the splitoff group as well, making this completely transparent, but some seg faults have kept me from getting that to work. A bird in the hand....
One thing I've seen: The number of clusters in an event has dropped dramatically: nClust.jpeg
I've been trying to get the rest of my analysis code in gear to see if this is a good or bad thing.... The last week has given me conflicting answers to this question.
After the conference call, Richard asked for a change in the way I store the reconstructed data. I have now moved it into a group called GROUP_LGD_RECONSTRUCT, stored in sub-groups depending on the number of clusters in the reconstructed event. Each event is iteratively reconstructed until there is only one cluster remaining; each reconstruction is assigned a confidence level. This data structure will facilitate identification of all reconstructions with a certain number of clusters, allowing selection based on the confidence level of each reconstruction.
After figuring out how to do this, I was having very little success finding an improvement in signals. Earlier this week I realized that there was a conceptual flaw in the way I was handling this new organization of data: I was cutting on my confidence level of the current reconstruction, when what is now important is the confidence level of the next reconstruction. Splitoffs create bad events, and I never get rid of those events unless I see that the next reconstruction has a high confidence level. Each reconstruction now stores the confidence level of the next most likely reconstruction....
I've seen some success now, but this method of organizing the data makes it a little more difficult to get to the photon data. Rather than overwriting the GROUP_LGD_CLUSTERS, which then automatically pipes into make_photons, Richard suggested it was better not to cut events until later in the analysis. This means I need to make another group, something like GROUP_LGD_RECONSTRUCT_PHOTONS, filled by sending each reconstruction through make_photons. This has caused me some problems....
I'm having trouble seeing the 5- and 6- cluster signals clearly, so I'm trying to improve my particle ID analysis. After making a BSD pixel cut, some light energy cuts, and a reasonably stringent reconstruction confidence level cut, I lose about 35-40% of the events fitting multiple pi0 profiles (mostly on the lower end of the mass spectrum). A number of pics for discussion:
It's not yet clear that the reconstructions aid in 5- and 6-photon analysis, but there are a lot of cuts to adjust.
I finally fixed the problem in my analysis software, and am looking at more reasonable results. The clusterization improvements seem to have an effect, but it's not clear at this point how much of an improvement this may be. The following plots use seeds (350, 150) on top, (150, 50) in the middle, and (150, 50) with splitoff_reclaim on the bottom:
The use of a 4.3 GeV LGD energy deposition cut seemed questionable to me, so I've tried to study the issue in more detail. The first step I made was to find the energy difference between the best in-time tagger photon and the summed LGD energy, as the 4.3 GeV cut was chosen in part to reflect the lower boundary of accepted tagger energies. For a given data sample, cutting on a LGD-Tagger energy difference of -0.55 GeV produced about the same number of events as a 4.3 GeV LGD cut. These cuts seem to have significant overlap, as they each produce obvious shape changes when used on the other.
To test the relative worth of these cuts, I'm examining various event hypotheses. For a sample of about 10M events I go through the photon pair combinations and identify pi0 and eta candidates, then look at each pi0 pair trying to produce omega candidates. Plotted first for all events, followed by those satisfying the 4.3 GeV LGD cut and those satisfying the -0.55 GeV LGD-Tagger cut:
The advantage of the LGD-Tagger energy difference cut seems small, at best. I'd like to improve one of these cuts by including the energy carried by the recoil proton, as well as the photon energy deposited in the BGV. I've tried to get the BGV Clusterizer into working order, in hopes of identifying the recoil hit and looking for any additional energy deposition. I've tried adding the in-time energy deposition from all detectors to the LGD-Tagger difference, hoping to get a narrower peak near zero, but David has cast doubts on the reliability of the ADC calibrations for this purpose.
My Questions and Immediate Goals:I made a few quick studies of the Tagger timing, enough to convince me that the energy difference cuts I was making are premature at best, non-productive at worst. The first picture below shows Tagger TDC values after offset are applied. The top plot is for all hits in the tagger, the bottom for the hit closest to an offset time of zero. A quick look at the number of hits in the two peaks is somewhat encouraging, as one might expect the bottom peak to contain the entire background offset of the top peak. The simple gaussian fit doesn't give exact results, but it seems that a number of the background hit events have been cut.
Much less promising is a plot of LGD Energy Sum vs the Best-In-Time Tagger Energy, below. There doesn't seem to be much correlation between these values, which implies that the Tagger Energy (as I have determined it) is not useful. Plotting the LGD-Tagger energy difference vs Best-In-Time Tagger Energy only gives a false correlation. Applying a number of additional cuts, including BGV and CPV, did not seem to improve the correlation of LGD Energy Sum and Tagger Energy. At this point, it seems appropriate to leave tagger energy as a measure of event hermiticity on the back burner....
While trying to emulate the BGV cut used by IU, I found a strange behavior. In hopes of masking off BSD hits caused by the recoil proton, I plotted BSD_Pixel-Straight Channel vs BSD Hit Channel (all hits are in-time). Having identified a coordinate map between the two detectors' elements, I masked off the appropriate BSD channels for a given pixel. Checking the plot, to make sure the masking was done correctly, I noted a strange bias in the BSD hits. They seem to be preferentially located in channels higher than (left of?) the masked channel. I don't understand this behavior.... Could it be a product of the way BSD hits are filled?
As a side note, I've included a plot of the BGV ADC Energy Sum, for in-time hits, first non-masked (presumably due to broken events) and second masked (presumably due to recoil protons). I haven't worked much on the BGV Clusterizer since the last conference call, but might this information allow us to eventually calibrate the BGV Energy scale? In any event, cutting on the non-masked BGV energy should allow me to make a reasonable cut on wide-angle events.
