Analysis Actions

From GlueXWiki
Revision as of 06:48, 3 November 2017 by Pmatt (Talk | contribs) (Details for writing DAnalysisActions)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Summary

  • It is often desirable to place cuts and make histograms of the data in JANA prior to making a ROOT TTree.
    • For example: data monitoring, cuts to reduce the # of kinematic fits, cuts on the pid or kinematic fit confidence levels, comparison of mass distributions before/after the kinematic fit, skim cuts, etc.
  • DAnalysisAction objects enable users to easily integrate these tasks into an analysis: they encapsulate the setup and execution of a given action.
  • These actions can be executed directly, but if they are added to the DReaction they will be executed sequentially by the DAnalysisResults_factory.
    • Actions will be executed on a given DParticleCombo object until it fails a cut, after which the remaining actions won't be executed on that object.
  • All analysis action objects inherit from DAnalysisAction.
    • Many common actions have been pre-defined in DHistogramActions.* and DCutActions.*, located in sim-recon/src/libraries/ANALYSIS/
    • Additional, custom actions can be created in any plugin.
  • The MakeAnalysisAction.pl perl script (it is installed to $PATH) can be used to create template code for a new, custom action.
    • Run it with no arguments for instructions.
  • For details on how to perform an anti(opposite)-cut, and how to call an action from within another action, see the Analysis_FAQ Analysis FAQ.

Reaction-Independent Actions

  • Reaction-independent actions are actions that can be executed independently from the rest of the analysis framework. They do not depend on DReaction or DParticleCombo in any way.
    • These actions (should) have a default (void) constructor, distinguishing them from reaction-dependent actions (which do not).
  • However, they can be added to DReaction objects and executed in sequence with the other DAnalysisAction objects.
    • This can be used to histogram reaction-independent quantities for events that satisfy cuts on your DReaction.
    • E.g.: Histogram the track multiplicity for events that satisfy a kinematic fit confidence level cut.

Setup

  • There are (or should be) three different constructors for reaction-independent objects:
    • (const DReaction* locReaction, string locActionUniqueString = ""): Use this constructor if you want to add the action to a DReaction.
      • WARNING: If you create two different objects of this type without unique action strings, such as one in each of two plugins and then run with both of those plugins simultaneously, you will double-count in any histograms and trees that are filled.
    • (void) and (string locActionUniqueString): Use these constructors when executing completely independently of any DReaction.
  • The locActionUniqueString is used to distinguish the histograms between different instances of the same action.
    • For example, you may wish to create two sets of DHistogramAction_DetectedParticleKinematics histograms and have them filled under different scenarios.
    • locActionUniqueString should only be left unspecified (== "") up to one time (per thread), and other instances should be assigned a unique, distinguishing string.

Execution

  • When these actions are not added to a const DReaction, you should call the Initialize() method before executing it.
  • There are two function-call operators that you can call to execute the action: one with particle combos as input, one without. If the action acts on particle combinations, you MUST use the operator with the combos as input.
  • For the combo-independent function-call operator, the return-type is bool: this is the same bool as returned by the Perform_Action() function. This allows access to the result from combo-independent cuts. This is only true for combo-independent actions.
  • For the combo-dependent function-call operator, the return-type is void: the bools for each combo returned by the Perform_Action() function can be found in the input.
  • Example:
  //Define the actions (e.g., in plugin proccessor header file):
  DHistogramAction_TrackMultiplicity dHist_TrackMultiplicity;
  DHistogramAction_ThrownParticleKinematics dHist_ThrownParticleKinematics;
  DHistogramAction_DetectedParticleKinematics dHist_DetectedParticleKinematics;
  DHistogramAction_GenReconTrackComparison dHist_GenReconTrackComparison;
  DHistogramAction_NumReconstructedObjects dHist_NumReconstructedObjects;
 
  //Initialize the actions (e.g. in plugin processor brun() method):
  dHist_TrackMultiplicity.Initialize(locEventLoop);
  dHist_ThrownParticleKinematics.Initialize(locEventLoop);
  dHist_DetectedParticleKinematics.Initialize(locEventLoop);
  dHist_GenReconTrackComparison.Initialize(locEventLoop);
  dHist_NumReconstructedObjects.Initialize(locEventLoop);
 
  //Execute the actions (e.g., in plugin processor evnt() method):
    //The histograms are created upon first-execution
  dHist_TrackMultiplicity(locEventLoop);
  dHist_ThrownParticleKinematics(locEventLoop);
  dHist_DetectedParticleKinematics(locEventLoop);
  dHist_GenReconTrackComparison(locEventLoop);
  dHist_NumReconstructedObjects(locEventLoop);

Reaction-Dependent Actions

  • Reaction-dependent actions are actions that are designed to be executed on a given reaction's DParticleCombo objects.
    • They should be added to DReaction and executed by DAnalysisResults_factory's.
    • All of the constructors for these actions (should) require a DReaction* argument, distinguishing them from reaction-independent actions (which can have default constructors).
  • The actions are executed sequentially, in the order they are added to the DReaction, by the DAnalysisResults_factory's.
    • Actions will be executed on a given DParticleCombo object until it fails a cut, after which the remaining actions won't be executed on that object.
  • WARNING: NEVER EVER create a reaction-dependent action object that is shared amongst multiple threads. Create a unique object for each thread. Objects that are created within factories (such as DReaction_factory) are fine. Objects that are members of your plugin's processor are not. This will cause race-condition issues between threads.