Presentation is loading. Please wait.

Presentation is loading. Please wait.

Status of the Cuore software Marco Pallavicini Cuore Co-Software coordinator with M. Pavan (Milano) Università di Genova & INFN.

Similar presentations


Presentation on theme: "Status of the Cuore software Marco Pallavicini Cuore Co-Software coordinator with M. Pavan (Milano) Università di Genova & INFN."— Presentation transcript:

1 Status of the Cuore software Marco Pallavicini Cuore Co-Software coordinator with M. Pavan (Milano) Università di Genova & INFN

2 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN Talk 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-requisites Compilers, UNIX flavours, SVN, GSL, ROOT, environment variables

3 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN Apollo & Diana These codes are very different, but they share a common software environment Apollo is the ONLINE code data taking & data monitoring event display run control electronics control slow control online prompt reco and possibly, preliminary analysis Diana is the OFFLINE RECONSTRUCTION code Single pulse analysis Calibration Stabilization Spectral analysis Physics tools for neutrino mass and similar Warning: as explained later, Diana is ALSO used online

4 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN Fluka and Geant4 MC G4 developed in Milano so far Still to be integrated in the common environment A lot of work still ahead See Fabio Bellini’s talk for details Fluka Important 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 !

5 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN Main 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!

6 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN Configuration 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_int_par = 4 my_private_float_par = 2.3 my_private_string_par = ciao ciao Endmod writer my_reader enable = 1 verbosity=1 my_private_int_par = 8 endmod endseq

7 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN 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() Init Called before starting event loop at each sequence Do Perform an action on the event Done Called 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

8 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN Readers 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

9 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN Procedure to write a new module 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….)

10 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN The 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 module Each 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

11 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN Root 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.

12 Berkeley, Tutorial on Cuore Software Environment 01-22-2007M. Pallavicini - Università di Genova & INFN Software Environment OS Linux 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) Compiler g++ 3.2 (4.1 DOES NOT work yet, still to investigate the reason why) GSL: GNU Scientific Library version 1.8 ROOT: latest version Perl 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 defined PATH should contain $ROOTSYS/bin/ export LD_LIBRARYPATH=$ROOTSYS/lib:$HOME/cuore/lib/


Download ppt "Status of the Cuore software Marco Pallavicini Cuore Co-Software coordinator with M. Pavan (Milano) Università di Genova & INFN."

Similar presentations


Ads by Google