File to generate Hit Parameters using Los not in GitHub repository

[ajedele]

The Los calibration was recently updated to include multi-hit. As part of this, the HitPar structure was rewritten.

The R3BLosHitPar. files (parameter managers) are in GitHub, allowing you to process the calibration parameters. The R3BTCal2Hit. files, which apply the parameters to the data exist in GitHub too.

But, the R3BTCal2HitPar.* file, which generate the parameters, is not part of the GitHub repository.

Therefore, you cannot currently use the code because there is no means to generate the parameters you need to apply in the final step.

[akelic]

R3BTCal2HitPar.* never existed. LOS was designed as a timing detector, and time calibration was done in Mapped2CalPar task. Cal2HitPar task never existed, as we didn't have standard way to calibrate position from LOS detector. Thus, x and y positions used to be calibrated per hand (in KVI using a mask, in s444 using PSPs, in other experiments it was done with a help of ROLU....) and the parameters were then given via functions in analysis macro as e.g.: // Set parameters for X,Y calibration // offsetX, offsetY,VeffX,VeffY for LOS1 and LOS2 losCal2Hit->SetLosXYMCFD(xoffset_MCFD,yoffset_MCFD,xveff_MCFD,yveff_MCFD,0,0,1,1); // position from MCFD times
losCal2Hit->SetLosXYToT(xoffset_ToT,yoffset_ToT,xveff_ToT,yveff_ToT,0,0,1,1); // position from ToT losCal2Hit->SetLosXYTAMEX(0,0,1,1,0,0,1,1); // position from TAMEX times

As LOS was never planned to be used for measuring the nuclear charge (ToT measurements was introduced for correcting for walk effect if needed), charge calibration was not planned, and was not introduced. The only time we tried to use LOS for incoming-beam charge identificatioin was in s515, and there the charge calibration parameters were also given via functions in macro but not to LOS cal2hit task. We needed other detectors to properly identify charge in LOS, and thus cal2hit LOS task gave as output ToT, which was then calibrated in the incoming PID task using correlations with other detectors.

Thus, if the LOS cal2hit task was not change in a way that the above functions are removed, one has to be able to use the code with giving the values of the position-calibration parameters in the analysis macro. But, if one only needs time for LOS, then one even doesn't need to calibrate positions, one can just put in all 3 functioins above the values as given above in the function SetLosXYTAMEX(0,0,1,1,0,0,1,1).

[ajedele]

Thanks Aleksandra. That did cross my mind later. I assumed there was a 2nd step that matched the trailing and leading edges, but that's not needed when LOS is for timing only.

Have you looked into using the ToT to filter out non-beam events (i.e. noise or cosmics)? Or is the rate low enough that we are not concerned?

Either way, if you want to use LOS for PID (mandatory for s522, a check for s509 and most likely the case for Marina's experiment), then we need a means to calculate the walk correction and the charge. I believe that was done for s522, but I don't see where the walk correction values are set

[akelic]

In case of LOS you don't have to worry about cosmics nor noise. During the time Michael and me were developping and testing different options for LOS detector, we tried to use cosmics for testing, but never saw them for the standard values of LOS HV. Also we never had problems with noise in LOS, as you measure the time with 8 PMTs and you accept an event only if all electronic channels saw something. And with proper values of HV and proper electronic thresholds, a chance that all 8 channels see noise signals in coincidence is non-existing.

Walk correction you also don't need. Timing of the LOS, under condition you use MCFD times (which one should use for timing) and not TAMEX leading-eddge time (which one should not use for timing purposes) is more than good for our present needs. The walk effect on the MCFD is on the level of few ps, and doing the walk correction on LOS times would not bring you anything, especially if the stop detector has worse timing than LOS. Here, just to point it out once again - in case of LOS one must use MCFD times for timing purposes and not TAMEX times; the only thing to use from TAMEX branch is time-over-threshold, if needed.

Nuclear charge was calculated in S515, and I made charge calibration of LOS for this experiment during online running and incorporated it in the incoming PID task. One can use for S522 and S509 the same method as in S515.

[nmozumdar]

Hi, I completely agree with @akelic that the main purpose of Los is as a timing detector and not for charge measurements. I want to make it clear that for low rate experiments the old LOS tasks works very well. In fact the LosCal2Hit is not even needed when using LOS for timing since the start time can be selected from LosProvideTStart which uses only the Cal level data. And also the VFTX and TAMEX signal matching is done properly if the number of VFTX and TAMEX signals are same (which is the case for low rate experiments). Which is the reason I agree with keeping the old tasks in use and preferred over my task. In fact if we use the standard available unpackers that is what is being used as default.

The fact that LOS is primarily a timing detector is what I kept in mind when writing the new task. There were two reasons for the new tasks one is to have access to TCal level data without any matching, to look for proper windows and correlation and if the data makes sense. The second and more important reason is that for S522 which ran at very high rates there was a problem with the matching in the old LosMapped2Cal task of the VFTX and TAMEX signals which sometimes saves unmatched individual tamex LE and TE times as the last hits since the matching is done by order of the signals. This meant that when using task LosProvideTStart it is not able to access VFTX times from some events because it looks at this last hit leading to statistics loss of ~15% in S522. So I made the Task LosTcal2Hit to match all signals properly so that there are no such "stray" hits. The parameters read by this task is only for matching the VFTX with the TAMEX, but if you don't use any parameters it will still match the 8 VFTX signals properly and save the LOS time which is the minimum required from LOS task. In other words if you don't do anything an run my code it will still give you LOS time (not corrected by trigger time). The VFTX windows between the 8 PMTs should not change from experiment to experiment and it is the exact same thing I did for the S2 scintillator. (Actually I copied the matching algorithm from the old LOS codes :P ) Now matching the TAMEX and getting a good charge in LOS is just a cherry on top which I did for S522 and S509. Especially since I expect S522 needs to use LOS charge because of multihit event loss of MUSLi. Seeing that the LOS task did the minimum (of providing time) without the parameters I didn't invest a lot of time into it, also I don't have the expertise to write code to satisfy the current clang-tidy check and even if there is a way to turn it off we are at a bleak line of what is considered as acceptable code. But the main reason I didn't write the task is simply that I don't have the time since we are on limited time and we need to work on more important things in the analysis.

@ajedele I didn't do the walk correction in LOS, since it is only S522 that needs it and it has only one incoming charge, I don't understand why you need walk correction for one charge but maybe you know something I don't. For S509 we don't use LOS for charge. I also have not done any position calibration since we already have the MWPCs.

[akelic]

@nmozumdar You are right, we had problems with proper ordering of the multi-hit events. At that time, we didn't have a way to treat multi-hit events (and this was clearly stated in the code). We tried to match proper leading and trailing tamex times already in the LOS reader. If you look there, you will see that we "recovered" for cases where one of the coarse counters had reset, and then accepted trailing edge only if difference between trailing and leading coarse times was positive; in some experiments we also demanded to have this difference smaller than a given value, and we tested different values until we got the best results. As far as I remember, after we introduced this time matching in the reader we didn't have any more problems with missing times. But, in case of your experiment it was probably more challenging.