Difference between revisions of "Mattione GlueX Analysis Factories"

From GlueXWiki
Jump to: navigation, search
(How it Works)
(Details)
Line 79: Line 79:
 
*** However, the user should be allowed to perform "optional" modifications outside of the constructor (e.g. changing the default histogram range and binning).  
 
*** 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.   
 
** 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()).   
 
* '''Execution''': Each DAnalysisAction is executed by calling the function-call operator (operator()).   
Line 87: Line 88:
 
* '''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.  
 
* '''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.  
 
** This function must be defined in each class deriving from DAnalysisAction, and should be declared as private.  
 +
 +
* '''Creating Histograms''': In the Initialize() function, the following rules should be followed to create directories and histograms in the output 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.  
 
* '''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.  

Revision as of 15:18, 12 October 2012

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 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 Histograms: In the Initialize() function, the following rules should be followed to create directories and histograms in the output 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.

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.

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 will be 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.

DReaction

  • Located in src/libraries/ANALYSIS
  • The factory needs to be defined in your plugin (see DReaction_factory section below)
  • User creates one of these in their plugin for each reaction they want to analyze (example shown later below) (can analyze more than one at once).
class DReaction : public JObject
{
	private:
		//REACTION AND ANALYSIS:
		string dReactionName; //must be unique: e.g. "Y2175"
		deque<const DReactionStep*> dReactionSteps;
		deque<const DAnalysisAction*> dAnalysisActions;

		//CONTROL VARIABLES:
		DKinFitType dKinFitType; //defined in ANALYSIS/DKinFitResults.h
		deque<size_t> dDecayingParticlesExcludedFromKinfit; //to exclude decaying particles from the kinematic fit (resonances are automatically excluded)
};
class DReactionStep
{
	private:
		Particle_t dInitialParticleID; //e.g. lambda, phi, gamma
		Particle_t dTargetParticleID; //Unknown for no target
		deque<Particle_t> dFinalParticleIDs;

		int dMissingParticleIndex; //-1 for no missing particles, else final state particle at this index is missing (0 -> x)
};

DParticleCombo

  • Located in src/libraries/ANALYSIS
  • DParticleCombo_factory_PreKinFit: Generates a DParticleCombo object for each possible combination of detected tracks and DBeamPhotons (configurable time cut used to eliminate way-out-of-time photons).
    • PID is NOT assumed, all possibilities are tested: For each q = +/-/0 particle in a given DReaction, all detected q = +/-/0 tracks are tested as to whether or not they are that particle.
  • DKinFitResults_factory: Performs a single kinematic fit testing whether each DParticleCombo matches the DReaction: includes all mass, vertex, timing constraints if requested.
  • DParticleCombo_factory: Create new DParticleCombo objects, using the kinematic fit track information and results.
class DParticleCombo : public JObject
{
	private:
		//REACTION AND ANALYSIS:
		const DReaction* dReaction;
		deque<const DParticleComboStep*> dParticleComboSteps;
		const DKinFitResults* dKinFitResults;

		//UNUSED TRACKS:
		deque<const DChargedTrack*> dUnusedPositiveTracks;
		deque<const DChargedTrack*> dUnusedNegativeTracks;
		deque<const DNeutralShower*> dUnusedNeutralShowers;
};
class DParticleComboStep
{
	private:
		//PIDS:
		Particle_t dInitialParticleID; //e.g. lambda, phi, gamma
		Particle_t dTargetParticleID; //Unknown for no target
		deque<Particle_t> dFinalParticleIDs;

		//INITIAL PARTICLES:
		DKinematicData* dInitialParticle; //kinfit result, else measured
		DKinematicData* dInitialParticle_Measured; //e.g. DBeamPhoton
		DKinematicData* dTargetParticle; //NULL for no target

		//FINAL PARTICLES:
		deque<const DKinematicData*> dFinalParticles; //kinfit result, else measured //e.g. DChargedTrackHypothesis, DNeutralParticleHypothesis
		deque<const DKinematicData*> dFinalParticles_Measured; //e.g. DChargedTrackHypothesis, DNeutralParticleHypothesis
		deque<const JObject*> dFinalParticleSourceObjects; //original DChargedTrack or DNeutralShower objects

		//CONTROL VARIABLES:
		int dInitialParticleDecayFromStepIndex; //points to which DParticleComboStep represents the production of the initial particle (e.g. Lambda)
		deque<int> dDecayStepIndices; //let's you know whether a final state particle is decaying, missing, or detected.  if decaying, points to which DParticleComboStep represents its decay
};

Cutting & Histogramming: DAnalysisAction, DAnalysisResults

DAnalysisAction

  • 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.
    • 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 plugin, along with any custom factories you need for them (e.g.: studying the background).
    • These actions should be added to the DReaction objects in the order that they will be executed.
class DAnalysisAction
{
	public:
		//returns true/false if passes/fails cut/hist/etc.
		virtual bool operator()(JEventLoop* locEventLoop, map<const DParticleCombo*, bool>& locParticleCombos) const = 0;
};

DAnalysisResults

  • Loops over all DReaction objects, executing the DAnalysisAction objects for each one. Returns the cut status of each DParticleCombo (which cut they failed on, if any).
class DAnalysisResults : public JObject
{
	private:
		DReaction* dReaction;
		map<const DParticleCombo*, size_t> dFailedParticleComboMap; //indicates at which action these DParticleCombo failed to pass the cut
		deque<const DParticleCombo*> dPassedParticleCombos; //DParticleCombo objects that passed all DAnalysisAction cuts. 
};

Simple Example

  • Cutting the confidence level of a kinematic fit:
class DAnalysisAction_KinFitFOM : public DAnalysisAction
{
 	public:
		double dMinimumConfidenceLevel; //e.g. 0.01

		DAnalysisAction_KinFitFOM(double locMinimumConfidenceLevel) : dMinimumConfidenceLevel(locMinimumConfidenceLevel) {} //cut setup upon construction

		bool operator()(JEventLoop* locEventLoop, map<const DParticleCombo*, bool>& locParticleComboStatusMap) const
		{
			bool locEventPassedCutFlag = false;
			//loop over all particle combos and perform the cut (unless already failed a previous cut)
			for(map<const DParticleCombo*, bool>::iterator locIterator = locParticleComboStatusMap(); locIterator != locParticleComboStatusMap(); ++locIterator)
			{
				if(!locIterator->second)
					continue; //particle combo failed a previous cut!

				const DParticleCombo* locParticleCombo = locIterator->first;
				DKinFitResults* locKinFitResults = locParticleCombo->Get_KinFitResults();
				double locConfidenceLevel = locKinFitResults->Get_ConfidenceLevel();

				if(locConfidenceLevel > dMinimumConfidenceLevel)
					locParticleCombos[locParticleCombo] = false; //mark the DParticleCombo as having failed the cut
				else
					locEventPassedCutFlag = true; //at least once DParticleCombo passed the cut 
			}
			return locEventPassedCutFlag;
		}
};

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 histograms, I haven't really gotten this far yet...