Difference between revisions of "Analysis FAQ"

From GlueXWiki
Jump to: navigation, search
(What do I need to know about multithreading with JANA?)
(What do I need to know about multithreading with JANA?)
Line 21: Line 21:
 
** Only one instance of a given ROOT file, directory, histogram, or tree should be created.  
 
** Only one instance of a given ROOT file, directory, histogram, or tree should be created.  
 
*** In processors, they should be created in the init() method, so that only one thread will attempt to create them.  
 
*** In processors, they should be created in the init() method, so that only one thread will attempt to create them.  
*** In factories and analysis actions, each thread should acquire a ROOT lock (see histogramming section), and first check to see if the histogram/etc. has already been created. If so, it should grab a pointer to the existing histogram/etc. instead of creating a duplicate.
+
*** In factories and analysis actions, each thread should acquire a ROOT lock (see histogramming section), and first check to see if the histogram/etc. has already been created. If so, it should grab a pointer to the existing histogram/etc. instead of creating a duplicate. Example:
 +
 
 +
<syntaxhighlight>
 +
japp->RootWriteLock(); //ACQUIRE ROOT LOCK!!
 +
{
 +
  if(gDirectory->Get("MyHistName") != NULL) //already created by another thread
 +
      dMyHist = static_cast<TH1D*>(gDirectory->Get("MyHistName"); //grab the pointer to the pre-existing object
 +
  else
 +
      dMyHist = new TH1D("MyHistName", "MyHistTitle", 100, 0.0, 1.0); //create the histogram
 +
}
 +
japp->RootUnLock(); //RELEASE ROOT LOCK!!
 +
</syntaxhighlight>
 +
 
 
** Except within the processor init() method, any time a ROOT histogram/file/tree/directory is created/modified/filled, it should occur within a ROOT lock:
 
** Except within the processor init() method, any time a ROOT histogram/file/tree/directory is created/modified/filled, it should occur within a ROOT lock:
  
Line 29: Line 41:
 
   dMyHist->Fill(locValue);
 
   dMyHist->Fill(locValue);
 
}
 
}
 +
japp->RootUnLock(); //RELEASE ROOT LOCK!!
 
</syntaxhighlight>
 
</syntaxhighlight>
  

Revision as of 12:38, 19 July 2014

JANA

What do I need to know about multithreading with JANA?

  • To run JANA with 'X' threads, add the following to the command line when running hd_root:
-PNTHREADS=X
  • Event Processors (They drive JANA, and are in your plugins):
    • All threads share/use the same instance of an event processor. Thus, you must be careful when setting/modifying processor member variables.
    • The init() method is guaranteed to be called by only one thread. Any code in here will be thread safe.
    • The brun() method will be called by each thread. Be VERY careful when modifying processor member variables here, as one thread may still be analyzing an event with the previous run number.
    • The evnt() method will be called by each thread. See the histogramming section about how to safely fill histograms.
  • Factories (They create most JANA objects):
    • Each thread will have it's own instance of each factory. Thus, factory member variables can be safely modified without locks. You still need to be careful about ROOT objects (below).
  • ROOT:
    • Only one instance of a given ROOT file, directory, histogram, or tree should be created.
      • In processors, they should be created in the init() method, so that only one thread will attempt to create them.
      • In factories and analysis actions, each thread should acquire a ROOT lock (see histogramming section), and first check to see if the histogram/etc. has already been created. If so, it should grab a pointer to the existing histogram/etc. instead of creating a duplicate. Example:
japp->RootWriteLock(); //ACQUIRE ROOT LOCK!!
{
   if(gDirectory->Get("MyHistName") != NULL) //already created by another thread
      dMyHist = static_cast<TH1D*>(gDirectory->Get("MyHistName"); //grab the pointer to the pre-existing object
   else
      dMyHist = new TH1D("MyHistName", "MyHistTitle", 100, 0.0, 1.0); //create the histogram
}
japp->RootUnLock(); //RELEASE ROOT LOCK!!
    • Except within the processor init() method, any time a ROOT histogram/file/tree/directory is created/modified/filled, it should occur within a ROOT lock:
japp->RootWriteLock(); //ACQUIRE ROOT LOCK!!
{
   dMyHist->Fill(locValue);
}
japp->RootUnLock(); //RELEASE ROOT LOCK!!

Neutrals

Given a DNeutralParticleHypothesis or DNeutralShower object, how do I get the FCAL/BCAL shower objects?

  • Answer: By calling the inherited JObject::GetSingle() function:
//given a hypothesis, get the neutral shower:
const DNeutralShower* locNeutralShower = NULL;
locNeutralParticleHypothesis->GetSingle(locNeutralShower);
 
//given a neutral shower, get the BCAL shower:
const DFCALShower* locFCALShower = NULL;
if(locNeutralShower->dDetectorSystem == SYS_FCAL)
   locNeutralShower->GetSingle(locFCALShower);
 
//given a neutral shower, get the FCAL shower:
const DBCALShower* locBCALShower = NULL;
if(locNeutralShower->dDetectorSystem == SYS_BCAL)
   locNeutralShower->GetSingle(locBCALShower);

Histogramming

How do I manually create and fill a histogram in my plugin's processor in a way that is thread-safe?

//If not already present, include the appropriate ROOT header file in your processor header file:
#include "TH1D.h" //1 dimensional ("1") histogram containing doubles ("D")
 
//Define your histogram in your processor class definition:
TH1D* dMyHist;
 
//Create your histogram in your processor init() method:
   //Note that you do not need a ROOT lock here, since the init() method of event processors is only called by one of the threads. 
   //If you were doing this in a factory or an analysis action, you would need a ROOT lock here. 
dMyHist = new TH1D("HistName", "Hist Title;X-axis Title;Y-axis Title", 100, 0.0, 1.0); //100 bins from 0 to 1
 
//Fill the histogram in your processor evnt() method, but within a ROOT lock:
double locValue = 1.0;
japp->RootWriteLock(); //ACQUIRE ROOT LOCK!!
{
   dMyHist->Fill(locValue);
}
japp->RootUnLock(); //RELEASE ROOT LOCK!!
 
//The histogram is automatically saved to hd_root.root, or the file you specified with "-o" on the command line.

Cuts

How do I place a cut prior to kinematic fitting?

  • Answer: Add an analysis action to the DReaction that performs the cut. It should be added prior to any action that uses the kinematic fit results. If no action uses the fit results, then it can be added anywhere.
   //E.g.: Place cut on pi0 invariant mass (assuming a Pi0 decay step is defined in your DReaction): 
      //the false means "used measured data" as opposed to kinfit data
      //0.04 and 0.24 specify the minimum and maximum invariant mass
   locReaction->Add_AnalysisAction(new DCutAction_InvariantMass(locReaction, Pi0, false, 0.04, 0.24)); //does not require kinfit results
 
   //Histogram kinematic fit results
   locReaction->Add_AnalysisAction(new DHistogramAction_KinFitResults(locReaction, 0.05)); //requires kinfit results
 
   //Thus, the kinematic fit is performed between execution of these actions. If a combo fails a cut prior to the kinfit, then the kinfit is not performed for that combo.