[d2n-analysis-talk] BeamTrip code now working for BigBite

[Diana Parno]

Hello all,

The BeamTrip class that Dave put together is now working for BigBite.  
It required a fairly substantial rewrite of the first half of the  
FindBeamTrips function. I've given my version of the class the name  
BeamTripBB, since the FindBeamTrips algorithm is quite different, and  
probably would not work well for the LHRS, and since I haven't  
incorporated Dave's more recent changes regarding pulling kinematics  
data, etc.

You can find my code on the d2n machine at

	/home/dseymour/beamtrip/BeamTripBB.h
	/home/dseymour/beamtrip/BeamTripBB.C

The required input file, FileListTest, and directory structure are the  
same as for Dave's class. The format for rootfile names has been  
slightly modified to point to my own set of root files.

I've attached the summary canvas for a sample run, 2145. You can see  
right away that the tails on the beam-current distribution are way too  
wide to use the same algorithm as Dave uses for the LHRS. If you try  
to loosen the cuts so that you don't get buried in the outliers for  
"beam on", you wind up with an absurdly low cut current, and half or  
more of the beam-trip recovery time would wind up escaping cuts  
altogether. No good. (And I do mean "buried" in outliers; even with a  
cut of some 20 sigma, the TTree::Project calls end up seg-faulting,  
because you end up with several thousand regions to cut out, and there  
are too many operators in the cut!)

But you can also see that the beam trips themselves are very well  
defined. Take a look at the top right panel in particular -- the beam  
current readings just march straight down (or straight up).

Here's how I solved the problem for BigBite: instead of evaluating  
whether an individual readout fell outside the predefined limits, I  
effectively slowed down the readout speed in software, by averaging  
the values of a large group of readouts. (I wound up settling on 50  
consecutive readouts as a group size.) If the group average falls  
outside the limits, then I cut out the entire group. This requires a  
brace of additional variables to keep track of the various group  
values, but it's set up so that the size of the group can be altered  
by changing only one parameter (fgroup_size, whose value is set in the  
constructor).

Of course, this value means that we throw out a few readouts at group  
edges that are probably okay. In BigBite, the readout speed is such  
(about 10Hz, I think) that this doesn't hurt us too badly. For the  
LHRS, that would represent a far larger chunk of time, so this method  
probably would not work as well for the LHRS. With this in mind, I  
think it makes sense to do beam trips slightly differently for the two  
detectors, as long as we're picking up the same regions.

I also changed the fclock and fclock_new arrays to be TArrayDs instead  
of C arrays, and added provisions to resize them as needed. Early in  
my debugging efforts, those segfaulted quite a bit as the cuts  
overflowed them. With the new averaging method, they shouldn't ever  
get anywhere near an index of 5000, but it goes against the grain to  
undo fixes for an array-out-of-bounds error, so I didn't. :-)

Best,
Diana
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bt_2145_10_03_10.png
Type: image/png
Size: 55716 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20101007/21ac260b/attachment-0001.png