Snowpack performs physical modeling of the various processes taking place between the soil, snow cover and atmosphere in order to simulate the evolution of the snow cover based on meteorological input data. It requires the following meteorological parameters:

air temperature (TA)
relative humidity (RH)
wind speed (VW)
incoming short wave radiation (ISWR) and/or reflected short wave radiation (RSWR) or net short wave radiation (it must be called NET_SW in Smet files).
incoming long wave radiation (ILWR) and/or surface temperature (TSS)
precipitation (PSUM) and/or snow height (HS)
ground temperature (TSG, if available. Otherwise, you will have to use MeteoIO's data generators to generate a value) or geothermal heat flux
snow temperatures at various depths (TS1, TS2, etc if available and only for comparisons, see section Snow and/or soil temperatures)

These parameters should best be available at a hourly time step and preferably in MKSA units (please check the MeteoIO plugins documentation for specific cases, like GRIB, NetCDF... that are automatically handled). Please have a look at the other input parameters that are required to run your simulation!

Data preparation

In order to help Snowpack handle the (sometimes broken) data sets to be used in a simulation, the MeteoIO library is used. This enables Snowpack to get data from a variety of sources (several input file formats, connection to a database, connection to a web service) and to pre-process real-world data, by filtering the data on the fly and by resampling the data on the fly. Please read the MeteoIO documentation (available online for the last official release) to learn about the supported file formats, the available filters and resampling/re-accumulation strategies as well as the available parametrizations that can help generate some otherwise missing data (either from other parameters or fully synthetic, as last resort).

It is recommended to prepare the data in the SMET file format for its ease of use.

Data recommendations

In case incoming and reflected short wave radiation as well as incoming long wave radiation are all measured under ventilated and heated conditions, the best approach in terms of energy flux calculations seems to be by using:

SW_MODE = "BOTH" ; that is, incoming and reflected short wave radiation are both measured)

CHANGE_BC = false ; that is, Neumann boundary conditions throughout

In case you only have reflected short wave and snow surface temperature, using Dirichlet boundary condition would be recommended:

SW_MODE = "REFLECTED" (that is, reflected short wave radiation is available)
MEAS_TSS = true    ;our surface temperature measurement is good and can be used for validation criteria
CHANGE_BC = true

For energy balance interpretation the change of internal energy is for that case better than the sum of fluxes.

Data checks

Please keep in mind that any inaccuracy on the input parameters will have an impact on the quality of the simulation. Since the modelling is physically-based, manually re-constructing missing data can lead to completely wrong results if not done with great care (the model performing various checks on the physical consistency of the input data, it will exclude data points that are not consistent with the other parameters. For example, precipitation occuring simultaneously with quite dry air will be refused).

Data consistency check

For example, the figure above allows to check the following points:

the (solid) precipitation are synchronized with the major snow height increase - this is consistent;
the precipitation happen during hight relative humidity periods - this is consistent;
during times of precipitation, the air and surface temperatures remain close - this means that the sky is cloudy, this is consistent;
a few periods of low wind speed coincide with high relative humidity, which could lead to surface hoar formation - look for it in the simulation outputs;
early in the season, two periods of high wind speed could have lead to drifting snow. The first one occurs during a large snow fall and therefore might be hidden in the data while the second period that experiences a strong snow height decrease could also be driven by rapidly increasing air temperatures - the precipitation might show a large undercatch while the snow might have been wind pressed;
late in the data set, the snow height measurements fail for an extended period of time at a time of high wind speed - some snow drift might have gone unnoticed.

When using spurious data or when faced with a bad behaving simulation, one should first look at the consistency of the input data. The vast majority of the problems can be traced back to some low quality data (either for sensor issues or spurious data manipulation at some stage).

Snow and/or soil temperatures

Up to 5 snow and/or soil temperatures, either measured or modelled or both can be monitored. Measured temperatures are read in from the input file. If you use the smet format, do not forget to properly label the columns as TS1, TS2, TS3, etc. If you use the snio format, refer to the documentation. User defined positions (m) should be provided in the SnowpackAdvanced section of the "io.ini" file, for example, FIXED_POSITIONS = "0.25 0.50 -0.10":

positive values refer to heigths measured from the ground surface (snow only)
negative values refer to depths measured from either the ground surface or the snow surface in case no soil layers are present
A sensor must at least be covered by MIN_DEPTH_SUBSURF (m) snow for its temperature to be output. This parameter can be set in the SnowpackAdvanced section of the io.ini file.

Precipitation phase

If the precipitation phase is available, you can provide it along the meteorological input under the name "PSUM_PH". This phase represents the fraction of liquid precipitation; for example:

it is set to zero for fully solid precipitation;
it is set to one for fully liquid precipitation;
it is set to 0.75 for mixed precipitation made of 75% liquid and 25% solid.

If no precipitation phase is provided, Snowpack will rely on a fixed threshold approach: for air temperatures above the value given by THRESH_RAIN in the SnowpackAdvanced section of the "io.ini" file, liquid precipitation is assumed while in the contrary fully solid precipitation is assumed.

It is possible to use other spliting schemes by defining a data generator in the "io.ini" file (see in MeteoIO's documentation the section "Available data generators and usage" for the full list of available generators):

[Generators]
PSUM_PH::generators   = PPHASE
PSUM_PH::pphase::type = RANGE
PSUM_PH::pphase::snow = 273.35
PSUM_PH::pphase::rain = 275.35