Inputs

Several categories of data are necessary for the input:

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

The landscape data can be prepared with any GIS software (for example, the Open Source QGIS), the meteorological data with statistical computing tools (for example R) or scripts (for example Python or AWK) and the snowcover data has to be prepared with scripts.

Landscape data

Digital Elevation Model

Example of a Digital Elevation Model grid

Once you have defined the domain that you want to simulate, you have to get a Digital Elevation Model that contains this area. The DEM must be rectangular, but you will be able to restrict the actual domain within this rectangular area by settings the cells you want to ignore to 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 necessary 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.

DEM data can either come from your own measurements (for example from laser scans, see P. Axelsson, "DEM generation from laser scanner data using adaptive TIN models", International Archives of Photogrammetry and Remote Sensing, 33.B4/1, PART 4, 2000, pp 111-118), from your national topographic service (Swiss Topo for Switzerland, IGN for France, National Elevation Dataset for the USA, HeliDEM for the southern Alps) or from global initiatives ( GTOPO30, a 30-arc-second global dem, GLOBE, a 30-arc-second global dem, SRTM, a 1-arc-second global dem between 60N and 56S averaged at 90m resolution, ASTER DEM, a 30m resolution global dem between 83N and 83S).

Land Cover model

Example of a Land Cover grid

For each cell of the domain, a land cover code must be provided. This must be using the exact same geolocalization as the DEM. You can create you own LUS file based on aerial photography (see in section simulation tools) or find such data for your area of interest. Such data are usually available in various classifications depending on the country, for example:

• CORINE for Europe;
• the US National Land Cover Dataset for the USA;
• the countryside survey for the UK;
• Arealstatistik NOAS04 for Switzerland;
• GLC for a 30m resolution global land cover or FAO GeoNetwork for multiple land cover data sets including a 30 arcsec resolution global land cover.

Currently, Alpine3D improperly calls the Land Cover Model "Land Use", abbreviated as LUS and uses an ARC ascii file (see MeteoIO's documentation) with PREVAH landuse codes that have the format 1LLDC where:

• LL is the land use code as given in the table given below
• D is the soil depth (unused)
• C is the field capacity (unused)

PREVAH land cover codes

land use (vegetation) Prevah land use classes 01 water 02 settlement 03 coniferous forest 04 decidous forest 05 mixed forest 06 cereals 07 pasture 08 bush 09 undefined 10 undefined 11 road 12 undefined 13 firn 14 bare ice 15 rock

land use (vegetation) Prevah land use classes 16 undefined 17 undefined 18 fruit 19 vegetables 20 wheat 21 alpine vegetation 22 wetlands 23 rough pasture 24 subalpine meadow 25 alpine meadow 26 bare soil vegetation 27 free 28 corn 29 grapes 30-99 undefined

Remarks

There is a common confusion between land use and land cover, when actually a land cover is determined by direct observations (OECD definition) while a land use requires socio-economic interpretation of the activities that take place on that surface (OECD definition), see P. Fisher, A. Comber, and R. Wadsworth, "Land use and Land cover: Contradiction or Complement", Re-presenting GIS, 2005, pp85-98).

Catchments definition

Example of catchments definition

For hydrological modeling, hydrological subcatchments must be defined. Both the precipitation, snow melt and glacier melt contributions are provided as well as the total catchment runoff, for each subcatchment. The subcatchments are defined by creating a grid that contains a code describing which catchments this cell 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. Finally, this grid must have the same geolocalization as the dem.

Snow cover and soil data

Initial soil and snow definition

Either each cell must be assigned an initial soil and snow profile (as well as a few Canopy parameters). 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 written in a Snowpack snowfile supported format (see Snowpack documentation, "Data File Formats" > "Single Snow Profiles") and usually kept with all other similar files in a separate directory (in order to keep the simulation tidy). Finally, the profile and layers must be dated from before the simulation starts.

There are two possibilities for assigning these files to each cell of the simulation domain (see reading snow files):

• by land cover classes. In this case, every cell receives an initial soil/snow profile based on its land cover class. The files must be named as {LAND_USE_CLASS}_{EXPERIMENT_NAME}.{ext};
• independently for each (i,j) pixel (i being in the x direction and j in the y direction, referenced by the lower left corner). In this case, the files must be named as {i_index}_{j_index}_{EXPERIMENT_NAME}.{ext};

Note

In any case, you MUST set the key "EXPERIMENT_NAME" in the [Output] section.

Meteorological data

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

Meteorological inputs often come from automatic weather stations that are part of a measurement network (for example M. Lehning et al. "A network of automatic weather and snow stations and supplementary model calculations providing snowpack information for avalanche warning", Proceedings of the International Snow Science Workshop “a merging of theory and practice”, 27, 1998 or the US SNOTEL network) or are deployed for a specific experiment and area. The networks are often managed by national weather services.

It is also possible to find some other data producers such as airports, Synop stations (a script to download and convert the data is available in MeteoIO's tools directory), railways operators, highways (or this), ski lift operators, network of citizen weather stations.

Another source of data can be reanalysis runs performed with weather forecasting models on measured data (UK metoffice, Norvegian Meteorological Institute, Euro4M for all of Europe as well as worldwide NOAA ESRL and ECMWF (with associated DEM) reanalysis).

Point measurements

This is mostly centered around the concept of station: a specific point in space 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 meaningfully resampled to an hourly resolution (i.e., daily measurements would usually 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 (PSUM)
• at least one point offering simultaneously the following:
  • air temperature (TA)
  • relative humidity (RH)
  • incoming short wave radiation (ISWR)
  • incoming long wave radiation (ILWR)

If the air pressure (P, usually in Pa) is provided, it will be used for improving some of the parametrizations, but this is absolutely not mandatory. However, it is recommended to provide stations well distributed over the domain and over the elevation range, so the elevation gradients can be properly computed.

Gridded meteorological data

This relies on meteoio's USER spatial interpolation algorithm. The grids must follow a specific naming scheme and be placed in a specific directory so they can be found and the grids must have the same geolocalization 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 (according to the spatial interpolation algorithms declared in the configuration file). It is therefore possible to only provide a few specific grids according to the needs (for example, the precipitation grids only when precipitation occurs).