Summary of the Gaudi Review Presentation

Toby Burnett

04 Aug 2004 15:39 -0700

Introduction

Purposes of the review:

• trigger a comprehensive review of how we are using Gaudi
• Improve, for us and the reviewers, the documentation
• Generate a list of TODOs for improving usage and documentation

Let the infrastructure of Gaudi itself guide the review. Like Gaudi, we use CMT to define and organize the code into "packages". Will assume that the reviewers are familiar with this concept. Important references: the Gaudi source, and the Gaudi developers manual. We have a special user guide for Glast developers. We have documentation guidelines using doxygen.

Gaudi is external code, but we do not treat it that way: the source is managed by cvs, and binaries are build by CMT,  like any of our packages. This allows minor changes in the requirements files to include header files in MSDEV projects, specify our interface packages. We use the build policy package GaudiPolicy to define most build behavior, but have a GlastPolicy to override some options.

Note: CMT and Gaudi are frozen at versions v1r10p20011126 and v9, respectively. The latter restricts us to egcs 2.91.66. We use Visual C++ 6.0 on Windows.

Gaudi Design Summary

• Factories: how this is implemented in separate DLL's
• Abstract interfaces: a client and a server are connected with C++'s Virtual Function Table and RTTI
• Versioning: use of the queryInterface virtual function for protection against changing interfaces. (We haven't been using this, bad.)
• Interfaces and Factories: Gaudi has Factories for the following abstract interfaces:
  • IAlgorithm
  • IService
  • IAlgTool
  • IConverter

Glast executables

• Unless local components are linked in, (often the case for test programs) there are only two actual executables built, from code in the packages GlastPolicy: and GuiSvc. On Linux the sizes are:
   

  Type	External Symbols	Size (MB)
  Gui	1980	2.3
  non-Gui	178	0.2

  By contrast, the sizes of the largest shareables are G4Generator: 12.3 MB; TkrRecon: 10.9 MB. (All numbers include debug symbols.)

  This is because we use the feature of Gaudi that the basic executable includes only kernel code, defined in GaudiKernel. When it starts, it finds GaudiSvc via the environment variable GaudiSvcShr. After GaudiSvc is started, the job options files are read, and all DLL's in the list ApplicationMgr.DLLs are loaded with the same mechanism. The env vars are set from the script "setup.sh", which is constructed by CMT from the information in the package requirements file, and the env var CMTPATH.

The package Gleam:

• Defines the explicit set of packages that need to be built for the application, including all the component shareables. Our build system uses this list to perform a recursive checkout from cvs of all non-external packages.
• Creates a (actually generic) executable from the code in GlastPolicy and GuiSvc
• defines the script setup.sh, defining environment variables for Gaudi execution
• Contain "job options" files for various execution options. (give current list), including generic test program
• Contain ROOT scripts for detailed tests.
• Control Application manager - DLL's, external services, algorithms.
• Use of the Sequence algorithm to guide execution: specification in a basic job options file, allowing overrides or additions for special jobs.
• Special GUI/event display mode, using the IRunnable interface to set ApplicationMgr.Runnable.
• Quick overview of all Gaudi packages

Event and RootIo packages

• defines  TDS  event structure. (follow LHCb model)
• Root-tree IO algorithms using parallel set of classes.

GlastSvc package: the GLAST-specific

• converters
• Services

Table of Gaudi components in current Glast software (leave out Converters)

Program flow