GaudiObjDesc

GaudiObjDesc provides tools work with class schema defined in XML. From this they can produce the C++ class files and the ROOT/Reflex dictionary code, taking care of the requirements Gaudi imposes on data.

This topic is to document GaudiObjDesc from the point of view of using it in Daya Bay.

Documentation on GaudiObjDesc

• LHCb's docs on this package: start here.

• Pitch to Daya Bay offline group to use GaudiOjbDesc. Part of the Aug 07 collaboration meeting is here in PS or PDF formats.

• Understanding GaudiObjDesc Schema.

• The LHCb core software Savannah project.

Getting the source

This package is available from LHCb's CVS server via

:pserver:anonymous@isscvs.cern.ch:/local/reps/lhcb

There is a older version in Gaudi's CVS rep, but it is not developed in favor of LHCb's. No other LHCb code is apparently needed. If we adopt this package it will be mirrored in our SVN repository, but until then, to test it you can either add it along side the other Gaudi packages from our SVN or put it in a new location and add that location to your CMTPATH.

You can browse the source from LHCb's cvsweb.

Stefan Roiser suggests looking to Event/PhysEvent as a simple example.

G.O.D. aware Xml Editor

There is an XmlEditor package available.

Also standard XML aware editors such as oXygen and xemacs can be used.

Example of using GaudiObjDesc

A play DataModel package with a single top level object called "Hit" is assumed.

Package Layout

Need at a minimum three directories in the package

bviren@lycastus:DataModel> mkdir cmt src xml

cmt/requirements

The cmt/requirements file is as follows, broken up with inlined comments:

package DataModel
version v0
branches cmt xml
use GaudiKernel     v*
private
use GaudiObjDesc v* -no_auto_imports
end_private

Next, produce header files from the XML description. Note that the headers will be deposited into a more-or-less hard coded Event/ sub directory, so the second line tells the build to look there. G.O.D. won't produce any implementation file. If any <code></code> tags are given in the XML it will be inlined.

By default, code is put into the LHCb namespace. As of v10r2 there is support added to set this default on the command line. This can be done like:

# Optional, provide default namespace if not set in XML
macro_append GODflags " -n DayaBay "

Tell where to find the input XML file and where to look for the resulting headers.

apply_pattern god_headers files=../xml/*.xml
apply_pattern install_more_includes more=Event

Generate dictionaries library.

macro DataModelDict_dependencies DataModel
apply_pattern god_dictionary files=../xml/*.xml

Finally, a library holding any non-dictionary code, including any methods declared in XML but not given any <code></code>.

library DataModel ../src/*.cpp
apply_pattern linker_library library=DataModel

Finally2, you just need this so the build of the dictionary library can find the regular library.

private
macro DataModelDict_shlibflags "$(use_linkopts) $(libraryshr_linkopts)"

XML data description file

This defines the objects. It can be in a single file or many. This example is a single top level "Hit" object. No references nor containers used.

This goes in some file in the xml/ sub directory and should have a .xml extension.

First boiler plate:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE gdd SYSTEM "gdd.dtd">

The gdd.dtd needs to be findable at build time. The docs mention is will be copied from the G.O.D. package, but it may need to be copyed to xml/ by hand.

Now the meat:

<gdd>
  <package name='DataModel' namespace='DayaBay'>

Default namespace is "LHCb". It seems that putting it in the package isn't inherited.

    <class name='Hit' id='42' author='bv' desc='A deposition of energy' namespace='DayaBay'>

The "id" must be unique w/in the experiment.

      <base name='DataObject'/>

This makes it a single object. There is also KeyedObject for collections.

      <attribute type='double' name='energy' desc='Deposited energy'/>
      <attribute type='double' name='time' desc='Time of hit'/>

The attributes. Setters/getters will be generated or can be optionally turned off.

      <method const='TRUE' desc='Return energy as PE' name='Pe' type='int'>
        return (int)(m_energy/100.0);
      </method>
      <method const='TRUE' desc='Return particle name' name='PartName' type='std::string'/>

Last, the methods. Second one has no implementation which is supplied by hand, below.

    </class>
  </package>
</gdd>

Caveats

You can not use reserved XML characters in data areas, instead you must use codes that are escaped by placing them between a "&" and a ";". In particular:

&

amp

<

lt

>

gt

Manual implementation

A manual implementation may not be needed, but here is and example. This file goes in to src/Hit.cpp:

#include "Event/Hit.h"
#include <string>

using namespace DayaBay;

std::string Hit::PartName() const
{
    return "Fred";
}

PartName is declared in the XML.

Products

Building this package results in the generation of:

Class definition headers:

Event/Hit.h

Dictionary library

libDataModelDict.so

Implementation library

libDataModel.so

Timestamp file, remove this to force the header to be rebuilt:

Event/DataModel.obj2doth

See your data in Python

This example shows how to see your data from Python. It assumes the example XML above.

#!/usr/bin/env python
import gaudimodule as gm
g = gm.AppMgr()
g.loaddict('DataModelDict')
g.Dlls += ['DataModel']
g.initialize()
gm.getClass( 'DayaBay::Hit') 
db =  gm.gbl.DayaBay  # python representation of the C++ namespace
print str(db.Hit)
h = db.Hit()
h.setEnergy(6.9)
print "Energy is",h.energy()

Close Questions

The <location> tag

q

There seems to be tags in current gdd.dat, like "location" that are

not in the docs. There is location explained. Any other new ones since the initial GOD docs were written?

a

This is used by LHCb and can be safely ignored