status of the cuore software marco pallavicini cuore co-software coordinator with m. pavan (milano)...

Status of the Cuore Status of the Cuore softwaresoftware

Marco PallaviciniCuore Co-Software coordinator with M. Pavan (Milano)

Università di Genova & INFN

Berkeley, Tutorial on Cuore Software Environment 01-22-2007 M. Pallavicini - Università di Genova & INFN

Talk overviewTalk overview

Cuore Software environment

Apollo, Diana, Fluka, Geant 4

The Diana Framework

Modules

Sequences

The Diana Event

The root event(s)

Compatibility with previous software

Software and environment pre-requisitesCompilers, UNIX flavours, SVN, GSL, ROOT, environment variables


Apollo & DianaApollo & Diana

Apollo & DianaThese codes are very different, but they share a common software environment

Apollo is the ONLINE code data taking & data monitoringevent displayrun controlelectronics controlslow controlonline prompt reco and possibly, preliminary analysis

Diana is the OFFLINE RECONSTRUCTION codeSingle pulse analysisCalibration StabilizationSpectral analysisPhysics tools for neutrino mass and similar

Warning: as explained later,Diana is ALSO used online


Fluka and Geant4 MCFluka and Geant4 MC

G4 developed in Milano so farStill to be integrated in the common environment

A lot of work still ahead

See Fabio Bellini’s talk for details

FlukaImportant for specific studies where G4 is not considered reliable (low energy neutrons expecially)

Not clear whether we will maintain it as a general purpose code or not

Man power issue !


Main QFrameWork featuresMain QFrameWork features

Diana is designed to run an ordered list of QSequence(s), each of them composed of an ordered list of QModule(s)

The “module” is the smaller software unit that acts on the QEvent perfoming some action and storing the result into the QEvent itself.

Each module is of course an object instance of a class inheriting from QModule

The Diana framework (QFrameWork) support iterations (each sequence can be run more than once, and the modules can control this. Each module knows which iteration is being run. )

The QEvent class allow each module to write ONLY in its own variables (a module X cannot write on variables owned by Y). Read acces is always granted to all modules

The Framework support a GUI that will be able to control the analysis flow (re-run one event after some parameter change, re-iterate a sequence, select events with visual inspection and save on disk). NOT IMPLEMENTED YET!


ConfigurationConfiguration

The list of modules and the list of sequences that are run is controlled by a single configuration file.

On the left, a simple example

Each module can have an arbitrary number of parameters of any type (right now only int, float and string are supported)

Type is determined automatically (first check int, then float then string)

Other types (i.e. vectors) might be added if required

Right now modules can be used more than once in a sequence. We will remove this feature!

sequence s_name

reader my_reader

enable = 1

verbosity=1

my_private_int_par = 2

my_private_float_par = 2.

my_private_string_par = ciao

endmod

module my_module

enable = 1

verbosity=1


my_private_float_par = 2.3

my_private_string_par = ciao ciao

Endmod

writer my_reader

enable = 1

verbosity=1


endmod

endseq


What’s a module ?What’s a module ?

A class inheriting from QModule implementing the following virtual functions:

virtual void Init()

virtual QEvent* Do(QEvent *ev)

virtual void Done()

InitCalled before starting event loop at each sequence

DoPerform an action on the event

DoneCalled at the end of the event loop

Trivial example:

Here book your histograms and open your own private root file

Here compute what you wish, and fill histograms

Here write histograms and write files


Readers and WritersReaders and Writers

Each QSequence must have at least one “reader” and one “writer”Without an input you do nothing

Without an output, what you do is useless (output is not necessarily a file. Could be some record into the data base, for example in calibration)

A reader is a module that fills a QEvent from an input (file, network connection or any other input source)

A writer is the output module, the one which writes the root file or any other output file

The framework handles them differently from other modules


Procedure to write a new Procedure to write a new modulemodule

1) Discuss this with software management and agree with him the module name, and the package. The Software manager will update the module factory, so that your module can be run inside the framework

2) Write the module. Store your output temporarily into the AuxData container (see this afternoon for details)

3) Define which output variables will be stored into the event, at least at first approximation

4) Test your module

5) When module is ready, the QEvent will be updated with the new variables, the module will officially exist

6) Modules should not be too big. One well defined task one module. Main algorythms and “intelligent” actions should be done by service classes that might be re-used in other modules.

7) Think to physics BEFORE starting writing code

GENERAL RULES

The developer should never modify the module factory, the QEvent and the framework classes

Module names must be agreed with software managers

Code committed into repository should ALWAYS at least compile with 0 errors and possibly 0 warnings

The variables you need to write into QEvent must be agreed with QEvent package coordinator

Rule n. 0 is of course common sense. The SVN repository is not write protected, and we rely on developers good will (unless events will force us to change policy….)


The Diana Event: QEventThe Diana Event: QEvent

Each module receives the event as a pointer Do(QEvent*)

All QEvent variables are private. Public getters are given, so all variables can be read by any moduleEach QEvent sub-section is friend of a specific module, so that only that module can write the variables

Each subsection is an object of a class inheriting from QEventData class

Besides, the QEvent has a public container (map) where any object can be stored Int, Double, std::string and QObjects can be stored. In case of QObjects the module is responsible of the right casting.This QContainer is added for variables that are not supposed to be saved OR for quick tests

The QEvent class CANNOT be modified by developers. When you need a variable, you ask the package coordinator to add it. Temporarily, you can always use the QContainer to save whatever you want


Root eventsRoot events

All files written and read by Diana are ROOT files, or more specifically, TTrees of Root events

QAEventR, QEventR, QiEventR are examples

Each “persistent” event depends on QEvent, but NOT the other way around

QEvent ev;

QEventR e = ev;

e->Fill(&ev);

We will probably have several persistent events in the future.


Software EnvironmentSoftware Environment

OSLinux only is supported. Darwin works, but is not officially supported. Other UNIX flavours should be easy, but they are not supported. Linux kernel 2.4 or newer (not critical as far as I know)

Compilerg++ 3.2 (4.1 DOES NOT work yet, still to investigate the reason why)

GSL: GNU Scientific Library version 1.8ROOT: latest versionPerl is needed for scripts, but these scripts are not normally needed (data base handling and such)PostgreSQL is the data base server. You normally need to install the client libraries only.

ROOTSYS should be definedPATH should contain $ROOTSYS/bin/export LD_LIBRARYPATH=$ROOTSYS/lib:$HOME/cuore/lib/

status of the cuore software marco pallavicini cuore co-software coordinator with m. pavan (milano)...

Documents