- Inherits from TSelector: Can be used with TTree::Process(), PROOF.
Improvements over TSelectors
- You can access the data in the C-style branches from C++ interface classes. After initial setup, using these classes incurs almost no overhead. With these classes, data can be easily passed into external functions, unlike the hard-coded-in-your-header-file TSelector data members. This enables the creation and usage of library code that can be shared amongst collaborators, including analysis actions.
- The TTree knows what your reaction was, so when you generate your DSelector code is automatically generated with this in mind: DParticleCombo + example code.
- Array sizes are no longer hard-coded (they are adaptively expanded). This means that you can generate your DSelector with one TTree, and keep using it regardless how much more data you get. With basic TSelector's, you have to regenerate your TSelector each time you get more data, in case it contains an event that needs a larger array size.
- You can use the exact same code whether you're running directly over a tree, or you're running with PROOF. With just a TSelector, you have to change a lot of code to switch between them.
Setting up the software & environment
1) Go to the directory where you want the source code to go. Checkout the software here:
git clone https://github.com/JeffersonLab/gluex_root_analysis
2) Set the path to the checked-out gluex_root_analysis directory to be the variable:
3) After sourcing your standard GlueX sim-recon environment file, source the environment file appropriate for your shell:
source $ROOT_ANALYSIS_HOME/env_analysis.csh OR source $ROOT_ANALYSIS_HOME/env_analysis.sh
4) Build and install the software
cd $ROOT_ANALYSIS_HOME ./make_all.sh
Creating a DSelector
1) Run the MakeDSelector program to make a DSelector for your TTree. Run it with no arguments for usage instructions.
2) You can run the DSelector straight out of the box if you want to see what it does.
3) Let's assume that you have generated a ROOT TTree file called "tree_omega.root" and that this file contains a tree named "omega_skim_Tree". Then, the command that will generate a DSelector for this file and tree is:
MakeDSelector tree_omega.root omega_skim_Tree my_selector
The last argument is the name you want to give to your DSelector.
4) When customizing your DSelector be very careful to read ALL of the pre-generated comments. They are there for a reason.
5) Write code similar to the pre-generated code, and everything will work fine.
Using a DSelector
root -l -b my_tree_file.root .x $ROOT_ANALYSIS_HOME/scripts/Load_DSelector.C my_tree_name->Process("my_selector.C+"); .q
Using DSelector's with PROOF-Lite
- PROOF is ROOT's solution for running over a TChain multi-threaded.
- PROOF is for distributed computing, whereas PROOF-Lite is for running multi-threaded on your local machine.
- Note that each thread has it's own copy of ROOT histograms, and then they are merged together at the end. So, watch your memory usage, because it multiplies.
- However, since the objects in each thread are totally isolated from one another, you do not need to worry about locking.
- The DSelector is automatically setup to work either with or without PROOF (or PROOF-Lite).
- Note: "cout" statements are written to log files, not to screen. If you want to print to screen, call:
gProofServ->SendAsynMessage("My message"); //must #include "TProofServ.h"
- Note: PROOF log files can be viewed from the PROOF GUI that gets launched, or you can find them in your ~/.proof/ folder.
1) It is highly recommended that you add the below line to your ~/.rootrc file (create it if it doesn't exist). This is the maximum number of previous sessions (thread files) that PROOF-Lite will keep on your disk. Once the max is reached, it will delete the oldest ones. At the moment the default is 10, so if you execute 2 simultaneous instances of PROOF-Lite with 8 threads each, it will break the first one, unless you increase this value.
2) After each time the DSelector library is built, (re-)build the PROOF DSelector package (this is done automatically by the "make_all.sh" file):
cd $ROOT_ANALYSIS_HOME/programs/MakePROOFPackage/ ./build.sh
3) Launch ROOT, and load the DSelector library:
- Note: PROOF-Lite will launch a GUI, so run ROOT with -b if you don't want it. It's useful for viewing log files though.
root -l .x $ROOT_ANALYSIS_HOME/scripts/Load_DSelector.C
4) Run PROOF-Lite:
DPROOFLiteManager::Process_Tree("my_tree_file.root", "my_tree_name", "my_selector.C+", "my_outfile.root", my_num_threads); //my_num_threads = unsigned int
Making Cuts and Saving the Survivors Into a New TTree
Cloning the Tree
- To clone the input tree into an output ROOT file (except for the cuts that you make), first set the output file name inside of your selector's Init function:
dOutputTreeFileName = "my_tree_file.root"; //"" for none
- This will automatically create the tree in this file. Then, to save the event (if it passes your cuts), inside of your selector's Process function:
- If you want to flag some combos as cut, but not the entire event, then for each combo that fails a cut call:
Adding Custom Branches
- To add custom branches, in the selector's Init function, AFTER the call to:
- Call (e.g.):
dTreeInterface->Create_Branch_Fundamental<Int_t>("My_Int_Branch"); dTreeInterface->Create_Branch_NoSplitTObject<TLorentzVector>("My_P4_Branch"); dTreeInterface->Create_Branch_FundamentalArray<Float_t>("My_Float_Array", "Name_Of_Branch_Containing_Array_Size", 10); //10: init array size, will expand as needed dTreeInterface->Create_Branch_ClonesArray<TLorentzVector>("My_P4_Array_Branch", 10); //10: init array size, will expand as needed
- Then, fill the branches inside of your selector's Process function, call (e.g.):
dTreeInterface->Fill_Fundamental<Int_t>("My_Int_Branch", 5); //5: e.g. value dTreeInterface->Fill_Fundamental<Float_t>("My_Float_Array", 4.7, 2); //2: e.g. array index dTreeInterface->Fill_TObject<TLorentzVector>("My_P4_Branch", locP4); dTreeInterface->Fill_TObject<TLorentzVector>("My_P4_Array_Branch", locP4, 0); //0: e.g. array index