Alpine3D: an alpine surface processes model Mathias Bavay WSL Institute for Snow and Avalanche Research SLF, Davos, Switzerland

© Mathias Bavay 1. Goals Alpine surface processes modeling over an area. Inputs: DEM + weather stations data Used for snow hydrology, snow cover studies, climate change studies  Water availability? Flooding? Hydropower potential?  Avalanche danger? Permafrost? Possible tool for computing distributed physical parameters  High resolution surface temperature data  High resolution radiation data

© Mathias Bavay 1.1 Domain definition We define a domain (catchment)‏ This gives: the Digital Elevation Model (2D grid)‏ the land use model some soil model for each grid cell

© Mathias Bavay 1.2 Time dependent data We use meteorological data (point measurements)‏ Air temperature Relative humidity Wind Precipitations Radiations

© Mathias Bavay 1.3 Results We simulate snow depth, snow cover, catchment discharge... Snow depth Catchment discharge Snow profile

© Mathias Bavay 2. How? How is the modeling organized?

© Mathias Bavay 2.1 Snowpack Base element: Lateral exchanges limited soil/snow/canopy column Known forcing (radiation, precipitations, temperature, etc)‏ How is the snowpack at this location (depth, layering)? Distributed snow cover Our domain is N*M individual 1D columns

© Mathias Bavay 2.1 SNOWPACK 1D soil/snow/canopy column no lateral exchanges Arbitrary number of layers Heat diffusion Models for albedo, settling, canopy... Each cell of the grid is 1 SNOWPACK simulation  Parallelization by cell ranges  No exchanges between cells

© Mathias Bavay 2.2 Energy input Good energy input absolutely necessary! Mostly from radiation Thermal radiation: long wave (sky + terrain)‏ Direct & diffuse short wave radiation (atmosphere, sun/shadow + terrain reflections)‏ How to deal with clouds?

© Mathias Bavay 2.2 Energy Balance 3D radiation balance Radiosity approach sun/atmosphere parameters Shading Arbitrary multiple terrain reflections Short and long wave treated separately Very CPU intensive  No parallelization yet  Exchanges between neighboring cells

© Mathias Bavay 2.3 Drifting snow Snow transport mechanisms: Saltation Suspension Sublimation (removes mass)‏ Preferential deposition

© Mathias Bavay 2.3 Snowdrift Lateral snow exchange (by wind)‏ 3 processes: Saltation Suspension Sublimation Suspension & sublimation solved together Saltation as boundary condition Exchanges between cells Very CPU intensive  Suspension parallelized with standard numerical libraries (using MPI)‏

© Mathias Bavay 2.4 Runoff Hydrological contribution: Each cell maintain its runoff buckets Collect them all to get outlet discharge

© Mathias Bavay 2.4 Runoff Collecting liquid water From the bottom of each column Bucket model But requires global view of the data Inexpensive computation (so far)‏  No need to parallelize

© Mathias Bavay 3. Data input The models work by cells... Meteorological data at point measurements Need to have meteorological parameters for the cell! How to calculate cell value in a physically sensible way?

© Mathias Bavay 3. Data input Getting data in and out Raw data Filtering Spatial interpolations Reading grids and preparing them (DEM)‏ outputs  No need to parallelize yet, interpolations could become CPU intensive

© Mathias Bavay 4 Full overview Design philosophy 1 module per major process Each module can be made of an arbitrary hierarchy of sub- processes Follow the structure of the physics, not of the computer! Parallel and sequential versions must share the same code Parallelization Each module runs // Synchronization points when order is important Blend of parallel and sequential code

© Mathias Bavay Conclusion Complex code: Multi-physics Multi-scales So, multi-models! 1 major physical process = 1 object MPI-style approach: Would break the physical processes structure Or would force MPI into a structure that is not his! Pop-C++: Keep physical processes structure Parallelize per object, ie per physical process Can contain MPI code as well as parallelization within a parallel object