Skip to content

Snowpack best practices

Configuring SNOWPACK model output

SNOWPACK has four main outputs:

  1. timeseries information, containing bulk information about the snow cover, such as turbulent fluxes, snow water equivalent, etc. Generally, these are written out as either .met files, or .smet files.
  2. detailed snow cover information, like density profiles, temperature profiles, etc. Generally these are written out as *.pro files, but other output formats are available.
  3. snow cover backup files (*.sno). These are restart files for SNOWPACK. SNOWPACK can restart the simulation from these files, without loss of information. The format is similar to the input file that needs to be provided to start a simulation.
  4. hazard files, containing some hazard related information (24h new snow sums, etc).

Timeseries

The following [Output] keys can be used here:

  • TS_DAYS_BETWEEN = 0.125: specify the output frequency in days. Common intervals are 0.0104166667 for 15 minute output, 0.0208333 for 30 minute output, 0.04166667 for hourly output and 0.125 for 3 hourly output
  • TS_FORMAT = SMET: the output format to use
  • TS_START = 0.0: offset for writing profiles in hours. For example, if TS_DAYS_BETWEEN is set to 0.5, and TS_START to 6, then the first output is at 06:00, and then 18:00, etc.
  • TS_WRITE = true: toggle whether the timeseries need to be written or not.

Some remarks

  • You can specify groups of parameters that you want to include in the output, by using the keys OUT_HEAT, OUT_MASS, OUT_METEO, etc.
  • If not doing a restart (by either using OPERATIONAL mode, or specifying -r on the command line), the first timestep will always be written as output, irrespective of the setting for TS_START
  • Similar keys are used for the *.pro file output (PROF_WRITE, etc.).

Virtual slopes

  • The key MEAS_INCOMING_LONGWAVE is important here. If you have measured ILWR, or a reliable source of ILWR from for example a NWP model, it makes sense to set this key to TRUE. This would then use the same value of ILWR for the flat field as well as the slopes. In case you generate ILWR from other parameters, this likely is also the desired setting. Now, if the key is set to FALSE (default), SNOWPACK will determine ILWR by closing the energy balance. This is the best option in case the generated ILWR radiation is not reliable. But a simulation can only be run without a reliable source of ILWR, if reliable snow surface temperature measurements are available. To summarize, most applications would probably require MEAS_INCOMING_LONGWAVE = TRUE for best results on the virtual slopes.

Initializing soil layers

Soil thickness

  • If a measured temperature in the soil is available, this can be used as lower boundary condition. In that case, only the soil above the measured temperature can be simulated.
    • Set SOIL_FLUX = FALSE
    • Prescribe bottom temperature as variable TSG
  • If no measured temperature is available, or if you don't want to use TSG, you can use a heat flux boundary condition. Typically, we assume a geothermal heat flux. It is commonly assumed that this heat flux can be found at a depth of 5m. Thus, in this case:
    • Set SOIL_FLUX = TRUE, and prescribe the heat flux to be applied at the lower boundary
    • Set GEO_HEAT to specify the heat flux to be prescribed (typically 0.06 is assumed here)
    • Simulate at least 3m of soil, but better is 5m. If the soil is shallower, the geothermal heat flux has a too strong impact on the snowpack.

Layer spacing

In order for the model to be able to describe temperature gradients near the surface, a layer spacing of around 2 cm must be maintained in the uppermost surface layers. This can then quickly increase to 5, 10, 20, 50cm deep layers with depth, to reduce computational cost.

Soil layer properties

When using Richards equation for liquid water transport, the soil parameters are set using the grain size, according to this table. With the bucket scheme, more flexibility is possible. Adjust theta[SOIL], Rho, and heat conductivity and capacity according to the soil type you want to simulate. Note that these values are not bulk values, but only the values for the theta[SOIL] part. For example, the soil density is determined as theta[SOIL]Rho + theta[WATER]Rho_water. Sometimes in literature, bulk values are reported. This can be a bit confusing.

Some remarks:

  • Temperature profile: ideally, you run a few years of spinup, to get a realistic temperature and liquid water content profile. If this is not feasible, the second best option is to initialize the soil with the annual average air temperature.
  • When initializing soil in freezing conditions: this can be tricky and sometimes result in numerical instabilities when for example the soil is initialized at +5 Celcius, but with some ice content. Then, in the first time step, SNOWPACK has to do a lot of phase changes to obtain thermal equilibrium. Better approach is to pay attention and use a temperature consistent with the state of the soil:
    • When using the bucket scheme: no freezing point depression is possible. Thus, if ice is present, the temperature must be 0C or lower. If water is present, the soil must be 0C or higher. If both are present, the temperature must be 0C.
    • When using Richards equation: a freezing point depression is possible. To avoid numerical instabilities, set REQ_INITIALIZE_SOIL = TRUE in [SNOWPACKADVANCED]. This will run an initialization routine, to make the theta[ICE] and theta[WATER] consistent with the layer temperature.

Some more remarks:

  • Note that if simulated soil temperatures do not match observed ones, this can be due to wrongly chosen thermal properties of the soil, but also due to an over- or underestimation of water retention. If too much water is retained in the soil, more energy is needed for phase changes for example, and an overestimation of soil temperatures is typically found. This aspect is often overlooked.
  • When using the bucket scheme, water retention is determined based on layer grain size. See the function ElementData::soilFieldCapacity() in DataClasses.cc
  • Please note the way thermal conductivity is treated. There are three options:
    1. SOIL_THERMAL_CONDUCTIVITY = RAW: Arithmetic average
    2. SOIL_THERMAL_CONDUCTIVITY = COSENZA2003: thermal conductivity model from Cosenza et al. (2003). This option is recommended.
    3. SOIL_THERMAL_CONDUCTIVITY = FITTED: it is a fitted function. See the function double SnLaws::compSoilThermalConductivity in Laws_sn.cc. It is not recommended to use this one.