3. What are its design goals?
Act as an interface between physical
modeling and data sources
Suitable for operational systems
Reusable processing components between
models
Suitable for a wide range of models
Easy to install, use and expand
4. What is MeteoIO?
MeteoIO is a toolbox:
It won't do anything for you; it enables you to
do things
It is not limited to a few tasks; its building blocs
can be combined at will
It strives to provide standard processing blocs
to c++ for working with meteorological data
6. A model/data source interface
The model should not be changed when
changing data source (MeteoIO insulates the
model)
MeteoIO must provide all data conforming to a
given abstraction, regardless of their initial
characteristics
Formats conversions, time/coordinates/semantics
conversions
Arbitrary sampling rate conversion
Do the best possible for each data source
7. Operational usage
Must run unattended → autonomous,
robust
Must handle the unexpected (if possible)
Must be reasonably fast
High variability: data quality, quantity
Perform all the data pre-processing that is
needed by the model, automaticaly
10. Features: overview
Read meteo data from various sources and
preprocess it
Read gridded data from various sources
Write meteo data to various destinations
Write gridded data to various destinations
Offer various “convenience” objects to
handle meteo data
11. Reading meteo data
What happens when an application
requests a data point from MeteoIO?
13. The plugins: basics
The specific handling of a
format/protocol is contained in a plugin
(ARC, IMIS, SMET)
Therefore, a plugin must:
• Know where to find data, how to read it
• Convert units, perform reprojections
(rotated coordinates)
• Convert all data to MeteoIO's objects:
Coords → StationData → MeteoData
• Offer a specific set of functions
14. The plugins: interface
All plugins offer the same functions:
• Get all station metadata at a given date
• Get all meteo data between two dates
• Write a given meteo dataset
• Read 2D grid, by name or by parameter
• Write 2D grid, by name or by parameter
• Read dem, landuse, special points
But, each plugin is different:
• Not all functions are relevant for all plugins
• The configuration depends on the plugin (database
vs file)
In the [Input] and/or [Output] section(s)
16. The processing stack
Goes through the processing element, one after
another (i.e., serial)
Two kind of processing elements:
• Filters: keep or reject data (ex. min/max)
• Processing: modify the data (ex. undercatch)
processing elements defined by meteo parameter
Each processing elements has its own options
Common principle: “soft”
All in the [Filters] section
17. Available filters
RATE: rate of change filter
MIN_MAX: range check filter
MIN: minimum check filter
MAX: maximum check filter
STD_DEV: reject data outside mean +/- k*stddev
MAD: median absolute deviation
TUKEY: Tukey53H spike detection, based on median
UNHEATED_RAINGAUGE: detection of snow melting in a rain
gauge
It is easy to implement new filters!
18. Available processing elements
EXP_SMOOTHING: exponential smoothing of data
WMA_SMOOTHING weighted moving average smoothing of data
MEDIAN_AVG: running median average over a given window
MEAN_AVG: running mean average over a given window
WIND_AVG: vector average over a given window
ADD: adds a given offset to the data
MULT: multiply the data by a given factor
UNDERCATCH_WMO: WMO rain gauge correction for undercatch,
using various correction models
UNDERCATCH_HAMON: Hamon1973 rain gauge correction for
undercatch
UNVENTILATED_T: unventilated temperature sensor correction
19. Temporal interpolations
Goal: digest arbitrary time intervals
(including irregular) & provide the data at
any timestamp
• Standard methods (fast) can not be used
• Needs a “search radius” for safety & logic
• Configured per meteo parameter
resampling != reaccumulate, Interpolation !
= extrapolation
configured in the [Interpolations1D] section
21. Spatial interpolations
Distribute points measurements on a dem
Strongly dependent on the inputs (#stations)
Potentially very slow
Configured in [Interpolations2D]
• Per meteo parameter
• A list of acceptable algorithms is provided,
the “best” is evaluated & used for each
timestamp
• Each algorithm has its own options &
behavior (fallback)
23. Spatial interpolations
The keywords defining the algorithms are the following:
• STD_PRESS: standard atmospheric pressure as a function of the elevation of each cell
• CST: constant value in each cell
• CST_LAPSE: constant value reprojected to the elevation of the cell
• IDW: Inverse Distance Weighting averaging
• IDW_LAPSE: Inverse Distance Weighting averaging with reprojection to the elevation of the cell
• LIDW_LAPSE: IDW_LAPSE restricted to a local scale
• RH: the dew point temperatures are interpolated using IDW_LAPSE, then reconverted locally to
relative humidity
• ILWR: the incoming long wave radiation is converted to emissivity and then interpolated
• WIND_CURV: the wind field (VW and DW) is interpolated using IDW_LAPSE and then altered
depending on the local curvature and slope
• HNW_SNOW: precipitation interpolation according to (Magnusson, 2011)
• ODKRIG: ordinary kriging
• USER: user provided grids to be read from disk
24. Spatial interpolations
What can degrade your interpolations:
– Inappropriate interpolation method
– Stations' range too limited
– Badly representative station
25. Data Generators
•Last resort option
• When everything else failed
• Use parametrizations relying on other
parameters
•Available generators:
• Cst
• Sin (yearly/daily)
• Unsworth ILWR
• Potential ISWR