The basic concept of the ReactionFilter Plugin is to use a defined physics reaction, usually described in a configuration file, to analyze the reconstructed data (REST files) event by event testing the hypothesis of the proposed reaction. It creates an output root file referred to as Physics Analysis Root Tree (PART) which in turn will be analyzed by other code like the DSelector.
The plugin applies basic PID selection criteria (time, mass, and dEdx) and by default a Kinematic Fitter to the reconstructed charged track and/or neutral showers of each event and applies the Kinematic Fitter based on the chosen reaction requirements.
While the analyzers will usually not need to run this plugin by themselves, since this is generally done by the responsible operator running an analysis launch with all requested reactions from all analyzers at once, it is useful for any analyzer to understand the concept of the ReactionFilter plugin and its functionality, also in view of the fact that the analyzer is responsible to provide the definition of the reaction to the operator of the analysis launch.
- An introduction to the ReactionFilter plugin can be found in this DocDB document (at presentation) and some information on the wiki in Analysis DReaction. Note that most of this documentation is 5 years old and no updates have been made since then.
- Examples of how such a configuration files may look like, examine the online submission form: Create a Reaction Config File
- The particle selection criteria can be changed in the configuration file.
- Selection criteria can be applied to the reaction considered in the configuration file.
- The Kinematic fit constraints can be changed in the configuration file or the kinematic fit can also not be used at all.
- Important: Generally an analysis reaction is submitted to the global analysis system administrator, by the above link, who will run the reaction over the specified data set for all submitted reactions in one go. So the user will be provided with the resulting PART files. These files will have the specified reaction in their file name.
- This step by the administrator is called an Analysis Launch and details can be found here: Analysis Launch and Monitoring
- The output data (PART) will be located on the cache disk system of the jlab computing system. An example of such a location is /cache/halld/RunPeriod-2018-01/analysis/ver19/. The data is discriminated by Run-Period and version the latter referring to the software version begin used.
The definition of a reaction in a configuration file will look something like this:
Reaction1 1_14__7_8_9_17_14 Reaction1:Flags B2_T1_S1_M7_M17
- The first line "Reaction1" defines the reaction in this case reaction number 1. The first part before the "__" represents the initial state, in this case 1(gamma) on 14(proton target). The second part (after "__") represents the final state, in this case 7(pi0), 8(pi+), 9(pi-), 17(eta) and 14(proton). The number coding of the particles is defined in particleType.h.
- The second line "Reaction1:Flags" defines the flags associated with this reaction.
- B2 : include beam photons from two beam bunches on either side of the prompt peak
- T1 : include events with one additional reconstructed charged track if present.
- S1 : include events with on additional reconstructed shower if present.
- M7 : do NOT constrain the pi0 mass in the kinematic fit
- M17: do NOT constrain the eta mass in the kinematic fit
- By default pi0 decay into two photons and does not need to be explicitly defined and similarly for the eta. The full list of default decay channels can be found in the code of the Reaction Filter Factory (line #34).
- Explicit decay modes can be specified for particles. For example, requesting the eta decaying into pi0, pi+, pi-:
- The "1" at the end of "Decay" is a counter
- All particles of the same type (in a reaction) will decay into the same channel. So if there would be two etas in the reaction both would be treated to decay into the same channel.