Meteoio Introduction given by Mathias Bavey in Bozen

365 views

Published on

MeteoIO introduction given by Mathias Bavey in Bozen.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
365
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Meteoio Introduction given by Mathias Bavey in Bozen

  1. 1. Using MeteoIO M. Bavay with contributions from T. Egger, C. Fierz, N. Wever, D. Zanella, ... WSL-Institut für Schnee- und Lawinenforschung SLF 1
  2. 2. What is MeteoIO? What is it designed for? Why do we need it?
  3. 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. 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
  5. 5. A model/data source interface
  6. 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. 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
  8. 8. Reusability/modularity
  9. 9. What can MeteoIO do?
  10. 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. 11. Reading meteo data What happens when an application requests a data point from MeteoIO?
  12. 12. In the background...
  13. 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. 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)
  15. 15. Available plugins
  16. 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. 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. 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. 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
  20. 20. Temporal interpolations
  21. 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)
  22. 22. Spatial interpolations [Interpolations2D] TA::algorithms = IDW_LAPSE CST_LAPSE TA::cst_lapse = -0.008 RH::algorithms = RH IDW_LAPSE CST_LAPSE CST HNW::algorithms = HNW_SNOW IDW_LAPSE CST_LAPSE CST HNW::hnw_snow = cst_lapse HNW::cst_lapse = 0.0005 frac VW::algorithms = IDW_LAPSE CST_LAPSE P::algorithms = STD_PRESS
  23. 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. 24. Spatial interpolations What can degrade your interpolations: – Inappropriate interpolation method – Stations' range too limited – Badly representative station
  25. 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

×