[g13] RF Bunch Selection

[Paul Mattione]

This is how I select the RF bunch for my event, which I compare against to do PID.  This results in a better RF selection than you get from the CLAS reconstruction, reducing somewhat the out-of-time bands of pions, etc. 

The below is used to get the RF time from the BOS files.  The extra code is for when the HEVT bank is missing and/or when rf1 is bad.  

	double locRFTime = 0.0;
	if(!locBOSEvent->bHEVTBank.empty())
	{
		double locStartTime = locBOSEvent->bHEVTBank[0]->stt; //this is what it thinks the event start time is (auto propagated to a vertex)
		double locRFTime = locBOSEvent->bHEVTBank[0]->rf1;
		if((locRFTime < 0.0) && (!locBOSEvent->bCL01Bank.empty()))
			locRFTime = locBOSEvent->bCL01Bank[0]->rf2;
		double locRFBunchFrequency = 2.004;
		while((locRFTime - locStartTime) > (0.5*locRFBunchFrequency))
			locRFTime -= locRFBunchFrequency;
		while((locRFTime - locStartTime) < (-0.5*locRFBunchFrequency))
			locRFTime += locRFBunchFrequency;
	}
	else if(!locBOSEvent->bCL01Bank.empty())
	{
		// HEVT bank is missing, but CL01 is present
		locRFTime = locBOSEvent->bCL01Bank[0]->rf1;
		if(locRFTime < 0.0) //rf1 is bad
			locRFTime = locBOSEvent->bCL01Bank[0]->rf2;
	}
	else
		locRFTime = numeric_limits<double>::quiet_NaN();

Note that the RF time in the BOS file may not be anywhere near the true event start time: it's the time of AN RF bunch reaching the target center, not necessarily the correct one.  You need to choose the correct RF bunch yourself (+/- some multiple of 2.004 ns from the rf bunch).  The code in the HEVT portion above uses the HEVT->stt value to get a good initial guess for this value.  If you want to improve on this in your own analysis, you should use the start counter hit times.  


To check the sanity of the start counter hit times, I propagate both the ST and TOF hit times to the beamline and require for each track in my reaction (not each track in the event, because it may include accidentals):

	if((fabs(locStartTime_ST - locStartTime_TOF) < 20.0) || ((locStartTime_ST >= 4.0) && (locStartTime_ST <= 28.0)))

The numbers 4 & 28 came from a histogram I made of the start counter time: everything outside of this range looks like flat background, but if it (very) roughly coincides with the TOF time then it still can be OK.  These cuts can be tweaked, but you get the idea.  

I average all of the valid locStartTime_ST values for the tracks/showers in my reaction (again, not each track in the event) and use that value to pick a better RF time:

	double locPropagatedRFTime = locRFTime + (locVertexZ - dTargetCenterZ)/SPEED_OF_LIGHT;
	double locRFBunchFrequency = 2.004;
	while((locRFTime - locAverageStartTime_ST) > (0.5*locRFBunchFrequency))
		locRFTime -= locRFBunchFrequency;
	while((locRFTime - locAverageStartTime_ST) < (-0.5*locRFBunchFrequency))
		locRFTime += locRFBunchFrequency;

Where locVertexZ is a weighted average of the z-position of the charged tracks (weighted by tracking uncertainty on z).  

 - Paul