Difference: UmassNtupleAnalysis (12 vs. 13)

Revision 132010-04-19 - AndrewMeade

Line: 1 to 1
 
META TOPICPARENT name="AndrewMeade"

UmassNtupleAnalysis

Line: 50 to 50
  The following are the files you will want to look at and alter, in order of importance to the end user:
Changed:
<
<
  • MyAnalysis.cxx: This is where the final analysis is done on internal particle classes (muons,jets,etc), which are accessed through m_data, for example m_data->preMuons gives you a pointer to the vector of muons before selection.
>
>
  • MyAnalysis.cxx: This is where the final analysis is done on internal particle classes (muons,jets,etc), which are accessed through m_data, for example m_data->preMuons gives you a pointer to the vector of muons before selection. This has evolved so that most of the analysis is now done in Analysis Modules (see below), which are loaded by this event loop.
 
Changed:
<
<
  • oxfordConfig.cxx: This configures both the branch variables, as well as analysis level configuration such as cuts. So you can change for example the minimum p_T of muons you will select, or what jet algorithms to consider. Note that because branch name information is set here, so there is a different config file for each ntuple type. Each of them set a number of static variables in myConfig.h, that are then picked up by the other classes. Example:
     myConfig::MuonBranchName 
    This gives the prefix for muon variables, perhaps "muidMuon_",
>
>
  • wzConfig.cxx: This configures both the branch variables, as well as analysis level configuration such as cuts. So you can change for example the minimum p_T of muons you will select, or what jet algorithms to consider. Note that because branch name information is set here, so there is a different config file for each ntuple type. Each of them set a number of static variables in myConfig.h, that are then picked up by the other classes. Example:
     myConfig::MuonBranchName 
    This gives the prefix for muon variables, perhaps "muidMuon_",
 
  • DataManager.cxx: This class stores the particle vectors in the struct particleData. It fills the internal particle classes from the branch information, and selects a subset of these particles that you actually want to use in your analysis (for example m_data->selMuons), based on a number of cuts on momentum, angular distribution and quality criteria (for example isolation).
Line: 87 to 87
  Right now, D3PDMaker ntuples and Oxford Analysis Ntuples are supported. physicsConfig.cxx is set for the AODToPhysicsD3PD.py nuptles (with default options), and wzConfig.cxx is set for the common SM WZ ntuples that are being centrally produced (all three are D3PDmaker based). The MCP ntuple (harvardConfig.cxx) is being developed by Martin, but the scope of the ntuple (detailed hit information, etc), is a bit more detailed than UMAnalysis on the moment, so the reader will probably only access some of the ntuples content (or the framework will grow). In addition, I have all the information to support EWPA ntuples, let me know if you need this functionality.
Added:
>
>

Adding Modules

Copy AnalyModules/MyModule.cxx and rename it as you wish. In MyAnalysis.cxx, add an include statement for your module at the top, and add the following in the MyAnalysis constructor:
AnalyModule * yourModule = new YourModule(m_data);
m_analysisModuleList.push_back(yourModule);

Finally add your module to the list of classes to be compiled in run/compileAll.C

srcFiles.push_back("AnalyModules/YourModule.cxx"); 

That should be it!

 

Adding Variables

If you want a variable added, say muon chi2 information, you just need to do the following: (1) add it to yourConfig.cxx initMuonMap (where the postfixes are added), (2) add the variable to muon.h, and then go (3) dataManager::makeMuon() and add a line to fill the variable.

Line: 113 to 127
 
  • MyAnalysis is now not needed. All modules should be loaded in AnyTree.C instead. MyAnalysis existed to have an event loop which could be independent of different TSelector classes from different tried, but now AnyTree deals with all of them! It is now a superfluous (but harmless) layer.
  • In AnyTree.C the readTree() function is awkwardly placed, but I'm not sure where else it should go.
  • The DataManager.cxx class has many ways it could improve performance, by reducing unnecessary data copying and more importantly, fewer map operations (costly as they involve string comparisons).
Added:
>
>
  • Configuration needs to be improved. The method of passing configuration is not ideal, and there also should be a separation of tree dependent configuration (branch names, etc) and tree-independent configuration (pt cuts, modules to load).
  • Histograms output should be changed so that a directory is created in the output file for each module, in order to keep all the histograms organized.
  -- AndrewMeade - 18-Jan-2010
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback