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 the "conditions" include the entire detector description.

The recommended format for storing conditions file collections 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, as long as the required conditions have been previously accessed.

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 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 are simply sets of 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.

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_custom: sdjan03
   

Multiple detector tags can be used used in the same alias.properties file, but each detector tag should be listed only once.

Alias Locations

The alias file is stored in 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 shared ones.

Alias Translation

Once this translation is complete, the resulting value is checked as follows.

1. If the name 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.

Alias Lookup

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

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

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

a: b
b: c
c: d

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

Otherwise, the algorithm searches for a directory or zip file with the final alias 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/

If the translation does not result in a valid alias or URL, the program will fail to find any conditions and 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.