Athena Configuration Tutorial

Introduction

The goal of this tutorial to complement the Athena Configuration Guide. You are invited to read it first before starting with this tutorial.

Basic Configuration Fragment Example

In this tutorial you will play with beamspot position and size information. The information about that is loaded from the conditions database. For that purpose we need to setup a conditions algorithm. Let’s look at the BeamSpotCondAlgCfg as an example:

def BeamSpotCondAlgCfg(flags, name="BeamSpotCondAlg", **kwargs):
    """Configure the BeamSpotCondAlg."""
    acc = ComponentAccumulator()

    from IOVDbSvc.IOVDbSvcConfig import addFoldersSplitOnline, addFolders
    if flags.Common.doExpressProcessing:
        acc.merge(addFolders(flags, "/Indet/Onl/Beampos<key>/Indet/Beampos</key>",
                             "INDET_ONL",
                             className="AthenaAttributeList"))
    else:
        acc.merge(addFoldersSplitOnline(flags, "INDET",
                                        "/Indet/Onl/Beampos",
                                        "/Indet/Beampos",
                                        className="AthenaAttributeList"))

    acc.addCondAlgo(CompFactory.BeamSpotCondAlg(name, **kwargs))

    return acc

The fragment above configures database access based on the Common.doExpressProcessing flag and adds BeamSpotCondAlg conditions algorithm to the ComponentAccumulator.

Before continuing let’s look at the configurable properties of the algorithm (taken from here):

SG::ReadCondHandleKey<AthenaAttributeList> m_readKey {
    this, "BeamSpotFolder", "/Indet/Beampos", 
    "DB folder from which to read raw beam spot data" };
SG::WriteCondHandleKey<InDet::BeamSpotData> m_writeKey {
    this, "BeamSpotDataKey", "BeamSpotData",
    "Key for derived conditions in conditions store" };

ServiceHandle<ICondSvc> m_condSvc { this, "ConditionsService", "CondSvc", "name of conditions service" };

Gaudi::Property<bool>  m_useDB   { this, "useDB",   true,  "read beam spot from conditions DB" };
Gaudi::Property<int>   m_status  { this, "status",  1,     "default status" };
Gaudi::Property<float> m_posX    { this, "posX",    0.0f,  "default X position" };
Gaudi::Property<float> m_posY    { this, "posY",    0.0f,  "default Y position" };
Gaudi::Property<float> m_posZ    { this, "posZ",    0.0f,  "default Z position" };
Gaudi::Property<float> m_sigmaX  { this, "sigmaX",  0.15f, "default X width" };
Gaudi::Property<float> m_sigmaY  { this, "sigmaY",  0.15f, "default Y width" };
Gaudi::Property<float> m_sigmaZ  { this, "sigmaZ",  53.0f, "default Z width" };
Gaudi::Property<float> m_tiltX   { this, "tiltX",   0.0f,  "default X tilt" };
Gaudi::Property<float> m_tiltY   { this, "tiltY",   0.0f,  "default Y tilt" };
Gaudi::Property<float> m_sigmaXY { this, "sigmaXY", 0.0f,  "default XY width" };

We see two data handles, one service handle and 10 properties. What you can immediately spot is that none of the properties are explicitly configured. Often where there is only one possible configuration of an algorithm not all properties are explicitly configured to avoid duplication. It is still preferred to set at least event-level data handles explicitly.

The next step is to try to run this algorithm. You can try doing it on your own before proceeding to the next section.