Configuration Management

Aspen stores configuration information both in memory and in an XML configuration file. When Aspen is running, it reads config item values from the XML and the user can modify them in-memory, with an option to save config values back to the XML when closing Aspen.

Code dealing with config sets is in the Aspen repo under Aspen/AspenQC/Configuration.

See Configuration and Configuration parameters in the user manual for an introduction to configuration from the user’s perspective.

XML configuration file

The first time Aspen is opened, it saves the user’s XML file to (on OSX) ~/.config/Aspen/aspen.xml. The purpose of this is so the config set will be accessible on the user’s system from multiple installed versions of Aspen. It is possible for users to modify their config sets by hand by editing the XML, but generally changes to the config set are made through Aspen.

The XML config is made of config items which are grouped into config sets. Each set contains (or should contain) the same items, though the values of the items can change between different sets.

In Aspen/AspenQC/Configuration, XML is accessed through the RegistryXML class, which is a subclass of the more general Registry.

Config sets

Config sets are specified by name within the XML file:

<aspenConfig>
<active>dropsonde</active>
<set name="sample">
.
.
.
</set>
<set name="dropsonde">
.
.
.
</set>
</aspenConfig>

In addition, one config set is specified by name as the active set, whose values the user is currently using for QC. The purpose of different config sets is to be able to process data differently for different instruments or applications. For instance, QC should be different when processing a radiosonde (instrument on a balloon, traveling upward) than when processing a dropsonde (instrument launched from a plane, traveling downward). Aspen currently includes radiosonde config sets upsonde-1s and upsonde-10s, among others, and many dropsonde config sets. Another reason for changing processing parameters is the purpose of the data files being created. On Hurricane Hunter flights when data is being submitted to weather forecasting models in real time, QC limits should be stricter than when re-processing sondes at a later date for research. research-dropsonde is an example of a research config set and editsonde is the operationally used config set. editsonde is set as the default active config set since the Hurricane Hunters are the highest-priority Aspen users.

Users also have the option of creating new config sets based on the values from an existing set.

Config items

Each config item is specified as an option element in the XML:

<option immediate="true" name="CallSign" type="string">
      <current>CALL</current>
      <default>CALL</default>
    </option>

A config item has these attributes:

• Name: String name of the config item. Aspen uses CamelCase beginning with an uppercase letter for config option names.
• Type: Type of the config option (bool, double, string)
• (optional) Immediate: when true, save changes to the value of this config item immediately, rather than waiting until the user quits Aspen
• Current: current, possibly user-modified, value of the config item
• Default: base value of the config item, not modified by the user

Updating the config set

As developers make changes to Aspen, we sometimes have to add or modify config items. To keep track of changes, Aspen has a config set version number in a comment in aspen.xml:

<!-- The version of Aspen Configuration.". 
     @version: 2.06
-->

When changes are made to the config set, the number is incremented. When a user opens Aspen, it checks whether the user’s config set version number is the same as the version number of the aspen.xml that comes packaged with the Aspen release. If not, Aspen renames the old aspen.xml and copies in the new one. This is done in Aspen/AspenUI/QtUtil/FileManager::upgradeVersion().

For more information about config set changes, see Configuration infrastructure on the Aspen github wiki.

In-memory config set

While Aspen is running, config items are not re-read from the XML whenever their value is used, but instead stored in an in-memory ConfigSet object. In addition, there are some configuration parameters that apply to a single sounding (e.g. setting whether the sonde hit surface) that are not saved back to the XML file as their value should not be propagated between individual sondes.

Aspen and BatchAspen config sets

The general ConfigSet class, which controls accessing data from the in-memory configuration items, has separate subclasses that specify individual config items in the config set. AspenConfigSet creates config parameters for all applications, while BatchAspenConfigSet adds config parameters that only apply to BatchAspen.

Config items

The ConfigItem class corresponds to the option element in the Aspen XML. A ConfigItem consists of:

• string ID
• double or string value (currently, bool values are converted to double…)
• bool specifying whether this config item should be saved to XML
• bool specifying whether this item should be saved immediately (rather than waiting until Aspen is closed)
• bool specifying whether this item should appear in metadata of output files

Some config items are not saved in the XML, but are created in the in-memory config set.