RecExample

The aim of RecExample is to provide examples and instructions for running full Reconstruction in Athena. So far only one example is provided, RecExCommon, without any user analysis, which run all the reconstruction algorithms currently available and output a combined ntuple. This package is run very frequently to test the code and is the basis of reconstruction production. (Basic familiarity with Athena concepts acquired by reading the Athena user and developers guide available  here is implied below, but it is also possible to run somehow blindly, also in batch). The user HowTo indicated at the top of  Software Developer page also indicates a lot of useful tricks.
Instructions have been checked to work (i) on CERN atlas linux machines (ii) with the recommended zshell shell (although most of the time c shell scripts have been provided). These instructions are kept uptodate (towards simplicity!) so check this page regularly.

 

AthAsk is a new Graphics User Interface on top of CMT now allows to do the things described below. See in particular the web page  corresponding to the reconstruction tutorial.

 

Getting started

These two commands should be done only once (almost) for ever, until the next change of CMT version. If you see a message on sw-developers mailing list: "please use cmt version v1rnnqwerty", you should retype these two commands, with v1rnnqwerty.
 

Run Athena reconstruction

 The secret instruction

to be run in an empty directory, without any prior setup instruction:

 

What it does

Customizing

All files have lots of comments and can be customized easily. A few tips are given below

Running on one's own data

To run on a different data file, one simply has to change ZEBRA.P to point to it: ln -fs myfile ZEBRA.P. One should be careful though that RecExCommon cannot run on all the data generated in the lifetime of atlas. One can expect good results with Physics TDR data and DC1 data. Support to run on Physics TDR data has been discontinued after release 6.0.4. Running on several files in one go is possible and is explained in the batch script below.

Running only selected modules

Modules to be run are included by the line (e.g.) #include "$TAURECROOT/share/tauRec_jobOptions.txt" . (Starting with release 6.6.0 this is done through #include "tauRec/tauRec_jobOptions.txt" , but the migration is not completed yet. This includes the jobOptions fragment which (i) load dynamically the module code (ii) add it to the list of Algorithm to be run (iii) sets the algorithm parameters.
It is usually immediately followed by the line CBNT_Athena.Members  += { "CBNT_tau" }; which adds the corresponding ntuple block to the combined ntuple. To disable a module both lines should be commented out. The combined ntuple block can be removed while still running the module by commenting out the CBNT_Athena... line.
Commenting the #include "...tauRec..." line while leaving the CBNT_Athena... will cause an error, as the library for CBNT_tauRec will not be loaded in.

It is also possible to disable an algorithm while still loading its library with the line XXX.Enable = false ;

Some modules depend on others. For example commenting #include "LArCellRec/LArCell_jobOptions.txt" will cause LArCluster to fail and the job will stop.

Also the order in which the modules are listed is the order in which they are run, which cannot be random.

Writing out HBOOK ntuple

Commenting three lines in RecExCommon_jobOptions.txt and uncommenting three others, a root ntuple file ntuple.root will be produced in place of the hbook ntuple. (example of use: TFile f("ntuple.root");  f.cd("FILE1;1/CBNT;1"); t3333->Draw("1./PTInvVert");).

(for example in paw: his/file 20 ntuple.hbook ; nt/plo //lun20/cbnt/3333.1./ptinvvert to plot the pt of all reconstructed tracks. exec ../share/dump.kumac runs a very simple kumac plotting a few quantities  ).

WARNING : if you want to analyse the ntuple with a fortran file, you might find that paw does not want to create the correct include file (message HUWFUN: Not space to store COMMON definition ). To avoid this, a private version of paw is provided by Pavel Nevski on a suggestion by Guillaume Unal: /afs/cern.ch/user/n/nevski/scratch0/QA/paw.exe.
 

Using my own version of a given package

If you want to use your own, possibly modified, version of a given package:

 

Writing my own package: ZeeRec

An example package of a user analysis is available in the release (since 6.3.0): Reconstruction/RecExample/ZeeRec. This package, used in reconstruction tutorial, is a simple example on how to access the output of reconstruction and is a good starting point for user analysis.


                       

Running in batch

Scripts are provided in RecExCommon/doc to run Athena reconstruction in batch at CERN. It runs the standard RecExCommon package, taken either directly or from a release or from a user area. The code which is run is by default taken directly from the release but modified packages can be used if properly recompiled in a user area. New packages can also be used provided they have been compiled beforehand, and "use"d from a user RecExCommon.

 

The data to be processed are either DC1 files taken directly from castor, or any other data file if soft links are constructed by hand. It is possible to run on several files within the same job.

 

To use these scripts,

 

Writing/Reading Reconstruction output (only release 7.0.0 and above)

Since release 7.0.0 it is possible to write reconstruction output into POOL, the new C++ database in development. It allows to write out full fledge objects rather than just ntuple. It is so far experimental, only a few objects can be written in 7.0.0: EventInfo (run/event number), MissingEt (missing energy) and SimpleTrack (InnerDetector tracks). What developers need to do to make their own objects writeable is explained there.

 

To write reconstruction output:

To read reconstruction output:

 

When more reconstruction objects are available it will be possible to run one’s own analysis in Athena without rerunning reconstruction upstream.

Using valgrind (only release 6.3.0 and above)

valgrind is a tool to find memory leaks and other run time errors like branch on uninitialized variables. Using it is rather simple

 

To use these scripts,

1.      valgrind cannot run directly on files on castor, so either use ZEBRA_HEEMM_EXTRACT.P or copy yourself your file on disk

2.      RecExCommon in valgrind only runs in optimised mode

3.      given the monitoring valgrind is doing, it is very slow. So either run only your favourite algorithms, or run in batch (there is a switch in athenarec.sh to use valgrind). You can run in valgrind the complete RecExCommon_jobOptions.txt on two events (which is enough to spot most errors) in a 8nh job.

 

 

Feedback from users is essential. Please send comments, suggestions to me (rousseau@lal.in2p3.fr).

 Back to  reconstruction main page

 


Last modified, 12th September 2003