Using Properties With AnaAlgorithms

Last update: 30 Oct 2018 [History] [Edit]

Properties are handled with analysis algorithms in the same way in which they are handled in Athena/Gaudi.

  • You declare a variable as a member of your algorithm class;
  • You call declareProperty(...) in the constructor of your algorithm to declare this property to the framework;
  • You set the value of the property in your submission script/macro or jobOptions, to set/override it.

Declaring/Using Properties

In the C++ code, declare two simple properties for now. A float and an std::string one. Do this by adding this near the end of your algorithm class’s declaration, in its header:

private:
  /// Electron pT cut
  double m_electronPtCut;
  /// Sample name
  std::string m_sampleName;

tip The names of the properties are just meant to give you an idea of what sort of things one would usually set up as a property on an algorithm. Don’t take these examples too seriously.

Now, add the following to the constructor of your algorithm to declare these properties:

  declareProperty( "ElectronPtCut", m_electronPtCut = 25000.0,
                   "Minimum electron pT (in MeV)" );
  declareProperty( "SampleName", m_sampleName = "Unknown",
                   "Descriptive name for the processed sample" );

And to be able to double-check later on that we can modify these properties, print their values in the initialize() function with code like this:

  ANA_MSG_INFO( "ElectronPtCut = " << m_electronPtCut );
  ANA_MSG_INFO( "SampleName    = " << m_sampleName );

warning There are a finite number of types supported as algorithm properties. In general try to use as simple properties as possible. The current list of supported types is:

  • double;
  • int;
  • std::string;
  • std::vector of the previous types.
  • ToolHandle
  • AnaToolHandle if you use AnaToolHandle::declarePropertyFor to declare the property

Setting Algorithm Properties During Configuration

The main purpose of algorithm properties is to be able to customize them during the configuration step. If you use the python configuration this is straightforward.

Go back to the ATestRun_eljob.py macro (or ATestRun_jobOptions.py in Athena) that you created earlier. In it you create an algorithm object called alg. You can set properties on that object with:

alg.ElectronPtCut = 30000.0
alg.SampleName = 'Zee'

If you are using the C++ configuration instead, you would add these lines to your ATestRun_eljob.cxx macro:

alg.setProperty( "ElectronPtCut", 30000.0 ).ignore();
alg.setProperty( "SampleName", "Zee" ).ignore();

Direct Configuration During Algorithm Creation

If you want, you can also directly specify the properties when you create the algorithms (in python).

For EventLoop that is:

alg = AnaAlgorithmConfig( 'MyxAODAnalysis/AnalysisAlg',
                             ElectronPtCut = 30000.0,
                             SampleName = 'Zee' )

For Athena that is:

alg = CfgMgr.MyxAODAnalysis( 'AnalysisAlg',
                             ElectronPtCut = 30000.0,
                             SampleName = 'Zee' )

Pre-existing Algorithm Properties

The EL::AnaAlgorithm base class declares some properties of its own. The most important ones that you should be aware of are:

  • “OutputLevel”: The minimum level for the printed messages. This property allows you to either turn on DEBUG / VERBOSE messages for an algorithm, or to possibly turn off its INFO messages, if you don’t want to see those. You should set it either from simple integers (1: VERBOSE, 2: DEBUG, etc.), using the ROOT.MSG.VERBOSE, ROOT.MSG.DEBUG, etc. values (in EventLoop jobs), or using the VERBOSE, DEBUG, etc. variables (in Athena jobs).
  • “RootStreamName”: The name of the stream to create ntuples/histograms in. In Athena this controls both the destination of histograms and trees, while in EventLoop it only controls the destination of the trees. By default it is set to “ANALYSIS”, meaning that you need to create output streams with that name in your jobs in most cases.