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 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.