Ask any question about EPFL courses, lectures, exercises, research, news, etc. or try the example questions below.
DISCLAIMER: The Graph Chatbot is not programmed to provide explicit or categorical answers to your questions. Rather, it transforms your questions into API requests that are distributed across the various IT services officially administered by EPFL. Its purpose is solely to collect and recommend relevant references to content that you can explore to help you answer your questions.
From the start, the SNOWPACK model was created to address the needs of the avalanche warning in Switzerland based on a large network of Automatic Weather Stations (AWS). An energy balance approach was chosen that incorporated the modeling of the snow metamorphism in order to reproduce the stratigraphy, an arbitrary number of layers and the ability to simulate very thin layers. But a number of annoying issues remained for the daily use in an operational toolchain, linked to the handling of raw data coming from the AWS as well as the limitations of the AWS themselves. After the data preprocessing got separated from the SNOWPACK model itself as the MeteoIO library (in 2008), it experienced a sustained development effort over more than 15 years. Many typical data issues could be identified and addressed, often with timeseries filters in MeteoIO while a few had to be addressed in the SNOWPACK model itself. More flexibility was also allowed by new developments aimed at supporting operational constraints such as the inability to physically access some of the AWS in the winter, even to perform emergency maintenance. This paper shows some of the limitations of the measurement network from the SNOWPACK point of view and some typical data problems that have been encountered in the last 15 years while forcing SNOWPACK with raw AWS data. Some of the solutions that have been implemented and the compromises that had to be made are presented as well as their remaining limitations.