org.lcsim Conditions Database

Overview

The conditions database is designed to allow a running analysis or reconstruction module to access information about the run "conditions". In our current environment, conditions include the entire detector description.

The org.lcsim conditions framework is designed to be very flexible, both in use and in implementation. Our current implementation looks up conditions based on the detector name.

Conditions Formats

The recommended format for storing conditions information is in a zip file. The conditions database includes facilities for downloading zip files from the web and caching them, so no web connection is required when running analysis or reconstruction jobs, as long as the required conditions have been previously accessed.

The conditions themselves are stored as an arbitrary collection of files, either stored in a filesystem or in a zip file. The most common files used are property files (name, value pairs) or XML files (e.g. for geometry). However, there are no constraints as to which file formats can be used for conditions information.

Properties Files

Properties files contain line-delimited key, value pairs with the 'equals' as a '=', ':' or ' ' (space). The file extension should be '.properties'.

For instance, any of the following will assign the value 'strange' to the key 'charm'.

charm = strange 
charm: strange
charm  :strange

Multiple strings can also be associated with a single key, as follows.

charm    beauty, truth, strange

The value of the key 'charm' will be 'beauty, truth, strange'. These strings can be read as individual values using the method String.split() .

Accessing Conditions

For the following sections, we will use as an example the SDJan03 detector with corresponding tag of sdjan03 for conditions lookup.

Detector Alias Files

An alias file is a property file named alias.properties that lists the locations of conditions information for a specific detector tag.

It has the following format.

[detector_name]: [conditions]

The value of conditions can be one of the following.

1. Zip file on a website.

   sdjan03: http://www.example.com/path/to/sdjan03.zip
   

2. Local directory.

   sdjan03: file:/path/to/my/sdjan03/
   

3. Local zip file.

   sdjan03: file:/path/to/my/sdjan03.zip
   

4. Alias to another detector name.

   sdjan03_local: sdjan03
   

Multiple detector tags can be used used in the same alias.properties file, but each detector tag should eventually resolve to a single location.

Recursive Name Translation

If the name is not a URL, then it is assumed to be an alias, which is recursively translated.

Suppose the following is listed in the alias.properties.

a: b
b: c
c: http://www.example.com/d.zip

The final value of a will be

http://www.example.com/d.zip

If the alias translation results in a URL, then the previous algorithm is used to look up the conditions.

The value after translation need not be a URL or file. It can be a detector tag.

In the following case, the value of a will be d.

a: b
b: c
c: d

The d name will still need to be resolved using the conditions lookup algorithm.

Alias File Locations

The alias file is stored at one or more of the following locations.

1. The LCSim work directory in the user home directory.

   ~/.lcsim/

2. Within the lcsim.jar file at the following path.

   org/lcsim/detector/

3. At a URL on the LCSim website.

   http://www.lcsim.org/detectors/

Your custom aliases belong at

~/.lcsim/alias.properties

as this is likely the only place to which you'll have write access, and your own aliases should be kept separate from the common ones.

Conditions Lookup

Conditions information is retrieved as follows.

1. If the value is a URL with a protocol of file:, the local file (zip format) or directory path specified is assumed to contain the conditions.
2. If the name is a zip file at a remote URL, an attempt is made to download the file from that location, unless the zip file is already in the local cache (~/.lcsim/cache). In this case, the local copy is used instead.

In the case of an alias, once the final detector name is determined, the algorithm searches for a directory or zip file with the same name in the following "canonical" locations:

1. ~/.lcsim/detectors
2. Within the lcsim.jar file at

   /org/lcsim/detector/

3. At

   http://www.lcsim.org/detectors/

The following canonical locations would be scanned for sdjan03 conditions.

Within the home directory.

~/.lcsim/detectors/sdjan03.zip
~/.lcsim/detectors/sdjan03/

In the jar file.

/org/lcsim/detector/sdjan03.zip
/org/lcsim/detector/sdjan03/

On the LCSim website.

http://www.lcsim.org/detectors/sdjan03.zip

If the lookup process does not result in a valid set of conditions, the program will terminate with an error. (In Java, this is a ConditionsNotFoundException).

Java Example

Here is an example of accessing conditions of the sdjan03 detector from Java code.

First, retrieve the default instance of the ConditionsManager.

ConditionsManager mgr = ConditionsManager.defaultInstance();

Then look up the conditions. The base location is http://www.lcsim.org/detectors/sdjan03.zip.

mgr.setDetector("sdjan03", 0);

Conditions are stored in sets, usually organized by single files or directories.

For example, sampling fractions can be found in the SamplingFractions.properties file, which is referred to as SamplingFractions when using the ConditionsManager.

ConditionsSet cs = mgr.getConditions("SamplingFractions");

Now, the sampling fractions are available by their keys.

This code simply iterates over the keys and prints their keys and values.

for ( Object o : cs.keySet() )
{
    System.out.println(o.toString() + "=" + cs.getString(o.toString()) );
}

Most likely, the typed values from the ConditionsSet need to be retrieved in order to do anything useful.

Here is an example showing how to convert conditions in a ConditionSet to their typed values, one-by-one.

for ( Object o : cs.keySet() )
{
    String k = (String) o;

    Class typ = cs.getType(k);

    if ( typ == double.class )
    {
        double dblVal = cs.getDouble(k);
    }
    else if ( typ == int.class )
    {
        int intVal = cs.getInt(k);
    }
    else if ( typ == java.lang.String.class )
    {
        String strVal = cs.getString(k);
    } 
}

Presumably, an algorithm will do something with the value once it is retrieved.