---

userGuide Class Reference

User Guide information, class used to make documentation with doxygen. More...

#include <userGuide.h>

List of all members.

Public Methods
	userGuide ()
	default constructor.
virtual	~userGuide ()
	default destructor.
virtual void	writeOut () const
	writeOut the guide.

---

Detailed Description

User Guide information, class used to make documentation with doxygen.

userGuide contains a general information for the user

Introduction

Centella is a framework to process data from one representation into another.
Centella has been developed at the University of California Santa Cruz, to reconstruct the GLAST 2000 test beam data, SLAC, 2000.
Centella inherit GAUDI's philosophy. It keeps the concepts in their minimal expresions.

Centella Philosophy

data processors

A data processor turns data from one representation into another. Most of HEP software programs are data processors. Lets consider a reconstruction program, it converts raw data , (ADC values, strips ID's, etc) into reconstructed data (that is, tracks, vertexes, clusters, etc), or physical data (momenta of the particle, ID's of particles and interactions points,etc).
The GAUDI philosophy consider that a data processor program is well described separating data from algorithms.. Data turns to be simple store places where data values are located, and algorithms are the processes that create and manipulate the Data. This seems to be a pass ahead of object orienting programming, where algorithms should be methods of the data classes. This separation is nevertheless very convenient. It adds flexibility and reusability to the code, but most important, it creates a sort of language where data became subjects in a sentence where the algorithms are the verbs. The program turns to therefore a collection of grammar sentences where algorithms are applied to data classes.
In addition with algorithms, most of data processors, could use filters or selections, that we called cuts. A cut is a class that knows if a certain condition of the data or the algorithms has been fulfilled. The program could change its behavior if one cut is realized or not.
Centella uses data, algorithms, and cuts classes.
GAUDI divides the data in two: transient, and persistent data. Persistent data is data store in Durable support: disk, tapes, etc. The transient data is the data that only live during the run time of the program. GAUDI suggests creating transient data copies of the persistent data in order to be "independent" of the persistent data support chosen. Therefore they should be a collection of converters that transform persistent data into transient and vicecersa.

High Energy Physics processors

Lets consider now a HEP program, we can realize that it will need the following generic data classes:

• A detector data class. Every experiment has a detector, which as a physical object will have most likely a collection of geometrical nested volumes, and some detector active areas that will create responses to the pass of particles. We will need most likely a generic geometry and identification of the active and passive part of the detector. The geometry of the detector will be unique.
• Detector calibration data. Some part of the detector will need calibration data to operate, that could be a list of pedestals for the calorimeter, and alignment correction values for tracking devices, etc. Most likely, this data is valid only for a period of time or a collection or runs.
• 
  Event data. That contains the results of the interaction of particles with the detector. In general we have a basic element with is the data of a given event (maybe only one interaction or trigger of the detector), and a collection of events, most likely consecutive and that share some common setup characteristics, that we call run. The event data can be presented in different representation, it can be MonteCarlo data, Raw data, Reconstructed data, analysis data, etc.

Centella does not provide any class to implement the detector geometry. The user should create that class, it can use for example GEANT4.
Centella transient data is devided into calibration (detector) or event data. All the transient data inherits from trsDataVI base class.
Centella does not provide any base class for the permanent data and how to implement the converters. But we provide base classes to use ROOT trees and file, and also histograms and ntuples using ROOT. We provide a converterVI base class for converters, and a algorithmImport to create algorithms from methods of classes.

If we now consider the algorithms, we can realize that there are two nested tasks: a run, that will process collection of events, and the event task, which are the task executed for every event. In more detail, a event task is most likely separated into three tasks, that we call: generation, reconstruction, and analysis.
In the generation part, whatever is the initial point (data or MonteCarlo) the task creates the detector response to one event. In other words will create (or maybe load) the raw data. Data that contains only ADC values, etc. In the reconstruction part the Raw data is converter into reconstructed data, for example, the reconstruction algorithms will use the raw data, and most likely the geometrical description of the detector and the calibration data, to create reconstructed data. Lets say an algorithm that from the ADC values of a tracker devices creates clusters with physical positions will be an algorithm of the reconstruction task. Finally, the data is converter into the "physical" data, the closest representation to the original particle and its interaction. For example, we transform tracks into particle momentum.
Centella includes a Run algorithm (named runRunAlg) and an Event algorithm (named runEventAlg) . And the Event algorithm (eventTask) is divided into generation, reconstruction and analysis algorithms. In fact the Event algorithm can be constructed with several event algorithms.

User implementation of Centella

What classses should users implement and how to declare them into the system?

• Detector Data Geometry:
  • implementation: the user should implement the geometry detector data class
  • declaration: typedef the class name into the header file "userDetectorGeo.h"
• Input/Ouput files And persistency data:
  • implementation:
    • the user should implement Input/Output persistent data servers classes.
    • the data server classes have to inherit from IOfileVI base class. They should handle the typical operation of open/close files, etc, defined in IOfileVI.
    • Most likely the persistent data servers will contain the persistent data. There is no base class for persistent data in Centella.
    • The user should create converters or algorithms to convert the transient data into persistency and viceversa.
    • It the user want to declare some converters into the system, the persistent data servers should inherit from converterServer class.
    • the user converters can inherit from converterVI class.
  • declaration:
    • typedef the IO persistent data server classes names into the header file of "userIOfiles.h"
    • In the case that the IO persistent data server classes inherit from converterServer. the user defined converters can be added into the system via the addConverter() method of the converterServer, there is a method defineConverters() for the convenience of the user.
• Event transient data:
  • implementation:
    • the user should implement the event transient data classes. They may containt the data varaibles, the containers and some access methods.
    • the event transient data classes have to inherit from trsDataVI base class.
  • declaration:
    • the user should create the event data classes and add them into the dataEventServer using the addData() method.
    • there user can use the constructor of the userDataEvent class to create and add the data into the system.
• Detector transient data:
  • implementation:
    • the user should implement the detector transient data classes. They may containt the data varaibles, the containers and some access methods.
    • the detector transient data classes have to inherit from trsDataVI base class.
  • declaration:
    • the user should create the detector data classes and add them into the dataDetectorServer using the addData() method.
    • there user can use the constructor of the userDataDetector class to create and add the data into the system.
• Algorithms:
  • implementation:
    • the user should implement the algorithms classes. There are some algorithm classes that are automatically created by the system. They include the system algorithms: all the comClasses (see centellaAlgorithms constructor), for example "comOpenIO", or the main application "centellaAlg". In addition some of the user classes creates algorithms, this is the case for the converters which create the "load" and "save" algorithms. and the rHistoFolder (a fonder to store, book and fill ROOT histograms) that creates a "fill" algorithms. But most of the algorithms should be implemented by the user.
    • The user algorithms have to inherit from algorithmVI class, or other system algorithmVI derived classes such as: algorithmComposite, algorithmTree, algorithmConditional, etc.
  • declaration:
    • the user should create algorithm classes and add them into the processManager using the addAlgorithm() method.
    • there user can use the constructor of the userAlgorithms class to create and add the data into the system.
• Cuts:
  • implementation:
    • the user should implement the cuts classes. There are some cuts classes that are automatically created by the system. They are the system cuts (see centellaCuts) for or example "conNextEvent", which returns if there is or not a next event availebel in persistency.
    • The user cuts have to inherit from curVI class, or other system cutVI derived classes such as: cutComposite.
  • declaration:
    • the user should create the cut classes and add them into the selectionManager using the addAlgorithm() method.
    • there user can use the constructor of the userCuts class to create and add the data into the system.

How to set options into classes?

Users can set options into classes wich have the services of serviceI (or optionV), and have declared in their constructor some parameters as options.
The optionManager class applies the system options from a file that we will call system option file. The default input file is "centella.in".
The sytem options are grammar lines in the system option file. The options are set with the following grammar lines :
objectName optionName \ e optionType optionValue
where:

• objectName is the name of the object to which an option is going to be applied.
• optionName is the name of the option.
• optionType is the type of the option: it can be "I","D", or "S", for integer, double, or string.
• optionValue is the value of the option.

To list of the options declared in the system, execute the algorithm "comListOptions"
.

How to indicate the input and output file names

The user should use the system option ifile and incorporate on it a grammar line to execute some options of the IOfileServer. These are the grammar lines:
IOfileServer InFile S input_file_name
IOfileServer OutFile S ouput_file_name

How to create dinamically multialgorithms, or multicuts and how to execute them

The user can create algorithms, cuts, and execute other simple operations, via some system options already defined. This operations are grammar lines in the system option ile (the file that by defualt is centella.in).

• the user can indicate the application algorithm that runs the program with the option "application" of the processManager. Use this line of grammar:
  processManager application S \eJose's_application
  The default application is called "centellaAlg".
• the user can create algorithmTask, eventTask and algConditionalTask,(see processManager for mor details).
  To create for example a multiAlgorithm where the user can add several algorithms. use the following lines or grammar:
  processManager newAlgorithmTask S Jose's_application
  Jose's_application addAlgorithm S Algorithm_sayHello
  In this example Jose implemented and algorithm called "sayHello, declared into the system. To executed he created a run time algorithmTask named Jose's_application added his algorithm Algorithm_sayHello to it, and with the line of grammar of the application aboce, made the algorithm Jose's_application the main application to be run by Centella.
  eventTask, and algConditionalTask have their own options, the user can explore them via the documentation. <le> The user can also create cutSelectionTask (a multiCut that executed the AND of all its cuts). or add cuts to a cutSelectionTask using the options. To create a cutSelectionTask, use this line of grammar:
  selectionManager addCutSelectionTask S Jose's_selection
  To add a cut in this selectio, use this line:
  Jose's_selection addCut S cut_Jose'sBirthDay
  Jose'sBirthDay is a cut implemented by the user Jose and declared into the system. The cutSelectionTask will have apply this cut.

Definition at line 210 of file userGuide.h.

---

Constructor & Destructor Documentation

userGuide::userGuide ( ) [inline]

default constructor.

Definition at line 216 of file userGuide.h.

userGuide::~userGuide ( ) [inline, virtual]

default destructor.

Definition at line 218 of file userGuide.h.

---

Member Function Documentation

void userGuide::writeOut ( ) const [inline, virtual]

writeOut the guide.

Definition at line 221 of file userGuide.h.

---

The documentation for this class was generated from the following file:

• userGuide.h

---