Difference: UmassNtupleAnalysis (13 vs. 14)

Revision 142010-04-19 - AndrewMeade

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

UmassNtupleAnalysis

Line: 123 to 123
 

Planned Improvements

The framework is now in a period of growth, and so I consider it time to evaluate what areas of the framework structure could use improvement. The below will be addressed within the following weeks:

Added:
>
>
  • There are a number of old variables that the particle classes contain and attempt to fill based on a defunct ntuple format. These should be cleaned up. This would get rid of most of the printouts of "empty variables" (which are not used anyways).
 
  • Selection needs to be improved, right now the muon object defines the quality cuts that are then manipulated by a MuSelections object. Instead I would like to have the MuSelections object to define the cuts (possibly being initialized by a muon). I would also like to add a MuSelections::selectMuons() method that could take in a vector of muon pointers and return the selected muons, which would clean up the DataManager class as well.
  • 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.
Changed:
<
<
  • 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).
>
>
  • 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). The structure of the DataManager is also a bit bloated, as it manages all filling and selection. Some of its functionality could be moved into the Selection classes, and/or new modules or classes.
 
  • 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.
 
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