The University of Liverpool

Conditions for the LHCb VELO


Contents

top home

Implemented VELO Conditions

As of January 26 2006 the following conditions are represented in the XmlConditions package and interfaced through the detector element classes. Note that the alignment conditions are covered elsewhere. Also note that at the time of this writing the next version of LHCb software is in the process of integration and conditions as well as the interface code are only available from the head of the CVS repository.

Associated with DeVelo

Associated with DeVeloSensor

top home

XML Representation of the VELO Conditions

Since there is not yet a data base backend for the conditions, the representation in flat XML files is the only one currently available. The files reside in the Det/XmlConditions package. Three new catalogs were introduced for the representation of the VELO conditions. One, Sensors, is simply a sub-catalog of the Velo catalog. The other two are new top-level catalogs, namely ChannelInfo and HardwareProperties. These two catalogs might also be populated with conditions for other detector components. The file path and XML catalog path for the conditions is hown below.

Condition

File Path

XML Catalog

TELL1 to sensor mapping Velo/velo_readout.xml ReadoutConf/Velo
Overall sensor readout Velo/sensor_readout.xml ReadoutConf/Velo/Sensors
Strip information Velo/sensor_channelinfo.xml ChannelInfo/Velo/Sensors
Strip capacitances Velo/sensor_hardware.xml HardwareProperties/Velo/Sensors

top home

Detector Element Interface to VELO Conditions

The simplest interface to the conditions would be to let the detector element classes hand out constant pointers to the Condition objects. This has some disadvanteges, however. Firstly it is much nicer if client code can simply ask the detector element via some meaningfully named method. Secondly there is a slight performance hit when the condition parameters are always retrieved via their names instead of reading them from a cache in the detector element. In case of the TELL1 to sensor map condition there is another reason: the XML backend does not yet allow for the representation of maps. So the map is represented as two vectors in the XML which then have to be converted to a map whenever the condition is updated in DeVelo. What follows is a brief description of the interfaces to the various conditions.

TELL1 to sensor mapping

Associated detector element:

DeVelo

Interface:

const DeVeloSensor* DeVelo::sensorByTell1Id(unsigned int tell1Id) const;

Comment:

The only reason I used an unsigned int as a TELL1 identifier is that I am not aware of something like a TELL1 Id class for the Velo. If such a thing exists, I will happily change the interface.



Overall sensor readout

Associated detector element:

DeVeloSensor

Interface:

bool DeVeloSensor::isReadOut() const;



Strip information

Associated detector element:

DeVeloSensor

Interface:

StripInfo DeVeloSensor::stripInfo(unsigned int strip) const;

bool StripInfo::stripIsReadOut() const;

bool StripInfo::stripIsBonded() const;

bool StripInfo::stripIsBondedWithNext() const;

bool StripInfo::stripIsBondedWithPrevious() const;

Comment:

StripInfo is a nested class in DeVeloSensor



Strip capacitance

Associated detector element:

DeVeloSensor

Interface:

double DeVeloSensor::stripCapacitance(unsigned int strip) const;

top home