Difference between revisions of "Mattione GlueX Analysis Factories"

From GlueXWiki
Jump to: navigation, search
(DParticleCombo)
(DReaction)
Line 119: Line 119:
 
* Located in src/libraries/ANALYSIS/
 
* Located in src/libraries/ANALYSIS/
 
* The user should create a DReaction object in their plugin for each analysis they want to perform (can analyze more than one at once).
 
* The user should create a DReaction object in their plugin for each analysis they want to perform (can analyze more than one at once).
 +
 +
=== Source Code ===
 
* C++ code of class members (methods aren't shown):
 
* C++ code of class members (methods aren't shown):
 
<syntaxhighlight>
 
<syntaxhighlight>

Revision as of 17:42, 12 October 2012

Summary

  • In his/her plugin, a user specifies the reaction(s) he/she wants to study (DReaction), along with the histograms and cuts to perform (DAnalysisAction), then just asks JANA for the results (DAnalysisResults).
  • Through this process, the program creates all possible track combinations for the desired reaction (DParticleCombo, tag "PreKinFit"), kinematic fits the event to the reaction (DKinFitResults), and updates the tracks with the new kinfit information (DParticleCombo, no tag).
  • The DAnalysisAction objects encapsulate the setup and execution of an action (e.g. cut, histogram) into a single object.
    • Many common actions are predefined in DANA (see libraries/ANALYSIS/DHistogramActions.h and libraries/ANALYSIS/DCutActions.h), but the user can write custom ones for their analysis in their plugin.
  • The DAnalysisResults objects indicate which DParticleCombo objects have passed/failed the DAnalysisAction cuts for each DReaction.

Quick Start

  • NOTE: For an example of the below steps, see one of the existing analysis plugins (e.g. sim-recon/src/programs/Analysis/plugins/b1pi_hists).
  • Create a new plugin containing a DEventProcessor, DReactionFactory, and DFactoryGenerator (for the DReactionFactory).
  • Setup the DEventProcessor and DFactoryGenerator.
    • In DEventProcessor, make sure to grab the DAnalysisResults objects from the JEventLoop in the evnt() method, and to add the DFactoryGenerator to the application in the InitPlugin() method.
    • The DFactoryGenerator contents can be identical to those from sim-recon/src/programs/Analysis/plugins/b1pi_hists, although you may want a unique class name in case more than one plugin is used at once.
  • Create desired custom DAnalysisAction objects for your analysis (if any).
    • See existing analysis actions in sim-recon/src/libraries/ANALYSIS/DHistogramActions.h and sim-recon/src/libraries/ANALYSIS/DCutActions.h for examples.
  • In DReactionFactory::init(void), create a DReaction object (with a unique name!) for each analysis you want to perform, specify the kinematic fit type for it, specify the DAnalysisActions for each, and add them to _data.
    • Make sure to call SetFactoryFlag(PERSISTANT); in this function.
    • The DAnalysisAction objects are executed sequentially for each possible particle combination (DParticleCombo) matching the given DReaction, until it fails a cut.
    • If more than one DAnalysisAction object of a given type is used in a DReaction, all of their constructors must be called with a unique identifier string (including the default "").
    • More details on analysis actions in sim-recon/src/libraries/ANALYSIS/: DAnalysisAction.*, DHistogramActions.*, DCutActions.*
  • Compile and run hd_root with your plugin (preferably on REST data).

Analysis Procedure Details

Overview

  • Generate every possible combination of particles (DParticleCombo) that can represent the desired DReaction(s).
    • This can yield many DParticleCombo objects per event.
    • This is regardless of PID, # of remaining tracks, timing, track position or momentum, etc.
      • Only extremely loose cuts are placed by default on PID, track-vertex-z, and beam photon time prior to creating DParticleCombo objects: this is to avoid memory spikes from events with too many particles.
        • These can be changed by modifying the command line parameters defined in DParticleComboBlueprint_factory::brun() and DParticleCombo_factory_PreKinFit::brun().
  • User-specified cuts are then used to eliminate DParticleCombo objects that do not much the desired DReaction(s) (e.g. PID, kinematic fit, invariant mass, etc.)
    • This is done by executing DAnalysisActions (e.g. histogramming, cutting) in sequence on each DParticleCombo until it fails a cut.
    • The kinematic fit (if specified) is not performed until the kinematic fit results are required for a DAnalysisAction (DAnalysisAction::Get_UseKinFitResultsFlag() == true). This saves time and memory by letting users cut DParticleCombo objects prior to fitting.
  • Save the results to disk further analysis (currently not built-in (except for histograms)).

Reconstructed Data

  • NOTE: These are located in sim-recon/src/libraries/PID/
  • DBeamPhoton_factory: Currently just reads the generated DBeamPhoton objects in from the hddm file.
  • DChargedTrackHypothesis_factory: Creates a DChargedTrackHypothesis object for each DTrackTimeBased object (one per PID hypothesis, can be more than one per particle). When creating the DChargedTrackHypothesis objects, the tracks are matched to hits in the SC, BCAL, FCAL, and TOF, and the PID FOM is calculated (from TOF and DC dE/dx).
  • DChargedTrack_factory: Creates a DChargedTrack object for each reconstructed charged particle. These contain all of the DChargedTrackHypothesis objects associated with this particle.
  • DNeutralShower_factory: Creates a DNeutralShower object for each DBCALShower and DFCALShower object that is not matched to any of the DChargedTrackHypothesis objects.
  • DNeutralParticleHypothesis_factory: Creates two DNeutralParticleHypothesis objects for each DNeutralShower: a photon and neutron. The particle vertex is assumed to be the center of the target.

Reaction Analysis

  • NOTE: These are located in sim-recon/src/libraries/ANALYSIS/
  • DReaction_factory: Creates DReaction objects to be analyzed. Needs to be created in each analysis plugin.
  • DParticleComboBlueprint_factory: Creates a DParticleComboBlueprint object for each possible track combination, excluding any possible multiplicity from multiple beam photons. These DParticleComboBlueprint objects store pointers to which DChargedTrack and DNeutralShower objects will be used for each particle in the reaction. The beam photon multiplicity is handled in DParticleCombo_factory_PreKinFit.
  • DTrackTimeBased_factory_Reaction: If none of the existing DTrackTimeBased objects for a given reconstructed track have the needed PID for a particle in a DReaction, this creates new DTrackTimeBased objects for them (e.g. e-, or if one of the default PIDs (e.g. π+) fails reconstruction while the others don't (e.g. K+)). This uses the reconstructed momentum from the DTrackTimeBased object with the closest mass, and re-swims the track.
  • DChargedTrackHypothesis_factory_Reaction: Creates DChargedTrackHypothesis objects for the DTrackTimeBased objects created by DTrackTimeBased_factory_Reaction.
  • DParticleCombo_factory_PreKinFit: Creates a DParticleCombo object for each DParticleComboBlueprint, setting the data with the measured DChargedTrackHypothesis, DNeutralParticleHypothesis, and DBeamPhoton objects. A loose timing cut is placed between the RF time and the DBeamPhoton objects, and additional DParticleCombo objects are created if more than one DBeamPhoton object survives the cut.
  • DAnalysisResults_PreKinFit: Loops over the DAnalysisAction objects stored in each DReaction, executing them on the corresponding DParticleCombo objects until the kinematic fit results are needed for an action (DAnalysisAction::Get_UseKinFitResultsFlag() == true). This allows DAnalysisAction objects to reject background combinations prior to kinematic fitting to save time and memory. This creates and fills histograms of the number of events and DParticleCombo objects that survive each cut. This also creates and fills several reaction-independent histograms, such as thrown and reconstructed particle kinematics, and track multiplicity.
  • DKinFitResults_factory: For each DParticleCombo that survived all of the cuts executed in DAnalysisResults_PreKinFit, perform the kinematic fit specified by the DReaction(s) (if desired).
  • DChargedTrackHypothesis_factory_KinFit: Create DChargedTrackHypothesis objects containing the kinematically fit track parameters. New, unique objects are created for each charged particle in each kinematically fit DParticleCombo.
  • DNeutralTrackHypothesis_factory_KinFit: Create DNeutralTrackHypothesis objects containing the kinematically fit track parameters. New, unique objects are created for each neutral particle in each kinematically fit DParticleCombo.
  • DBeamPhoton_factory_KinFit: Create DBeamPhoton objects containing the kinematically fit track parameters. New, unique objects are created for each beam photon in each kinematically fit DParticleCombo.
  • DParticleCombo_factory: Creates a new DParticleCombo object in each DParticleCombo that survived all of the cuts executed in DAnalysisResults_PreKinFit, but containing the kinematically fit track parameters (in addition to the original, measured parameters).
  • DAnalysisResults_factory: Loops over the DAnalysisAction objects stored in each DReaction, skipping those that were executed by DAnalysisResults_PreKinFit, and executing the remaining ones on the corresponding DParticleCombo objects created by DParticleCombo_factory. This creates and fills histograms of the number of events and DParticleCombo objects that survive each cut.

Analysis Data Object Specifics

  • DParticleCombo: PUT DETAILS ELSEWHERE!!!

Analysis Actions/Utilities Specifics

  • DAnalysisAction
  • DMCThrownMatching
  • DAnalysisUtilities
  • DKinFitter
  • DHistogramActions
  • DCutActions

DAnalysisAction Objects

Overview

  • DAnalysisAction is a virtual base class that encapsulates the setup (e.g. histogram creation) and execution (cut, hist, etc.) of the contained action for each DParticleCombo that has passed all previous cuts.
  • These objects are typically used to cut DParticleCombo objects, histogram data, or save results in a TTree, although custom actions can be written to do just about anything (perform additional kinematic fits, etc.)
    • Many common actions (e.g. histogramming kinfit pulls, comparing thrown and reconstructed MC data, etc.) are pre-defined in src/libraries/ANALYSIS/ (see DHistogramActions.h and DCutActions.h)
    • Custom, analysis-specific actions can be created and stored in the user's plugin.
  • In the DAnalysisResults factories, the DAnalysisAction objects stored in each DReaction are sequentially executed on each of the corresponding DParticleCombo objects (until they fail one of the cuts).
    • The DAnalysisAction objects should be added to the DReaction objects in the order that they will be executed.

Details

  • Construction: Each class deriving from DAnalysisAction should be designed so that no user input is required after calling the constructor.
    • For example, the constructor should contain the DReaction that the action is to be performed on, the values of the cuts to be performed, whether to operate on pre-kinematic-fit or post-kinematic-fit data, etc.
      • However, the user should be allowed to perform "optional" modifications outside of the constructor (e.g. changing the default histogram range and binning).
    • The default DAnalysisAction constructor has been disabled (made private), so each constructor of each class deriving from DAnalysisAction must explicitly call the DAnalysisAction public constructor. This is to enforce proper setup of each DAnalysisAction.
    • Within a DReaction, each DAnalysisAction needs to have a unique name (for safe multithreaded creation of histograms). This name is composed of a base-name built into the class itself that is unique to that class, and an optional unique identifier string that should be passed into the constructor by the user if more than one instance of a given class is performed in a given DReaction (e.g. make two different invariant mass histograms).
  • Execution: Each DAnalysisAction is executed by calling the function-call operator (operator()).
    • In addition to the JEventLoop, this operator needs to be passed a deque of pair<const DParticleCombo*, bool>: these contain the DParticleCombo objects that the DAnalysisAction should be executed on, and boolean flags that afterwards will indicate if the given DParticleCombo objects passed or failed the cuts performed by that action (if any).
    • If the DAnalysisAction has not yet been initialized, the function-call operator will first call the Initialize() function (see "Initialization").
    • The Perform_Action() function is then called on each of the input DParticleCombo (see "Perform Action").
  • Initialization: The Initialize() function is called by the function-call operator and is used to create histograms, TTree objects, setup cuts, or any other operations that are needed to prepare the object for performing the desired action.
    • This function must be defined in each class deriving from DAnalysisAction, and should be declared as private.
  • Creating ROOT Objects: In the Initialize() function, the following rules should be followed to create directories, histograms, etc. in the output ROOT file in an organized, thread-safe manner:
    • Acquire and release a JANA ROOT lock before (DAnalysisAction::Get_Application()->RootWriteLock()) and after (DAnalysisAction::Get_Application()->RootUnLock()) reading/creating/changing directories and creating histograms.
    • Special care should be taken when creating directories in the output file, because they may have already been created by another thread. Follow these rules for creating directories:
      • Call DAnalysisAction::CreateAndChangeTo_ActionDirectory() to create and change-to a directory that is unique to this analysis action (but NOT to this DAnalysisAction (important multithreading distinction!: each thread will have it's own unique instance of the DAnalysisAction object)), yet is shared between threads. If the directory already exists (created by another thread), it just changes to it. This directory (and any desired sub-directories) should be used to store any histograms, trees, etc. that are created by this analysis action. This is why each DReaction needs to have a unique name, and each DAnalysisAction within a given DReaction needs to have a unique name.
      • Call DAnalysisAction::CreateAndChangeTo_Directory() to create and change-to new sub-directories within the main action directory. If the directory already exists (created by another thread), it just changes to it.
    • Before creating a histogram, check the directory to make sure that it hasn't already been created by another thread (if so, just grab the pre-existing pointer from the directory rather than creating a duplicate histogram).
  • Perform Action: The Perform_Action() function is called by the function-call operator and is used to execute the action on a given DParticleCombo. It returns true/false if the DParticleCombo passes/fails the action.
    • In addition to the JEventLoop and the DParticleCombo to be acted-upon, this function is passed in a deque of pair<const DParticleCombo*, bool>: these contain the DParticleCombo objects that the action has ALREADY acted upon, and boolean flags that indicate whether they passed or failed the action.
      • The previous combos can be used (for example) to determine whether or not the quantities to be histogrammed are identical to those from a previous DParticleCombo and should be skipped to prevent double-counting (e.g. when histogramming the momentum of K<sup+</sup> candidates, two different DParticleCombo objects can have the same track used as the K<sup+</sup> candidate (but be unique otherwise)).
    • This function must be defined in each class deriving from DAnalysisAction, and should be declared as private.
  • Filling ROOT Objects: In the Perform_Action() function, a JANA ROOT lock should be acquired before (DAnalysisAction::Get_Application()->RootWriteLock()) and released after (DAnalysisAction::Get_Application()->RootUnLock()) filling any ROOT TTrees or histograms.
    • To reduce bottlenecks, the lock should be held for the minimum amount of time possible: perform all calculations prior to acquiring the lock, and release it immediately after filling everything.
    • To reduce overhead, try to acquire the lock only once per action if possible.

Tricks for saving time and memory

  • Re-use DReactionStep objects when
  • To branch an analysis, create an identical DReaction (with the same DReactionStep objects), perform all the same cuts as before, but skip the histogramming steps.

DReaction

  • Located in src/libraries/ANALYSIS/
  • The user should create a DReaction object in their plugin for each analysis they want to perform (can analyze more than one at once).

Source Code

  • C++ code of class members (methods aren't shown):
class DReactionStep
{
  private:
    // PID MEMBERS:
    Particle_t dInitialParticleID; //e.g. lambda, gamma
    Particle_t dTargetParticleID; //Unknown for no target
    deque<Particle_t> dFinalParticleIDs;
 
    // CONTROL MEMBERS:
    int dMissingParticleIndex; //-1 for no missing particles, else final state particle at this index is missing (0 -> x)
};
class DReaction : public JObject
{
  private:
    // REACTION AND ANALYSIS MEMBERS:
    deque<const DReactionStep*> dReactionSteps;
    deque<DAnalysisAction*> dAnalysisActions;
 
    // CONTROL MEMBERS:
    string dReactionName; //must be unique
    DKinFitType dKinFitType; //defined in ANALYSIS/DKinFitResults.h
    deque<size_t> dDecayingParticlesExcludedFromP4Kinfit; //to exclude decaying particles from the kinematic fit (resonances are automatically excluded) //size_t is step index where it is a parent
};

DParticleCombo

  • Located in src/libraries/ANALYSIS/

Particles

  • Particle data is contained in either DChargedTrackHypothesis, DNeutralParticleHypothesis, DBeamPhoton, or DKinematicData (for reconstructed missing or decaying particles) objects.
    • However, all of these objects are stored in DParticleComboStep as pointers to DKinematicData. If you want the DBeamPhoton, etc. objects, you need to cast them back that type.
  • Both the measured data and the kinematic fit data are accessible from these classes.
    • In DParticleCombo objects grabbed from the "KinFit" tag factory, the measured data is stored in the both the "default" and the "measured" members (e.g. dFinalParticles and dFinalParticles_Measured).
    • In DParticleCombo objects grabbed from the default (no tag) factory, the kinematic data is stored in the "default" members (e.g. dFinalParticles) and the measured data is stored in the "measured" members (e.g. dFinalParticles_Measured).
  • The source objects (DChargedTrack and DNeutralShower) and PIDs are accessible through the DParticleComboBlueprintStep.
  • Particles that are missing or are decaying may have NULL pointers stored for the objects.
    • The source and measured pointers will be NULL, and the "default" pointers will be NULL unless they are constrained by the kinematic fit (e.g. resonances are not constrained, but a Λ or a missing recoil proton will be).

Source Code

  • C++ code of class members (methods aren't shown):
class DParticleComboStep
{
  private:
    // BLUEPRINT:
    const DParticleComboBlueprintStep* dParticleComboBlueprintStep; //contains PIDs, source objects
 
    // INITIAL PARTICLES:
    const DKinematicData* dInitialParticle; //if is null: decaying or beam particle not yet set!
    const DKinematicData* dInitialParticle_Measured; //if is null: decaying or beam particle not yet set!
    const DKinematicData* dTargetParticle; //NULL for no target
 
    // FINAL PARTICLES:
    deque<const DKinematicData*> dFinalParticles; //if particle is null: missing or decaying! //these are DChargedTrackHypothesis or DNeutralParticleHypothesis objects if detected
    deque<const DKinematicData*> dFinalParticles_Measured; //if particle is null: missing or decaying! //these are DChargedTrackHypothesis or DNeutralParticleHypothesis objects if detected
};
class DParticleCombo : public JObject
{
  private:
    const DReaction* dReaction;
    const DKinFitResults* dKinFitResults;
    deque<const DParticleComboStep*> dParticleComboSteps;
};

User Plugin DReaction Factory

  • Below shows how to set up DReaction for a Y(2175) analysis.
  • Note that while most of the analysis actions are pre-defined, built-in ones (e.g. histogramming kinfit results), some are custom to the plugin (for now) (e.g. histogramming phi invariant mass).
//------------------
// init
//------------------
jerror_t DReaction_factory::init(void)
{
	// Setting the PERSISTANT prevents JANA from deleting
	// the objects every event so we only create them once.
	SetFactoryFlag(PERSISTANT);

	DReaction* locReaction;
	DReactionStep* locReactionStep;

	// Make as many DReaction objects as desired
	locReaction = new DReaction();
	locReaction->Set_ReactionName("Y2175");
	locReaction->Set_FitTypeFlag(3); //kinfit p4, v, & t simultaneously (0 is no kinfit)
 
 	//SETUP REACTION

	//g, p -> phi(2175), (p)
	locReactionStep = new DReactionStep();
	locReactionStep->Set_InitialParticleID(Gamma);
	locReactionStep->Set_TargetParticleID(Proton);
	locReactionStep->Add_FinalParticleID(Unknown); //phi(2175)
	locReactionStep->Add_FinalParticleID(Proton);
	locReactionStep->Set_MissingParticleIndex(1); //proton missing
	locReaction->Add_ReactionStep(locReactionStep);
	dReactionStepPool.push_back(locReactionStep); //prevent memory leak

	//phi(2175) -> pi+, pi-, phi
	locReactionStep = new DReactionStep();
	locReactionStep->Set_InitialParticleID(Unknown); //phi(2175)
	locReactionStep->Set_TargetParticleID(Unknown); //no target for this step
	locReactionStep->Add_FinalParticleID(PiPlus);
	locReactionStep->Add_FinalParticleID(PiMinus);
	locReactionStep->Add_FinalParticleID(phiMeson);
	locReactionStep->Set_MissingParticleIndex(-1); //none missing
	locReaction->Add_ReactionStep(locReactionStep);
	dReactionStepPool.push_back(locReactionStep); //prevent memory leak

	//phi -> K+, K-
	locReactionStep = new DReactionStep();
	locReactionStep->Set_InitialParticleID(Unknown); //phi(2175)
	locReactionStep->Set_TargetParticleID(Unknown); //no target for this step
	locReactionStep->Add_FinalParticleID(KPlus);
	locReactionStep->Add_FinalParticleID(KMinus);
 	locReactionStep->Set_MissingParticleIndex(-1); //none missing
 	locReaction->Add_ReactionStep(locReactionStep);
	dReactionStepPool.push_back(locReactionStep); //prevent memory leak
 
 	//SETUP ANALYSIS ACTIONS

	//Track reconstruction quality/multiplicity
	dReaction->Add_AnalysisAction(new DHistogramFunctor_TrackMultiplicity());
	dReaction->Add_AnalysisAction(new DHistogramFunctor_GenReconTrackComparison());

	//Vertex reconstruction and cuts of tracks with bogus vertex-z
	dReaction->Add_AnalysisAction(new DHistogramFunctor_ParticleComboKinematics(1)); //1: initial data
	dReaction->Add_AnalysisAction(new DCutFunctor_AllVertexZ(45.0, 85.0));
	dReaction->Add_AnalysisAction(new DHistogramFunctor_TrackVertexComparison());

	//PID
	dReaction->Add_AnalysisAction(new DHistogramFunctor_PID());
	dReaction->Add_AnalysisAction(new DCutFunctor_AllPID(0.01, 1)); //1%, all charged tracks
	dReaction->Add_AnalysisAction(new DHistogramFunctor_TruePID());

	//Phi Invariant Mass Cut & PID Check
	dReaction->Add_AnalysisAction(new DHistogramFunctor_PhiMass(1)); //1: initial data
	dReaction->Add_AnalysisAction(new DCutFunctor_InvariantMass(phiMeson, 1, 1.004, 1.04)); //~3sigma
	dReaction->Add_AnalysisAction(new DHistogramFunctor_TruePID());

	//Initial Proton and Y2175 Mass Distributions
	dReaction->Add_AnalysisAction(new DHistogramFunctor_ProtonMass(1)); //1: initial data
	dReaction->Add_AnalysisAction(new DHistogramFunctor_Phi2175Mass(1)); //1: initial data

	//Missing Proton Kinematic Fit
	dReaction->Add_AnalysisAction(new DHistogramFunctor_KinFitResults(0.1));
	dReaction->Add_AnalysisAction(new DCutFunctor_KinFitFOM(0.01); //1%

	//Final Proton and Y2175 Mass Distributions
	dReaction->Add_AnalysisAction(new DHistogramFunctor_ProtonMass(1)); //1: initial data
	dReaction->Add_AnalysisAction(new DHistogramFunctor_Phi2175Mass(1)); //1: initial data
	dReaction->Add_AnalysisAction(new DHistogramFunctor_Phi2175Mass(2)); //2: final data

	//Final track kinematics & PID Check
	dReaction->Add_AnalysisAction(new DHistogramFunctor_ParticleComboKinematics(2)); //2: final data
	dReaction->Add_AnalysisAction(new DHistogramFunctor_TruePID());

	_data.push_back(locReaction);

	return NOERROR;
}

User Plugin DEventProcessor

  • The DEventProcessor itself is extremely minimal in content:
extern "C" 
{
	void InitPlugin(JApplication *app)
	{
		InitJANAPlugin(app);
		app->AddProcessor(new DEventProcessor_Y2175());
		app->AddFactoryGenerator(new DFactoryGenerator_DReaction());
	}
} // "C"

jerror_t DEventProcessor_Y2175::evnt(JEventLoop *locEventLoop, int eventnumber)
{
	vector<const DAnalysisResults*> locAnalysisResultsVector;
	locEventLoop->Get(locAnalysisResultsVector);

	//SAVE PROGRAM OUTPUT HERE (e.g. surviving DParticleCombo objects, custom tuples, etc. (format undetermined)

	return NOERROR;
}

Program Output

  • Other than the built-in histograms, you are currently on your own for this. Output any data you want in either your own DAnalysisAction or in your DEventProcessor::evnt() method.