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

Key MEAS_INCOMING_LONGWAVE

If you run for the flat field, and you have measured surface temperature available, you can use the measured surface temperature as the upper boundary condition for the temperature (CHANGE_BC = TRUE). Then, you would not need ILWR (which is notoriously difficult to get right, because of expensive instrumentation, or biases in generated/modelled ILWR from NWP). In this case, even if you would provide ILWR, it wouldn't impact the simulated temperature profile, because it is determined by the snow surface temperature. However, in virtual slopes, this approach cannot be used, since measured surface temperature is NOT available, and thus, ILWR would be needed. Classically, this has been solved in SNOWPACK by implementing an estimation of ILWR by closing the energy balance. This means: estimating the ILWR that would be required to match all the energy fluxes given the snow surface temperature. This is what is done when MEAS_INCOMING_LONGWAVE = FALSE. However, in the melt phase, this creates problems because TSS cannot be used any longer, and closing the energy balance is also not accurate (because of the phase transitions). This is typically noticeable by north-facing virtual slopes having slow melt, and sometimes forming glaciers (not disappearing over summer at all).

However, when you have measured ILWR, or you have ILWR from a weather model, then you could tell SNOWPACK to use this value for virtual slopes as well, by setting MEAS_INCOMING_LONGWAVE = TRUE.

Change as of commit 5e31986d82101f3863ef1d18e157c7c395bced29 on Nov. 20, 2024: Thus far, this only worked when ILWR as provided in the input, either in the smet file, or by using a generator from MeteoIO. If the latter was used without available ISWR, SNOWPACK would run its own ILWR generator. Crucially here is that this step cannot be done as a pre-processing step, since when ISWR is not available, RSWR should be, but in order to calculate ISWR and cloudiness, etc., snow albedo must be known. We all know that snow albedo is not constant in time, thus this approach moves the generation of ILWR inside SNOWPACK, when albedo is known. However, if you were not using an explicitly defined generator, but relying on SNOWPACK's internal ILWR generator, the key didn't have the same effect. I changed this behavior, because I think it is very useful. My feeling is that it generally provides more accurate simulations of virtual slopes to use a generated ILWR, than to use the closure of the energy balance method. I did not want to completely remove that functionality, but now I make MEAS_INCOMING_LONGWAVE = TRUE the default option. On top of that, MEAS_INCOMING_LONGWAVE = TRUE works for both ILWR provided, as well as SNOWPACK's internally generated ILWR.

Conclusion: if you have measured ILWR, or a reliable source of ILWR from for example a NWP model, it makes sense to set key MEAS_INCOMING_LONGWAVE = TRUE. Setting it to false would only make sense if you have measured TSS, and set CHANGE_BC = TRUE. If you generate ILWR either using MeteoIO directly, or using SNOWPACKs internal call to MeteoIO, it likely is also the best choice.

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.