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

Updated Details (markdown)

Gordon McCann 2021-10-13 17:12:00 -04:00
parent 6839aa5edc
commit e36975f572
1 changed files with 5 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
Details.md

@ -17,3 +17,8 @@ These classes are the implementation of the method described in the Home page. T
## `ChannelMap` and its interaction with `SlowSort` ## `ChannelMap` and its interaction with `SlowSort`
As it is currently implemented, we map CoMPASS channel data to detector related data structures using the `ChannelMap` class in conjuction with `SlowSort`. `ChannelMap` reads in a map file, which essentially provides a conversion between a global channel number and a number specifically associated with a detector component (a detector id). The allowed values are specified by an `enum` list defined in `ChannelMap`. `SlowSort` then has a secondary map which converts this detector id into a pointer to the correct memory location in the data structure. The reason for this slightly complicated scheme is that it provides a performance boost over the alternative of a large `if` statement over hardcoded values, and also it is more stable against modifications. It also does a better job of encapsulating the idea of the mapping as well. However, it is slightly convoluted, and in a better implementation `SlowSort` would probably not have a map as well; the entire mapping process should be encapsulated within the `ChannelMap` class. Consider this an area of active development. As it is currently implemented, we map CoMPASS channel data to detector related data structures using the `ChannelMap` class in conjuction with `SlowSort`. `ChannelMap` reads in a map file, which essentially provides a conversion between a global channel number and a number specifically associated with a detector component (a detector id). The allowed values are specified by an `enum` list defined in `ChannelMap`. `SlowSort` then has a secondary map which converts this detector id into a pointer to the correct memory location in the data structure. The reason for this slightly complicated scheme is that it provides a performance boost over the alternative of a large `if` statement over hardcoded values, and also it is more stable against modifications. It also does a better job of encapsulating the idea of the mapping as well. However, it is slightly convoluted, and in a better implementation `SlowSort` would probably not have a map as well; the entire mapping process should be encapsulated within the `ChannelMap` class. Consider this an area of active development.
## `SFPPlotter` and `CutHandler`
`SFPPlotter` is the class responsible for handling a plot request. It takes in a ROOT file with a tree and generates a new file with histograms. It can also perform one layer of cuts. Cuts are methods for selecting specific data out of the entire set. This is done with ROOT's `TCutG` class. A list of ROOT files, each of which contains a `TCutG` object named "CUTG" (the default name), can be given to the plotter which then passes the list along to a `CutHandler`. The handler retrieves the cut, gives it the new name specified in the list file, and associates the names of the variables to be cut upon. A map of variable names to memory location is created at construction by the `CutHandler`. If the user wants to expand the possible cut variables, they will need to add a name to the map and specify the memory location in the data structure.
The plotter has two overloaded methods named `MyFill`. These essentially handle the creation and filling of ROOT histograms. Using these type of patterns greatly reduce the code overhead of using the ROOT histograms. In general these methods should be used rather than individually constructing, filling, and writing histograms. There is some cost to using the `MyFill` style, but in general it is greatly outweighed by the reduction in code and increase in readability of the code.