Difference between revisions of "Analysis DReaction"

Latest revision as of 10:34, 17 March 2022

Summary

• Note: The objects (not the factory) are located in: $HALLD_HOME/src/libraries/ANALYSIS/
  • the ReactionFilter factory is in $HALLD_HOME/src/plugins/Analysis/ReactionFilter.
• DReactionStep: Contains the particle types for an interaction or decay step in a reaction.
  • The particle types are from the Particle_t enum defined in sim-recon/src/libraries/include/particleType.h
• DReaction: Contains the DReactionStep objects for a reaction, along with (optional) analysis actions/instructions.
• DReaction_factory: Users should create the DReaction objects they want to study in this factory, and place it in their plugin.
  • It is recommended that users create their class with a unique name and corresponding tag so that multiple analysis plugins can be run simultaneously.
• The MakeReactionPlugin.pl perl script (it is installed to $PATH) can be used to create template code for a new plugin.

DReaction Notes

• The user should create a DReaction object in their plugin for each analysis they want to perform (can analyze more than one at once). For example, by creating additional DReaction objects you can:
  • Analyze different reactions in the same plugin.
  • Treat different particles as missing in the same reaction (or have no particles missing).
  • Perform different kinematic fits to the same reaction (e.g. compare results from p4-only and vertex-p4 fits)
  • Perform different DAnalysisActions to compare the results from having different cuts.

• IMPORTANT NOTE FOR DEVELOPERS: Grabbing the DReaction objects from JANA is tricky, because a user may have several factories per plugin, or may be running several plugins at once. See DParticleComboBlueprint_factory::evnt() for an example on how to correctly grab all DReaction objects from JANA.

DReactionStep Notes

• The DReactionStep objects must be added to the DReaction in the correct order: the decay step for a particle must always be after its production step (it can be anywhere after it, but it must be after it).
  • However, you can study (for example) π⁰ decays without a π⁰ production step if you don't care how they're produced. E.g.:

//pi0 -> gamma, gamma
DReaction* locReaction = new DReaction("pi0"); //unique name
locReaction->Add_ReactionStep(new DReactionStep(Pi0, {Gamma, Gamma}));

• To define one of the particles as missing, add it after the list of final state particles

locReaction->Add_ReactionStep(new DReactionStep(Gamma, Proton, {PiPlus, PiMinus}, Proton)); //proton is missing, pi+/- are detected

• To analyze a channel inclusively (with no missing particles otherwise (the Unknown below)):

locReaction->Add_ReactionStep(new DReactionStep(Gamma, Proton, {PiPlus, PiMinus, Proton}, Unknown, true)); //proton/pi+/- are detected, nothing is missing (Unknown), inclusive (true)

• IMPORTANT NOTE FOR ANALYZERS: Resonance PIDs (except for ω and φ) are not allowed anywhere in a DReactionStep. This is because you cannot identify on an event-by-event basis which particles decayed from a resonance and which did not. However, since they are extremely narrow, the ω and φ resonances are allowed.

• IMPORTANT NOTE FOR ANALYZERS: The Unknown PID can be used as an initial particle (for when you don't want to worry about beam particle selection). If a kinematic fit with a P4 constraint is selected, then four-momentum will not be constrained but any mass constraints still will be (inclusive kinematic fit).

• To disable a mass constraint from being applied during a kinematic fit, call the following on the DReactionStep where that particle is the initial particle:

locReactionStep->Set_KinFitConstrainInitMassFlag(false);

DReaction Control Variables

Kinematic Fit Type

• Defined by the DKinFitType enum in sim-recon/src/libraries/Analysis/DReaction.h
  • Values: d_NoFit, d_P4Fit, d_VertexFit, d_SpacetimeFit, d_P4AndVertexFit, d_P4AndSpacetimeFit
  • P4 fits include mass constraints
  • The spacetime fits are currently unsupported.

TTree Output

• If creating your own plugin, output the results from the analysis of a DReaction is disabled by default, and must be enabled for each desired DReaction. This enabling is in addition to actually writing out the TTree (see Standard TTree for details). To enable TTree output for a DReaction, call:

// string is file name (must end in \".root\"!!): doen't need to be unique, feel free to change
locReaction->Enable_TTreeOutput("tree_b1pi.root", false); //true/false: do/don't save unused hypotheses

• Note that if you specify more than one DReaction to have the same file name, then they will both be saved in the same file.

Comboing Cuts

• There are several different cuts the user can place to cut out potential particle combinations that are "obviously" invalid before they are created.
• These are useful for reducing memory usage spikes and cpu-time, especially in events with many (10+) garbage tracks/showers (in some cases the # of DParticleCombos can exceed 20000)
• Most of these cuts are disabled by default.
• The values of these cuts are overridden if specified on the command line.

Custom Track / Shower Pre-selection

• Users can place custom cuts to select a subset of the reconstructed DChargedTrack and DNeutralShower objects.
  • To do this, create factories in your plugin(s) that perform the desired cuts.
  • Tracks and showers that survive these cuts should be copied and saved as data members of those factories.
  • In addition, make sure to create a factory of the DNeutralParticle objects corresponding to your DNeutralShower's (use the PreSelect DNeutralParticle factory as an example).
  • Then, specify which factories you would like to use on the command line with "COMBO:TRACK_SELECT_TAG" and "COMBO:SHOWER_SELECT_TAG". For example:

  hd_root dana_rest.hddm -PPLUGINS=b1pi_hists -PCOMBO:TRACK_SELECT_TAG=MyTracks -PCOMBO:SHOWER_SELECT_TAG=MyShowers

• To disable them entirely (and use all tracks and showers), do:

  hd_root dana_rest.hddm -PPLUGINS=b1pi_hists -PCOMBO:TRACK_SELECT_TAG= -PCOMBO:SHOWER_SELECT_TAG=

• Example: A pre-selection factory cutting on the DNeutralShower energy (where "MyShowers" is the factory tag):

jerror_t DNeutralShower_factory_MyShowers::init(void)
{
  //Setting this flag makes it so that JANA does not delete the objects in _data.  This factory will manage this memory. 
    //This is because some/all of these pointers are just copied from earlier objects, and should not be deleted.  
  SetFactoryFlag(NOT_OBJECT_OWNER);
 
  return NOERROR;
}
jerror_t DNeutralShower_factory_MyShowers::evnt(JEventLoop* locEventLoop, int locEventNumber)
{
  //Clear previous memory
    //IF YOUR FACTORY CREATES NEW OBJECTS: be sure to manually delete them since NOT_OBJECT_OWNER is set. 
  _data.clear();
 
  //Grab already pre-selected showers. 
  vector<const DNeutralShower*> locNeutralShowers;
  locEventLoop->Get(locNeutralShowers, "PreSelect");
 
  //Place further cuts
  for(size_t loc_i = 0; loc_i < locNeutralShowers.size(); ++loc_i)
  {
    if(locNeutralShowers[loc_i]->dEnergy < 0.02) //e.g. 20 MeV
      continue;
    _data.push_back(const_cast<DNeutralShower*>(locNeutralShowers[loc_i])); //save a copy of the shower
  }
  return NOERROR;
}

• Tell JANA that your factory exists by setting it in your plugin's factory generator:

jerror_t GenerateFactories(jana::JEventLoop *loop)
{
  loop->AddFactory(new DReaction_factory_b1pi_hists());
  loop->AddFactory(new DNeutralShower_factory_MyShowers());
  return NOERROR;
}