THIS PAGE IS OBSOLETE.

-- JuanPalacios - 17 Nov 2005

XmlConditions page

The XmlConditions package is designed to hold a persistent, local copy of conditions for use by the detector data service in the absence of a real working database. It allows to check most of the features of the alignment framework and the update manager system. Since the interface to CondDB is the same regardless of whether the conditions are coming from XmlConditions or a real database, it should help sub-detector software experts change their software to conform to the interface. In due course, it will be replaced by the database, but should serve as a tool to prepare the software before the real database starts operation.

XmlConditions also allows users to edit and test conditions without having to affect the whole of XmlDDDB, and so takes some of the development-related maintenance pressure off XmlDDDB. It is in XmlConditions that the detector-specific conditions catalogues should be placed. At the moment it contains largely empty catalogues for alignment, readout configuration, calibration, trigger settings and environmental conditions for different set sof subdetectors. The last iteration of the structure, in the head revision Det/XmlConditions, looks like this:

/dd/Conditions/
        |______Alignment/
        |          |_______LHCb  (single condition)
        |          |_______Velo  (flat catalogue)
        |          |_______TT    (empty)
        |          |_______Rich1 (empty)
        |          |_______IT    (empty)
        |          |_______OT    (empty)
        |          |_______Rich2 (empty)
        |          |_______Prs   (empty)
        |          |_______Ecal  (empty)
        |          |_______Hcal  (empty)
        |          |_______Muon  (empty)
        |
        |______ReadoutConf/
        |          |_______Velo (flat catalogue with examples)
        |          |_______Prs (single cond.)
        |          |_______Ecal (single cond.)
        |          |_______Hcal (single cond.)
        |          |_______Muon (readout conditions)
        |                    |___Grid (flat catalogue)
        |                    |___Cabling
        |                           |_____M1 (flat catalogue)
        |                           |_____M2 ( "      "     )
        |                           |_____M3 ( "      "     )
        |                           |_____M4 ( "      "     )
        |                           |_____M5 ( "      "     )
        |
        |______Environment/
        |          |_______LHCb  (flat catalogue)
        |          |_______Rich1 (flat catalogue)
        |          |_______Rich2 (flat catalogue)
        |
        |______Calibration/
        |           |_______Prs  (empty) 
        |           |_______Ecal (empty)
        |           |_______Hcal (empty)
        |           |_______Muon (empty)
        |
        |______Trigger/ (empty)

The XmlConditions file hierarchy

The XmlConditions files are organised as follow:

XmlConditions/DDDB/Local/[subdetector_name]/[subcatalog_name.xml]

This corresponds to the following transient store path:

/dd/Conditions/[subcatalog_name]/[subdetector_name]

The list of subcatalogs defined so far is:

• Alignment: position of the subdetector elements relative to their nominal position (Velo boxes, RICH mirrors, etc.).
• ReadoutConf: probs measures of the configuration data (high voltage, etc.)
• Environment: probs measure of environmental conditions (temperature, pressure, humidity, etc.)
• Calibration: all calibration information which is not alignment (examples ?)
• Trigger: conditions specific to the Trigger (examples ?)

The main catalog file is XmlConditions/DDDB/conditions.xml. It contains the definition of the tree shown in the previous section. The Document Type Definition (DTD) files are located in XmlConditions/DDDB/DTD. The file used to describe the structure of the catalog files is XmlConditions/DDDB/DTD/structure.xml.

These files should never be modified by users

Creating an XML condition

Users can add their own conditions in their own copy of the XmlConditions package. The reference to this condition will be located in:

XmlConditions/DDDB/Local/[subdetector_name]/[subcatalog_name.xml]

The definition of the condition itself can be stored for instance in:

XmlConditions/DDDB/Local/[subdetector_name]/[condition_name.xml]

Example

Let suppose that we want to create the following entry in the transient store:

/dd/Conditions/ReadoutConf/Velo/testCondition

In order to do it, we first open XmlConditions/DDDB/Local/Velo/readout.xml (should we change the name of the file to readoutconf.xml ?). Then, in the catalog definition

<catalog name = "Velo">

we add the line

<conditionref href = "example.xml#testCondition">

This being done, we need to create the XmlCondition/DDDB/Local/Velo/example.xml file.

Creating the condition file manually

The simplest way to create the definition of an xml condition is to do it manually by editing an xml file. Here is a file containing the definition of the testCondition condition used in the above example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE DDDB SYSTEM "../../DTD/structure.dtd">
<DDDB>
    <condition classID = "5" name = "testCondition">
        <param name="testExample" type="other" comment="a string param">
        blablabla
        </param>
    </condition>
</DDDB>

You can also put multiple definitions of conditions in a single file. The reference to them from the subcatalog file would then be something like:

<conditionref href = "example.xml#cond1">
<conditionref href = "example.xml#cond2">
<conditionref href = "example.xml#cond3">

Creating the condition file automatically

Sometimes, the parameters of a condition might contain too many data to be written by hand (e.g. a vector of hundreds of sensorIDs). It is then better to create the xml file directly from a Gaudi Algorithm or (better) a Gaudi Tool. Here is an example of code to do so:

Condition     mycond;
std::string   stringParams = "blablabla";
std::ofstream xmlFile("XmlConditions/DDDB/Local/Velo/example.xml");

mycond.addParam("textExample", stringParam, "a string param");
xmlFile << mycond.toXml("testCondition");
xmlFile.close();

The function Condition::toXml() is formatting the contents of the Condition into the following xml string:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE DDDB SYSTEM "structure.dtd"><DDDB><condition classID="5" name=testCondition"><param name="testExample" type="other" comment="a string param">blablabla</param></condition></DDDB>

This needs some post-formatting to be human readable. More important: the path to the structure.dtd file must be correctly set as the function doesn't know where to find it. Appart from that, the string can be safely written to a file and included "as is" in the XmlConditions file hierarchy.