FAQ:Gaudi

From Daya Bay

Jump to: navigation, search

Frequently Asked Questions and their Answers about Gaudi.

What's the difference between a tool and an algorithm?

Algorithms are chained up in a job and run by the framework. Once per execution cycle their method:

StatusCode execute();

is called.

Tools encapsulate some procedures and are run by other Algorithms (and sometimes by other Tools). They can be shared or kept private to one object. A Tool will inherit from one or more Interface class to define what methods it exposes.

What's the difference between a tool and a service?

They are actually very similar. The main differences are:

Intent
Tools are meant to provide reusable procedures, services are meant to provide access to shared resources.
Life time
A service is created once per job and survives the entire job. A tool's lifetime may be shorter.
Accessibility
A single instance of a service class is available to all client code. Tool instances may be shared or may be kept private to a subset of all possible clients.

What's the difference between an Algorithm and a GaudiAlgorithm

GaudiAlgorithm inherits from Algorithm. It provides useful methods to sub-classes that can simplify a user's algorithm code. For example it provides simple access to the event and detector stores and to the message service. In addition NuWa provides DybAlgorithm that will do some automatic book-keeping relevant to algorithms that produce output data.

Am I correct in saying that “transient data” is a new feature we didn't have before with G4dyb?

Sort of. There is a distinction made between data in memory and data on file. User code need not and should not know anything about data on file. Instead it works on well defined data (Data Model classes) taken from and placed in a well defined place (Transient Event Store).

When we say “persistent data,” is that the data that I choose to write out of the TES and analyze?

Sort of. Normally you will write code that analyzes the transient data directly. There are times where you or the framework will write out this data for later readback. For example:

  • After CPU consuming detector simulation.
  • Post-DAQ or simulated DAQ readout.

Control over what data is written out is done either through the nuwa.py command line or configuration of any filtering algorithms.

In addition the StatisticsSvc can both write out and read back in histograms and ntuples. This is useful for

  • Analysis histograms, maybe read back to add further statistics using later jobs
  • Special purpose ntuples for, say, calibration studies.
  • Final physics-level ntuples for final analysis

From the standpoint of a user, do I need to worry too much about writing ...

AlgTools, like a GenTool?

You might write a GenTool if you wanted to generate kinematics in a way that is not currently possible with an existing one.

You may write an AlgTool if you have some useful chunk of code that can be used by others in different contexts. For example, all simulation (generation, detector, electronics, trigger and readout) is written using Tools. This lets different processing models ("push" vs. "pull") to be implemented without the need to rewrite any of the "business" code (ie, the code that actually does the simulations).

If you anticipate recursive algorithms, the "smarts" are best put into a tool. For example, consider reconstructing a vertex via the center-of-charge method. A first pass would be done using electronics-calibrated digits. Then, using this vertex, the digits can be further calibrated for light attenuation and a second fit can be done using them. The same tool can used for both passes.

Converters?

Converters will very likely always be written by the offline group members. Just know that adding to or modifying the Data Model requires writing converters.

Do services need to be called, i.e., if I want to use MsgService, do I need to call it when I initialize my algorithm, or will it be available automatically, since it's part of the framework?

It depends on the service. For basic ones like message service you do not need them. And if you inherit from GaudiAlgorithm you can easily access them via calls like:

info() << "Some information" << endreq;
warning() << "Uh oh!" << endreq;

For other services you may need to tell Gaudi to explicitly use them. For example, the detector simulation relies on the GiGa service and Gaudi is told to use it via this python code:

from  GaudiPython import AppMgr
app = AppMgr()
...
app.ExtSvc += ["GiGa"]


In TES, we have a higherarchical structure. How and where is this structure defined?

It is defined completely by convention.

Specificially, it is defined by an algorithm or a service that loads the data. These components, and components that want to read the data, should always be configured such that the TES paths can be set by the user.

The XML that defines our DataModel classes define a default path which should be honored by any componenent putting or getting the object to or from the TES. It is define relative to "/Event/". For example the SimHeader's default location is:

 SimHeaderLocation::Default

Personal tools