A common framework

A common framework#

or more verbosely:

A common framework for developing post-processing methods#

Context#

xsnow is the powerful link between snow cover simulation datasets and sophisticated post-processing tools that assess avalanche hazard-relevant metrics from the raw data. As such, its scope is well-defined:

  1. Read and write simulation data into

  2. an efficient and flexible data model, as well as

  3. Facilitate a flexible application of post-processing tools

  4. in an easy-to-share manner.

While the first two objectives are described in detail in the xsnow tutorials, this part focuses on xsnow’s extension strategy that allows everybody in the community to write their own post-processing algorithms and analysis workflows on top of xsnow’s powerful base.

Objectives#

The objectives of the extension strategy are to

  • Create a common framework for developing post-processing methods

  • Provide guidelines for building extensions to the xsnow package

  • Show how to extend xsnow’s core data class xsnowDataset with custom dimensions and variables for post-processed data

  • Enable a flexible, consistent structure for computing, storing, and accessing post-processed data

Principles of the extension strategy#

  • Customization: Every stakeholder (research group, warning agency) can implement an extension that satisfies their need.

  • Independence: Anyone can implement extensions on their platforms and keep them private or share them publicly with the community.

  • Specificity: xsnow provides a flexible yet lean foundation, and everyone can extend that base with exactly the extensions they need without having to deal with unwanted extensions, unused dimensions, or cluttered method registries.

  • Chainability: Extensions can be chained in the desired order to facilitate the user workflow.

Built-in extensions versus externally hosted extensions#

xsnow ships several built-in extensions. They act as templates for other extensions, and, more importantly, they extend xsnow’s core functionality with generic features that we expect a wider audience to benefit from. Ideally, these built-in extensions are generic, customizable, and modular enough that they won’t change much over time.

More experimental extensions or those that implement specific hardcoded workflows should remain hosted outside the xsnow repository. Similarly, extensions that are sensitive to specific versions of their dependencies need to be hosted externally (e.g., often the case for machine learning models that were fit with a specific dependency version).

Application scenarios that require extensions to xsnow#

So, on a high-level, what are the different application cases where users may require extensions?

Three application scenarios

  1. Adding new data variables that perfectly fit into the existing xsnowDataset structure, such as

    • Scalars: HN24, HN72, HST, wind runs, etc

    • Layer properties: p_unstable, new stability indices, etc.

  2. Adding new data streams and functionality beyond the existing xsnowDataset structure, often adding new dimensions to the data model.

  3. Altering the existing core dimensions before applying scenarios 1 or 2, such as

    • aggregating existing locations into polygons before

    • storing regular scalars and/or aggregating layers

Application scenarios 1 & 2 seem most common. They involve in post-processing individual profiles or layers and the resulting output can be appended to an xsnowDataset.

Application scenario 3 is more complex, as core dimensions may change. Rather than appending output, the suggested approach is to initialize a new xsnowDataset with updated dimensions (e.g., locations may refer to polygons instead of grid points).

Contents