GlueX Analysis Software

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 (if any) (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.
This documentation is updated along with the trunk, so it may contain (minor) details that are untrue for the latest tagged release (e.g. minor interface improvements).

NOTE: For an example of the below steps, see one of the example plugins below (e.g. b1pi).

Create a new plugin containing a DEventProcessor, DReaction_factory, and DFactoryGenerator (for the DReaction_factory).
- It is recommended that you create these objects with unique names (and a unique tag for the DReaction_factory) so that this plugin can be executed with other analysis plugins simultaneously.

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 DReaction_factory::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.
- 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.*

Setup the DEventProcessor.
- 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.

Kinematic fitting with vertex constraints that contain only one detected particle do not converge very often.
- e.g. The Λ production vertex in γ, p → K⁺, Λ; Λ → p, π^-
  - Normally can include the beam photon in the vertex fit, but not if the uncertainties are all zero (MC).
- Technically the kinematic fitter works, but the analysis framework currently does not give an accurate enough initial guess for the vertex position. You can fit this case manually if your input guess is accurate enough.
Kinematic fits with spacetime constraints don't work yet.
Neutron reconstruction is not yet supported.

The target center is hard-coded as the position of the DBeamPhoton in DEventSourceHDDM.cc
Pulls of neutral shower parameters in b1pi are too wide (~1.5)
Covariance matrix of decaying particles is not set after kinematic fitting.
Generated / Detected object matching is not ideal:
- A FOM is used to determine the best match, but there is no minimum FOM: if the true track was not reconstructed, you may match the thrown track to a reconstructed ghost track.
- The FOM calculation is rough but adequate: it could be improved.
- The matching between true and reconstructed BCAL & FCAL showers has not been tested.
Multiple threads can enter the "Initialize()" method of an action simultaneously. This is especially a problem for reaction-independent actions created the a plugin's processor object (which are shared by all threads). However, don't want to put lock around it because additional locking in the method could lead to deadlock. This isn't too big a deal as long as action class members are only modified within the ROOT write lock.