Alpine3D

InputData-preparation

Table of Content

How to prepare the input data for Alpine3D

Several categories of data are necessary for the input:

  • Landscape data: Digital Elevation Model, Land Cover model...
  • Snowcover and soil data
  • Meteorological data

We will go through each of these categories. But first, it is usually a good idea to set up a clean structure for the simulation, as explained below.

Simulation files structure

We will consider that everything goes into a simulation folder, for example my_simulation. Then you could create several subdirectories: input, output, setup and bin. These subdirectories contain the following:

  • in input, all the input data, stored in a surface-grids directory for the landscape data, in a meteo directory for the meteorological data and in a snowfiles directory for the snowcover and soil data.
  • in output, all the outputs will be writen, the gridded data in grids, the snowcover and soil data in a snowfiles subdirectory and the runoff data in a runoff directory.
  • in setup, all the configuration files and start scripts
  • in bin, all the binary files (namely, the alpine3d binary and some associated libraries as well as the parallel objects for the parallel version).

Landscape data

Digital Elevation Model

Once you know the domain that you want to simulate, you have to get a Digital Elevation Model that contains this area. Usually, these are provided within a rectangular area. You will be able to restrict the actual domain within this rectangular area by settings the cells you to ignore as nodata. However, you need to keep in mind the following:

  • The DEM defines the spatial grid that will be used in Alpine3D
  • Therefore, the resolution of the DEM is the spatial resolution of the simulation
  • Each cell whose DEM is nodata will be skipped by all modules of Alpine3D
  • In order to properly compute the shading effects, do not exclude cells that could cast shades on an interesting part of the domain!

These last two points are important for both the definition of the rectangular DEM as well as filling the unecessary cells with nodata. All other grids (either land cover or potential meteorological grids) will have to use the exact same geolocalization as the DEM (same position, same size, same resolution) unless otherwise specified.

Land Cover model

For each DEM cell, a land cover code must be provided. This must be using the exact same geolocalization as the DEM. uch data are usually available in various classifications, depending on the country. Currently, Alpine3D uses the prevah classification (see Meteoio's ARC plugin documentation) and (improperly) calls the Land Cover Model "Land Use", abbreviated as LUS.

Catchments definition

If you intend on computing the runoff, you have to define the individual catchments. This is currently done by creating a grid that contains a code describing which catchments this pixel belongs to, based on sums of powers of two. For example, a pixel belonging to catchments 0 and 3 would receive the code: 2^0+2^3=9. A pixel belonging to catchments 2, 5, 6 would receive the code 2^2+2^5+2^6=100.

Snow cover and soil data

Either each cell or each cell class (based on Land Cover classification) must be assigned an initial soil and snow profile. Usually, to make things easier, the simulation starts at a time when no snow is present in the domain, making the snow profile empty. The same file also contains potential soil layers data. This file is writen in a Snowpack snowfile supported format (see Snowpack documentation). The profile and layers must be dated from before the simulation starts. The file is named {EXPERIMENT_NAME}_{LAND_USE_CLASS}.{ext} and placed along all other similar files in a separate directory (in order to keep the simulation tidy).

Meteorological data

Usually, the meteorological inputs are provided as points measurements time series and spatially interpolated within alpine3d (using meteoio). But it is also possible to provide some (or all) data as gridded data.

Gridded meteorological data

This relies on using meteoio's USER spatial interpolation algorithm. The grids must follow a specific naming scheme so they can be found and be placed in a specific directory and the grids must have the same geolocalization and size as the dem. This is detailed in meteoio's documentation.

Please note that if not all necessary grids are provided, meteoio will revert to point measurements inputs. It is therefore possible to provide only a few specific grids according to the needs (for example, only the precipitation grids when there are some precipitation).

Point measurements

This is mostly centered around the concept of station: a specific point in the landscape where multiple parameters are measured for a given period. The file formats vary greatly depending on which meteo plugin is used. It is nevertheless always possible to use stations that don't cover the whole period or contain data gaps. It is also possible to use stations that are outside the domain (but they should not be too far away, otherwise this does not make sense!). The model will run with an hourly resolution, so the data should be either hourly or could be meaningfuly resampled to an hourly resolution (i.e., daily measurements would not qualify). Please note that in any case, the following must always be provided:

  • at least one of:
    • air temperature (TA)
    • relative humidity (RH)
    • wind speed (VW)
    • precipitation (HNW)
  • at least one point offering simultaneously the following:
    • air temperature (TA)
    • relative humidity (RH)
    • incoming short wave radiation (ISWR)
    • incoming long wave radiation (ILWR)

It is also recommended to provide stations well distributed over the domain and over the elevation range, so the elevation gradients can be properly computed.

Created: 5 years 4 months ago
by Mathias Bavay

Updated: 4 years 4 months ago
by Mathias Bavay

Old Revisions