Access to Conditions Information

David Quarrie

13 September, 1996

Overview

• Background information
• Underlying technology
• AbsEnv Interface
• DDL Files
• Code guidelines
• Lists and Collections
• Access Examples [based loosely on Emc]

Background Information

The following talk was presented at the Common Reconstruction Meeting on 25th June 1996.

http://www.slac.stanford.edu/~quarrie/Talk-25Jun96.htm


The draft RD45 code guidelines are at:

http://wwwcn1.cern.ch/~dirkd/objy-rules.html


Underlying Technology

The conditions database is being implemented based on the Objectivity object-oriented database management system (OODBMS). This provides a direct C++ interface to persistent objects within the database, and query mechanisms to access information. The (simplified) model is that conditions information is valid for a range of times (or time interval) and each event is tagged by it's creation time. When accessing information for an event, the database uses the event time to locate the appropriate conditions information (corresponding to the time interval) for that event.

The granularity of information is determined by the detector subsystems. Characteristics that should be taken into account when determining this granularity are:

• The frequency with which information is changing. Thus is it bad design to create one class that contains condition information of two types (e.g. pedestals and gains) if they are stable over significantly different time intervals (e.g. months and hours). Use separate classes in this case.
  
• Calibration and alignment information. Keep these separate, not only because they are likely to change with very different time scales, but also because they are logically distinct.
  
• Natural access mechanisms from within Event. Do you typically need to access most or very little of the information for each event? If most of it, a rather flat approach would be fine, but if only a small part of it, then a more hierarchical approach might be better.
  

David Quarrie (DRQuarrie@LBL.Gov) & Jim Ohnemus (James_Ohnemus@LBL.Gov) will provide help and guidance on designing your classes.

AbsEnv Interface

The AbsEnv class is the primary access to the conditions database. A global AbsEnv object (gblEnv) is defined within the Framework. AbsEnv will be extended to have an interface very similar to AbsEvent interface.

class AbsEnv {
public:
....
HepRef(MyGeomInfo) getMyGeomInfo( );
HepRef(HisGainInfo) getHisGainInfo( );
};


HepRef(MyGeomInfo) myGeomInfo = gblEnv->getMyGeomInfo( );


Accessing this information should be explicit for every event. If it has not changed since the previous event, the AbsEnv object provides internal caching to avoid redundant database access. THIS INFORMATION SHOULD NOT BE CACHED BY YOU BETWEEN EVENTS. If you attempt this there is no guarantee thatyou will have the correct information for each event.

DDL Files

The .hh file for persistent capable classes no longer becomes the basic specification of the class. Instead a Data Definition Language (DDL) file takes that role. This has a syntax that is an extension of C++. A code generator parses the .ddl file and creates the appropriate .hh file and some auxillary files.

Until Objectivity is installed as a part of the BaBar software release, the .hh file can be derived from the .ddl file using the normal cpp preprocessor (if these guidelines are adhered to).

Code Guidelines

Use of OODBMS technology has some implications for application code. Must also support transition period between now and global use of OODBMS. Use RD45 coding guidelines as baseline. These are themselves based on Object Database Management Group (ODMG) guidelines.

• Persistent capable classes must inherit from d_Presistent_Object. We will probably hide this class within BaBar by a BaBar-specific persistent capable class. Current configuration database prototype uses BdbObject. [This is not appropriate for event store.]
  
  class MyClass : public BdbObject {
....
};

• Base types are
  d_Short 16 bit signed
d_Ushort 16 bit unsigned
d_Long 32 bit signed
d_ULong 32 bit unsigned
d_Char 8 bit signed
d_Octet 8 bit unsigned
d_Boolean enum {false, true}


  The plan is to migrate slowly to these.
  

• C++ Pointers and References are not allowed within persistent capable classes. They should be replaced by a "smart reference" HepRef(T).
  Hit* aHit;


  should be replaced by
  HepRef(Hit) aHit;


  These smart pointers have the semantics of conventional pointers as far as the arrow operator is concerned:
  aHit->myFunction( );


  Smart references should also be used to access persistent objects from transient objects. Smart references should be passed as function arguments (and values) explicitly, not as pointers).
  

• Use HepNew and HepDelete instead of the C++ new and delete operators.
  HepRef(Hit) aHit = HepNew(Hit);
....
HepDelete(aHit);

• A persistent capable object should not contain another persistent capable object.Use a HepRef instead with explicit ownership.
  class Track : public d_Persistent_Object {
....
};

class Vertex : public d_Persistent_Object {
....
Track first; // Bad
Track second; //
};

class Vertex : public d_Persistent_Object {
....
HepRef(Track) first; // Good
HepRef(Track) second;
};

Vertex::~Vertex( ) {
HepDelete(first);
HepDelete(seond);
}


  Lists & Collections

  HepAList will _NOT_ be supported. However, alternatives are provided as well as most of the Rogue Wave Tools.h++ collection classes.
  

  HepVector(T) Variable Length Array of type T

  HepRefVector(T) Variable Length Array of type HepRef(T)
  

  [I'm still trying to understand what the difference is between

  HepRefVector(T) and HepVector(HepRef(T))]
  

  RWPtrDList<T> Doubly linked list

  RWPtrHashDictionary<K, V> Hash dictionary

  RWPtrHashSet<T> Hash Set

  RWPtrHashTable<T> Hash Table

  RWCString String

  RWPtrOrderedVector<T> Vector, ordered

  RWPtrVector<T> Vector, plain

  RWPtrSortedVector<T> Vector, sorted
  

  [and Iterator classes]

  Access Examples [based loosely on Emc]
  

  • How to determine which Xtal a Digi lies in and access geometry and gain information.
    

  class EmcDigi : public AbsEvtObj {

  ....

  public:

  int theta( ) const; // theta index

  int phi( ) const; // phi index

  HepRef(EmcXtal) xtal( );

  ....

  private:

  int _theta;

  int _phi;

  };
  

  HepRef(EmcXtal)

  EmcDigi::xtal( ) {

  .....[????]

  }
  
  

  class EmcFullGeom : public AbsEnvObj {

  ....

  public:

  xtalGeom( int theta, int phi );

  };
  
  

  • How to determine which Digis correspond to a Xtal.
    
    
    
  • How to determine geometry for a Xtal.
    
    

  class EmcXtal {

  public:

  ....

  HepRef(EmcXtalGeom) geom( );

  int theta( );

  int phi( );

  };
  

  HepRef(EmcXtalGeom)

  EmcXtal::geom( ) {

  HepRef(EmcFullGeom) fullGeom = gblEnv->getEmcFullGeom( );

  return fullGeom->xtalGeom( theta(), phi() );

  }

DB Home | BaBar Home | Computing | Reconstruction | Simulation | Search

DRQuarrie@LBL.Gov