Configuration (rojak.orchestrator.configuration)#
Pydantic schema for the YAML configuration consumed by rojak run (rojak.cli.main.run())
Context, loaded via BaseConfigModel.from_yaml(), is the root of the configuration tree and
describes an entire run: where to write output (Context), what turbulence analysis to perform
(TurbulenceConfig, TurbulencePhases), and what input data to use (DataConfig,
MeteorologyConfig, AmdarConfig). Where meteorological data lives is described by a
DataLocation, and which MetData adapter reads it by
MetDataSource (see rojak.datalib.registry).
Turbulence analysis is split into a calibration stage (TurbulenceCalibrationPhases, deriving thresholds
and EDR distribution parameters from a calibration dataset) and an evaluation stage
(TurbulenceEvaluationPhases, applying those to an evaluation dataset), each made up of a configurable
list of phases (TurbulenceCalibrationPhaseOption, TurbulenceEvaluationPhaseOption). Most classes
in this module validate that the configuration is internally consistent (e.g. that a phase’s dependencies are
also configured) and raise InvalidConfigurationError if not.
Functions
|
Rewrite a legacy |
Classes
|
Metric used to aggregate a diagnostic's skill at classifying observed turbulence, within each spatial group |
|
Configuration for a directory of AMDAR turbulence observations, see |
|
AMDAR turbulence observation provider, see |
|
Which stage's diagnostic values AMDAR observations are compared/harmonised against |
Base class for every pydantic configuration model in this module, providing |
|
|
Base configuration for a directory of input data from a given provider |
|
Base configuration for a directory of input data from a given provider |
|
Root configuration for a |
|
Contrail formation/persistence model (from |
|
Top-level configuration for contrail analysis, see |
|
Configuration for the input data (both meteorological and AMDAR observational) used by a run |
|
A single condition defining when an observed AMDAR column counts as turbulence, for diagnostic validation |
|
Configuration for validating turbulence diagnostics against observed AMDAR turbulence |
|
Algorithm used to identify the jet stream from meteorological data |
|
Meteorological reanalysis data provider, see |
|
A meteorological dataset: what it is ( |
|
Association measure to compute between two binary features, see |
|
A rectangular (and optionally vertically-bounded) geographic domain to restrict data to |
|
How to group observations/diagnostic values spatially before aggregating validation statistics |
|
Configuration for the turbulence calibration stage, see |
|
A step of the turbulence calibration stage |
|
The turbulence calibration stage: which phases to run, and the configuration they need |
|
Top-level configuration for turbulence analysis, see |
|
A clear-air turbulence (CAT) diagnostic to compute, see |
|
Configuration for the turbulence evaluation stage, see |
|
A step of the turbulence evaluation stage, see |
|
The turbulence evaluation stage: which phases to run, and the configuration they need |
|
The full turbulence workflow: a required calibration stage and an optional evaluation stage |
|
Turbulence intensity severity, in increasing order of intensity from |
|
How a |
|
Threshold value for each turbulence severity, used to determine whether a diagnostic value counts as that severity |
Exceptions
|
Raised when a configuration file is malformed or internally inconsistent |