gwm17/SPS_SABRE_EventBuilder
1
0
Fork 0
mirror of https://github.com/sesps/SPS_SABRE_EventBuilder.git synced 2024-11-26 19:38:50 -05:00
Code Issues Projects Releases Wiki Activity

Updated Home (markdown)

Gordon McCann 2021-10-12 15:02:54 -04:00
parent 596da89607
commit e9cef675a5
1 changed files with 7 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
Home.md

@ -26,9 +26,14 @@ Fast sorting is an optional secondary stage of coincidence analysis, aimed at re
Technically speaking, after the sorting stages, the event building is complete and the next, much more complicated and experiment specific data analysis stage should take over. However, due to some limitations of the CoMPASS software with online data analysis, as well as to provide a method to test the success of event builder, the event builder can pass the data on to a very basic analysis class. This analysis is _not_ meant to be used as a final analysis program; it does not have very many safety measures and is typically too simple and too difficult to modify for most experiments. There are some key features that outline both the use and drawbacks of this analysis. First is that _any_ degeneracy in data must be resolved for use with the analysis. Consider the following scenario: the front left delay line signal is slightly noisy and inside the built event there are two front left delay line hits. To calculate a calibrated focal plane position one must subtract the timestamp of the left and right signal for a given delay line. How then is the analysis to select which front left delay signal goes with the single front right delay signal? To make the code generally applicable it employs a very simple solution of taking whichever hit occurred first, but one can imagine all of the reasons why this is not desirable for specific experiment cases. This first-in selection scheme is employed for _every_ detection channel that gets converted into analyzed data. In general, the only data member that continues to maintain the earlier policy of not dumping data is the SABRE array, however, a downscaled version of the SABRE array is then required to be used with the online plotting. Additionally, due to the dynamic nature of the sorted data, checks must be made upon the validity of the data at analysis time. This in turn induces a performance penalty as more and more complicated analyses are performed, which reduces the usefulness of adding more analysis steps. Finally, the data analysis tends to bloat the file size. Each additional analyzed parameter induces an increase in the written data size, and ROOT does not support optional writing. That is: even if an event does not have a right scintillator hit, all of the right scintillator data member will still be written to the file with an illegal default value (typically something like -1). In a more specialized analysis, only relevant data would be written, but due to the general nature of this analysis along with its focus on providing sanity checks for the event building process, a lot of experimentally irrelevant data will be written. Technically speaking, after the sorting stages, the event building is complete and the next, much more complicated and experiment specific data analysis stage should take over. However, due to some limitations of the CoMPASS software with online data analysis, as well as to provide a method to test the success of event builder, the event builder can pass the data on to a very basic analysis class. This analysis is _not_ meant to be used as a final analysis program; it does not have very many safety measures and is typically too simple and too difficult to modify for most experiments. There are some key features that outline both the use and drawbacks of this analysis. First is that _any_ degeneracy in data must be resolved for use with the analysis. Consider the following scenario: the front left delay line signal is slightly noisy and inside the built event there are two front left delay line hits. To calculate a calibrated focal plane position one must subtract the timestamp of the left and right signal for a given delay line. How then is the analysis to select which front left delay signal goes with the single front right delay signal? To make the code generally applicable it employs a very simple solution of taking whichever hit occurred first, but one can imagine all of the reasons why this is not desirable for specific experiment cases. This first-in selection scheme is employed for _every_ detection channel that gets converted into analyzed data. In general, the only data member that continues to maintain the earlier policy of not dumping data is the SABRE array, however, a downscaled version of the SABRE array is then required to be used with the online plotting. Additionally, due to the dynamic nature of the sorted data, checks must be made upon the validity of the data at analysis time. This in turn induces a performance penalty as more and more complicated analyses are performed, which reduces the usefulness of adding more analysis steps. Finally, the data analysis tends to bloat the file size. Each additional analyzed parameter induces an increase in the written data size, and ROOT does not support optional writing. That is: even if an event does not have a right scintillator hit, all of the right scintillator data member will still be written to the file with an illegal default value (typically something like -1). In a more specialized analysis, only relevant data would be written, but due to the general nature of this analysis along with its focus on providing sanity checks for the event building process, a lot of experimentally irrelevant data will be written.
## Plotting ## Other Operations
### Plotting
The main purpose of running the analysis is to then generate histograms which help indicate the quality of the data. To this end, the event builder has a plotting routine that uses ROOT tools to generate a file of histograms. This plotting tool can take in multiple analyzed files and generate a single plot file containing all of the data. Additionally, a list of cuts (called the CutList) can be given to the plotter tool, and they will be applied to the data. Cuts should be given in a cut list file, and should each be individually saved in ROOT files as TCutG objects named "CUTG". The cutlist file will ask the user to give a new name for the cut, as well as specify the name of the variables upon which the cut should be applied. There are a fixed number of keywords for variables which can be used, see the `CutHandler` class for more details. The main purpose of running the analysis is to then generate histograms which help indicate the quality of the data. To this end, the event builder has a plotting routine that uses ROOT tools to generate a file of histograms. This plotting tool can take in multiple analyzed files and generate a single plot file containing all of the data. Additionally, a list of cuts (called the CutList) can be given to the plotter tool, and they will be applied to the data. Cuts should be given in a cut list file, and should each be individually saved in ROOT files as TCutG objects named "CUTG". The cutlist file will ask the user to give a new name for the cut, as well as specify the name of the variables upon which the cut should be applied. There are a fixed number of keywords for variables which can be used, see the `CutHandler` class for more details.
### Scalers
Sometimes there is data collected where the only thing of interest is the number of counts in that channel, or the channel generates so much data that it cannot be analyzed online without slowing down the event building to such a crawl that it becomes impractical. To address these cases, specific channels can be designated as scalers. When a channel is designated as a scaler, the associated binary data file is separated from the main event building pipeline and analyzed quickly by calculating the number of hits. This number is then saved to the output file with an associated name. Scalers are specified using a scaler list file, where the file contains a list of CoMPASS file names and a scaler name. The CoMPASS file name is a string which indicates the board and channel to be designated as a scaler, where in this case the specific board ID must be used.
# Installation, Building, and Setting up the Workspace # Installation, Building, and Setting up the Workspace
First, the only external dependence for this repository is the ROOT Data Analysis Package. Due to the large size and complexity of ROOT, ROOT is not included as a submodule, and rather the user is relied upon to properly install and setup their own ROOT package. This code has been primarily tested and validated using ROOT6, so mileage may vary with older versions. First, the only external dependence for this repository is the ROOT Data Analysis Package. Due to the large size and complexity of ROOT, ROOT is not included as a submodule, and rather the user is relied upon to properly install and setup their own ROOT package. This code has been primarily tested and validated using ROOT6, so mileage may vary with older versions.