*E-mail: A.S.Zaytsev@inp.nsk.su

† Main Web Site: http://www.inp.nsk.su

‡ Main Web Site: http://www.nsu.ru

Figure 1: CMD-3 detector layout: 1 – vacuum chamber, 2 – drift chamber (DC), 3 – BGO endcap calorimeter (BGO),
4 – Z-chamber (ZC), 5 – superconducting solenoid, 6 – liquid Xe calorimeter (LXe), 7 – CsI barrel calorimeter (CsI),
8 – iron yoke, 9 – liquid He supply, 10 – vacuum pumpdown, 11 – VEPP-2000 superconducting magnetic lenses.

CMD-3 DETECTOR OFFLINE SOFTWARE DEVELOPMENT

F. Ignatov, S. Pirogov, A. Sibidanov, A. Zaytsev*,
Budker Institute of Nuclear Physics†, Novosibirsk, Russia
I. Fedko, A. Ognev, Novosibirsk State University‡, Novosibirsk, Russia

Abstract

This contribution contains the general design overview and a status of implementation of the CMD-3 detector offline software for the event reconstruction and simulation.

Software design standards of the project are object oriented programming techniques, C++ as a main language, modular approach, Geant4 as the only simulation tool, Geant4-based detector geometry description, visualization based on WIRED and HepRep, CLHEP and GSL libraries based primary generators and Linux as the main platform. All the tools produced are designed and optimized for the batch processing mode and GRID environment compatible.

Vepp-2000 cOLLIDER AND
CMD-3 DETECTOR

The CMD-3 is the general purpose cryogenic magnetic detector [1, 2] for the VEPP-2000 electron-positron collider [3, 4], which is being commissioned at the Budker Institute of Nuclear Physics (BINP, Novosibirsk, Russia). The detailed layout of the CMD-3 detector is shown on Fig. 1.

The main aspects of the physical program of the experiment are the study of known and the search for a new vector mesons, study of the and production cross sections in the vicinity of the threshold and search for exotic hadrons in the region of center-of-mass energy below 2 GeV. The VEPP-2000 collider also is going to perform the first test of round beam technique [5, 6].

The essential upgrade of the CMD-2 detector (designed for the VEPP-2M collider at BINP) production farm and distributed data storage management software is being performed in order to satisfy the new detector needs.

CMD-3 DETECTOR OFFLINE SOFTWARE DEVELOPMENT

Stages of the Offline Reconstruction

From the offline software design point of view the most important feature of the CMD-3 detector is that it has modular structure which allow one to use any active subsystem of the detector for the (partial) experimental (sub-)event reconstruction with no respect to all other subsystems. Thus the procedure of the complete reconstruction of the experimental event can be splitted into two parts:

individual (local) reconstruction within each active subsystems of the detector,

global reconstruction within the entire detector dealing with the output of all the subsystems and produces high level representation of an experimental event.

Since the number of active subsystems within the CMD-3 detector is large and all the subsystems are unique from the point of view of the representation of their local reconstruction procedures output the high flexibility of the global reconstruction implementation and the availability of an interactive detector geometry and experimental event visualization tools are of crucial importance.

All the data instances produced by the reconstruction are to be supported by the standard ROOT-based CMD-3 detector persistency manager.

Offline Software Development Framework

The dedicated software development framework (Cmd3Fwk) was implemented in order to be the basic integration solution for building offline reconstruction code, simulation tools and the 3rd level trigger for the CMD-3 detector. The CMD-3 Software Development and Data Processing Framework (officially named as CMD-3 SD/DP Fwk or simply Cmd3Fwk) design is based on the following assumptions about typical HEP data treatment procedure:

The data analysis procedure is well represented by a directed acyclic graph with the modules and data instances at the nodes, therefore the reverse call method of building self-organizing modules chain can be used.

The input data is divided into so called ”runs” consisting of so called ”events” with the similar structure withing the certain run, thus the cycle over the events and runs for the data set being analyzed can be organized by the framework tools themselves, not by some code provided by the user.

The data instances are produced by the modules and only the creator module of the certain data instance is intended to modify it, so all the intermediate stages of the data processing are preserved during the certain event reconstruction.

The key features of the framework are modularity, dynamic data processing chain generation according to the XML configuration of modules and the on-demand data request mechanisms. It also provides the command-line and the graphical user interfaces for building XML configurations and running the data processing jobs. All the iterative algorithms are intended to be hidden within the modules, though the iterative module chains can be managed by the framework.

Since the framework is modular and rather flexible the issues stated in the previous subsection are well addressed.

Local Reconstruction within the Subsystems

The local reconstruction procedure for each subsystem goes via the following steps:

Channel ID mapping from the physical (hardware) ID to the logical ID suitable for the analysis. The transformation is done by the tunable standard module which reads the mapping rules from the calibrations database (ClbrDB).

Channel amplitudes calibrations and building the object representations for subsystem specific hits (calibration data sets are extracted from the ClbrDB).

Building a compound objects from the hits obtained: tracks and vertexes for the tracking subsystems (e.g.: DC and ZC) and clusters for the calorimeters (e.g.: CsI and BGO).

In principle, all the implementations of hits, tracks, vertexes and clusters are subsystem specific and even provided by the different groups of developers, though some features are shared among them such as transformations of the object global coordinates within the detector.

Since the liquid Xe (LXe) calorimeter is capable of measuring both energy deposit and spatial coordinates its reconstruction deals with all four types of objects.

The production version of all the subsystems local reconstruction modules for Cmd3Fwk are expected in 2006Q3 – 2006Q4.

Global Reconstruction

The global reconstruction is intended to compile the information produced by the local reconstruction procedures and group the locally reconstructed objects via exploiting various user (physicist) defined criteria. It is also up to build a higher level object representations such as global tracks, global clusters and global vertexes. The global reconstruction procedure also includes the global event identification producing a set of hypothesis on the nature of an experimental event with likelihood estimators attached.

The first version of the global reconstruction modules for Cmd3Fwk are expected in 2006Q4 – 2007Q1.

CMDEVENT PACKAGE

The CmdEvent package was designed and implemented with the aim to produce a single compact set of tools for dealing with all the representations of the CMD-3 detector experimental events. It includes:

The container for the event with an arbitrary set of the reconstructed object collections stored with the human-readable name associated. Each event is provided with the extensible header.

A sophisticated object linking mechanism and search interface based on the BOOST Graph Library (BGL).

Persistency management tools based on ROOT persistency manager and a set of the Cmd3Fwk data I/O modules (all the reconstructed data are saved to the ROOT files with TTree instances within).

The CmdEvent is capable of storing the detector RAW data as well as the data produced by the primary generators in the CLHEP::GenEvent format so the dedicated filter-converter from the internal Geant4 event representation to the CLHEP::GenEvent format was implemented.

The final stage of reconstruction can be performed by physicists via implementing a ROOT script or a dedicated Cmd3Fwk module for the event selection and custom data processing.

CONCLUSION

The dedicated software development framework was implemented in order to be the basic software integration solution for building offline reconstruction code, simulation tools and the 3rd level trigger for the CMD-3 detector. The CmdEvent package was designed and implemented with the aim to produce a single compact set of tools for dealing with all the representation of the experimental events.

The production version of all the subsystems local reconstruction modules for Cmd3Fwk are expected in 2006Q3 – 2006Q4. The first version of global reconstruction modules for Cmd3Fwk are expected in 2006Q4 – 2007Q1.

Acknowledgements

The authors are grateful to all the members of CMD-3 online and offline software development groups for fruitful discussions during the design stage and also for useful testing and debugging feedback.

References

[1]	D.N. Grigoriev, CMD-2 Detector Upgrade.
hep-ex/0106009

[2]	CMD-3 Collaboration Web Site: http://cmd.inp.nsk.su

[3]	I.A. Koop, VEPP-2000 Project. physics/0106013

[4]	VEPP-2000 Collaboration Web Site:
http://vepp2k.inp.nsk.su

[5]	L.M. Barkov et al., Proc. of the IEEE Particle Accelerator Conference, San Francisco (1991), p.183

[6]	V.V. Danilov et al., Proc. of the Asian Particle Accelerator Conference, Tsukuba (1998), p.257

2006-01-27T13:40:22