SBNAnaFiles
The Common Analysis Files (CAF files or Ana files for short), are structured root files containing the event information needed to perform analyses on SBN. Which analysis? You ask. Any beam-related analysis! The CAF files and infrastructure were first developed by collaborators on the NOvA experiment. The SBN AnaFiles are a re-work of the CAFMaker structure for SBN experiments.
The basic structure of the Ana files consists of a few branches, mostly filled at the SLICE level. The files do contain information about multiple tracks, showers, etc. per slice, but they exist in arrays on the slide level.
Here is an example of the basic structure of an Ana file:
rec tree /// The main tree filled at the slice level variables
|
--> slc /// The tree with summary information about each slice.
|
--> reco /// A branch with variables from the reconstructed objects like tracks, showers, etc.
|
--> mc /// A branch with the MCTruth information of the neutrino interaction (or cosmic) most closely associated to the slice
|
--> spill /// Information about the spill for that specific event
|
--> sel: /// The results of ID algorithms and other useful variables for event selection.
WORK IN PROGRESS: Ana files are a work in progress. The goal is to settle on a structure and a set of variables to include in the files (the ones we know are needed by the oscillations analyses and more!) and add those variables to the existing CAFs as soon as possible.
*** A tentative structure for the Ana files currently exists in this google doc:[https://docs.google.com/spreadsheets/d/12qlNyOAPNGby2ZaLjfhrARObeWO5Hy4XG5E8lWv_914/edit?usp=sharing] Feel free to add missing variables to this list.
The SBNAnaFiles_Structure wiki contain a list of variables in the current file version.
Join the conversation on the #sbn-ana slack channel!
To increase efficiency and close collaboration, CAFMaker-v0 is being developed in a shared branch.
Because we are all developing on the same branch, please be courteous and conscious of the work of others.
Here are a few basic rules that can help:
-
Communicate with others about what you are working on. No need to ask for permission, but a general understanding of what everyone is doing is useful to have.
-
Ask question, ask for help if you need it, and offer a helping hand to those who ask.
-
Never make a change that changes the content of an existing variable or output of an existing function you did not create. Exception: Bug fixes, agreement with other developers and accompanying slack message.
-
When adding inputs to a function:
-
Maintain the order of the inputs others are using and add your inputs at the end of the list.
-
Give your inputs default values, so that the function doesn't break for others.
-
-
Follow the implied naming conventions and style of the modules you are editing.
First of all make sure to source the MicroBooNE, SBND and ICARUS products:
$ source /cvmfs/uboone.opensciencegrid.org/products/setup $ source /cvmfs/sbnd.opensciencegrid.org/products/sbnd/setup $ source /cvmfs/icarus.opensciencegrid.org/products/icarus/setup_icarus.sh
Now you can start a new repository with sbncode and checkout the branch feature/sbncaf. Explicitly,
$ setup larsoft v08_40_00 -q e19:prof $ mkdir $ cd $ mrb newDev $ source localProducts_larsoft_v08_40_00_e19_prof/setup $ cd srcs $ mrb g sbncode $ cd sbncode $ git fetch origin $ git checkout feature/sbncaf $ cd sbncode $ mrbsetenv $ mrb install -j 4
As usual, whenever you log in to work on this branch, you will do:
$ source localProducts_larsoft_v08_40_00_e19_prof/setup $ cd srcs/sbndcode/sbndcode $ mrbsetenv
If you are a developer, it is good practice to check that your local changes work before pushing them to the repository. Build your local branch, in <my_directory>/srcs/sbndcode/sbndcode, by typing the following command:
$ mrb install -j 4
There are two main packages that are important to the AnaFile production and content:
-
CAFMaker : A LArSoft module that gets the Analysis variables from slices in LArSoft files and creates an AnaFile per LArSoft input file.
-
StandardRecord : The "record" we keep of the AnaFile structure. The contents and arrangement of the branches in the file.
Adding a variable to the AnaFiles requires the following:
- If you want to start a new branch, you will first need to add the branch to StandardRecord.
- Add your leaf/variable to the right StandardRecord branch or product.
- Modify CAFMaker to fill the leaf/variable you created.
!CAFimg.png!
The instructions below, teach you how to make the two changes seen in the figure: adding a new branch with new variables, or adding a variable to an existing file.
* To *add a branch*, start by creating new files *SR<your branch>.h* and *SR<your branch>.cxx*. You can copy the style from the existing ones. These files define the structure of the branches. Then, add variables to your branch.
* To *Add a variable* to a branch, edit the include file (*SRshower.h* / *SRSlice.h*) and add your variable to it. Always provide a description of variables in the comments.
* *Edit SR<your branch>.cxx*, initializing your variable with a value (for positive numbers, the convention is -5).*
* *Add any new branches* to the classes_def.xml file in StandardRecord
h2. Step 2 Edit CAFMaker
* *Fill your variables* by creating new or edit existing filling function in CAFMaker. For this example, edit *CAFMaker/FillReco.cxx*, look for the function that fills the branch you want or make a new one.
* If you created a new function, remember to add it to *FillReco.h* and add it to the code inside *CAFMaker* where you want it to fill the variable.
* *Always verify that your added variables get filled correctly.*
Run the cafmakerjob fcl on a file with all the dataproducts, including reconstruction.
lar -c cafmakerjob.fcl
To open an AnaFile, you can do simple checks with the Root TBrowser. You can also run on the file with an anautils macro COMING SOON!!!