|
Alpine3D 20240418.cd14b8b
|
|
|
Alpine3D 20240418.cd14b8b
|
|
Here, we expose the core principles underlying the Alpine3D model. This should just give a quick overview of the model and help you understand the global architecture of Alpine3D. If you want to go deeper into the details, please have a look at the publications covering the whole model (M. Lehning et al. "ALPINE3D: a detailed model of mountain surface processes and its application to snow hydrology", Hydrological Processes, 20.10, 2006, pp 2111-2128; and P. Kuonen, M. Bavay, M. Lehning, "POP-C++ and ALPINE3D: petition for a new HPC approach", Advanced ICTs for disaster management and threat detection: collaborative and distributed frameworks, IGI Global, 2010, pp 237-61.) The individual modules are described here below and contain references to the relevant papers.
Here we expose the very foundations of Alpine3D. These remain valid independently of which modules are enabled when running the model.
At the core of the model, is the SNOWPACK model, a physically based, energy balance model for a 1D soil/snow/canopy column. This gives us a very detailed description of the snow stratigraphy and a very good evaluation of the mass and energy balance (therefore also of quantities such as Snow Water Equivalent (SWE) or temperature profile). This 1D energy balance is performed for each pixel of the domain (therefore it is a distributed SNOWPACK simulation) and for one time step (usually one hour). Any quantity that the user would like to get out of the simulation can be written out from this module.
In order to perform a SNOWPACK simulation at every pixel of the domain, it is necessary to get the meteorological forcing for each pixel. But the measured meteorological parameters are usually measured by a set of stations, which means that the data is available at a set of points. Interpolating these points measurements to every pixels of the domain is performed by the means of statistical interpolations with MeteoIO. if the forcing data is coming out of another model (such as a meteorological model), most probably the input grids have a resolution that is very insufficient for Alpine3D and therefore need downscaling. If the downscaling factor is very large, we often end up with only a few points from the meteorological model that are part of the Alpine3D domain, therefore such points can be considered as "virtual stations" and spatially interpolated similarly to weather stations.
The core principles laid out in the previous section rely on the assumption that there are no lateral fluxes, which is too strong of an assumption. Therefore the lateral fluxes deemed relevant are introduced by other modules:
Once the albedo of each pixels of the domain have been initialized or taken from the last time step, the radiation balance is computed. First, the incoming short wave radiation measured at one reference station is used to compute the splitting (between direct and diffuse, see D. G. Erbs, S.A. Klein, J.A. Duffie, "Estimation of the diffuse radiation fraction for hourly, daily and monthly-average global radiation", Solar Energy, 28, 4, 1982, Pages 293-302 and summarized in M. Iqbal, "An introduction to solar radiation", 1983, Academic Press, ISBN: 0-12-373750-8). This splitting will be assumed to be constant over the whole domain. Then, according to the meteorological parameters and elevation of each pixel, the direct and diffuse radiation fields are computed. Since the position of the sun has been computed ( J. Meeus, "Astronomical Algorithms", 1998, 2nd ed, Willmann-Bell, Inc., Richmond, VA, USA, ISBN 0-943396-61-1), it is used to compute the topographic shading for each pixel. If the terrain reflections have been enabled, a radiosity approach is used to compute the reflections by the surrounding terrain ( N. Helbig, H. Löwe, M. Lehning, "Radiosity Approach for the Shortwave Surface Radiation Balance in Complex Terrain", Journal of the Atmospheric Sciences, 66.9, 2009). Finally, the direct and diffuse radiation fields are returned.
Externally computed wind fields (for example with ARPS) are assigned to each time steps. If the surface shear stress exceeds a given threshold at a given pixel, the saltation will be computed. This in turn can feed the suspension if the saltation layer is saturated. While in suspension, some of the mass will sublimate and contribute to the relative humidity field ( C. D. Groot Zwaaftink et al. "Drifting snow sublimation: A high‐resolution 3‐D model with temperature and moisture feedbacks", Journal of Geophysical Research: Atmospheres (1984–2012), 116.D16, 2011).
Several options are available for collecting the melt water or precipitation running out of each pixel. The historical approach relies on the PREVAH hydrological modeling system ( D. Viviroli et al. "An introduction to the hydrological modelling system PREVAH and its pre-and post-processing-tools", Environmental Modelling & Software, 24.10, 2009, pp 1209-1222) to perform on-the-fly hydrological simulation. Another approach consists of collecting the runoff sums for each sub-catchments defined by the user (M. Bavay, T. Grünewald, M. Lehning, "Response of snow cover and runoff to climate change in high Alpine catchments of Eastern Switzerland", Advances in Water Resources, 55, 2013, pp 4-16). Finally, it is also possible to output the hourly distributed runoff (ie the runoff for each pixel, once per hour) and process this runoff in an external model ( F. Comola et al. "Comparison of hydrologic response between a conceptual and a travel time distribution model for a snow-covered alpine catchment using Alpine3D", EGU General Assembly Conference Abstracts, Vol. 15, 2013; J. Magnusson et al. "Quantitative evaluation of different hydrological modelling approaches in a partly glacierized Swiss watershed", Hydrological Processes, 25.13, 2011, pp 2071-2084). This approach enables the external model to be calibrated without having to re-run Alpine3D.
1.9.4