snowpack issueshttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues2022-01-10T12:52:40Zhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/868Inner computation of longwaves2022-01-10T12:52:40ZAdrien MichelInner computation of longwavesMathias had made some recent update of the LW computation in meteoio (see https://gitlabext.wsl.ch/snow-models/meteoio/-/commit/b65cc357bd18958450f2cacbda3fd176fed70e56).
I recently was surprised to realize that snowpack runs smoothly w...Mathias had made some recent update of the LW computation in meteoio (see https://gitlabext.wsl.ch/snow-models/meteoio/-/commit/b65cc357bd18958450f2cacbda3fd176fed70e56).
I recently was surprised to realize that snowpack runs smoothly when no LW are provided. Indeed, in Laws_cn.cc:1591:
```
/**
* @brief Compute the air emissivity
* It relies on mio::ILWR_parametrized to get a parametrized ILWR if no measured ILWR is available.
* This in turn relies either on Brutsaert (clear sky) or Omstedt (cloudiness) or Crawford(cloudiness from ISWR).
* The air temperature and relative humidity should be available for meanigful results.
* In any case, the returned air emissivity will be between min_air_emissivity and 1, min_air_emissivity depending
* on the variant.
* @param md meteorological conditions
* @param variant variant to use for the minimum allowed air emissivity
* @note observed minimum air emissivities:
* - default: 0.55 (from 1993 data at Weissfluhjoch)
* - Antarctica: 0.31 (from 2006/2007 data of Dome C)
* @return air emissivity in range [MIN_AIR_EMISSIVITY,1.] (1)
*/
double SnLaws::AirEmissivity(mio::MeteoData& md, const std::string& variant)
{
const double ILWR = (md(MeteoData::ILWR)>1.)? md(MeteoData::ILWR) : IOUtils::nodata;
if (ILWR!=IOUtils::nodata)
return AirEmissivity(ILWR, md(MeteoData::TA), variant);
else {
const double cloudiness = (md(MeteoData::ILWR)>0. && md(MeteoData::ILWR)<=1.)? md(MeteoData::ILWR) : IOUtils::nodata;
const double ilwr_p = Atmosphere::ILWR_parametrized(md.meta.position.getLat(), md.meta.position.getLon(), md.meta.position.getAltitude(),
md.date.getJulian(), md.date.getTimeZone(),
md(MeteoData::RH), md(MeteoData::TA), md(MeteoData::ISWR), cloudiness);
return AirEmissivity(ilwr_p, md(MeteoData::TA), variant);
}
}
```
Atmosphere::ILWR_parametrized ia a MIO function whihc is never called in MIO, meaning that it is not used in MIO to generate ILWR. Indeed this functions ignores any parameters provided for LW generation in the ini file.
1. I think this behaviour in Swnopack is not wanted and dangerous. I would recommend to remove this automatic generation of ILWR in Snowpack and force the user to properly parameterize a LW generator through MIO, this is more transparent and ensure to use the latest and updated version of the generator. We can provide an error message indicating to the user how to generate LW if missing. In the current implementation, snowpack will switch between generators depending on the available data at each timestep, and the user has no idea about it
2. I would remove Atmosphere::ILWR_parametrized from MIO since it seems to be used only for this call in Snowpack
3. On the same topic, Varun realized that emissivity is capped to 1 (see SnLaws::AirEmissivity), which physically makes sense, but when we provide measured values that we "trust" we do not want snowpack to play with it. also, we use TA, which is a rough approximation to compute LW, so maybe those checks should be removed. I never understood anyway why we go from LW to ea to go back to LW. (In Snowpack::neumannBoundaryConditions we go back to LW here: `Fe[1] += delta * pow( Mdata.ea, 0.25 ) * T_air;`). So can't we simply always work with LW? We also save some power 0.25 operations, which are really expensive.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/798enforced_measured_snow_height not always enforced2019-11-07T17:55:05ZMathias Bavayenforced_measured_snow_height not always enforcedIn this attached simulation, the measured snow height increments do not always lead to precipitation in Snowpack (both the the trunk and dev versions), despite high relative humidity, TA<0 and low radiation (there is no TSS but even gene...In this attached simulation, the measured snow height increments do not always lead to precipitation in Snowpack (both the the trunk and dev versions), despite high relative humidity, TA<0 and low radiation (there is no TSS but even generating TSS as TA-2.5 did not change anything).
**Attachments**:
* [io_shin2017sp.ini](/uploads/e82d7a883a1734195b5cc1e18ba4855e/io_shin2017sp.ini)
* [shin2017sp.smet](/uploads/f211da3badf30c52c355d5ebd1d0c7c3/shin2017sp.smet)
* [shin2017sp.sno](/uploads/32f19e07a9c0fc85756790613ccf4875/shin2017sp.sno)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/747Steep slope snow catching capacity2019-01-16T13:24:17ZMathias BavaySteep slope snow catching capacityWhen modeling ground temperatures in steep slopes, there is the problem that too much snow is simulated on the slope. This is because in real slopes, some of the snow would fall off. A possibility to simulate this behavior would be to at...When modeling ground temperatures in steep slopes, there is the problem that too much snow is simulated on the slope. This is because in real slopes, some of the snow would fall off. A possibility to simulate this behavior would be to attribute a maximum catching capacity to the slope, for example depending on the roughness of the slope. Once this maximum capacity has been reached, all new snow coming would simply be discarded (of course, this should not be used in Alpine3D where the mass should instead be redistributed).https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/688VW_MAX set to VW in Snowpack outputs2018-06-05T13:08:23ZMathias BavayVW_MAX set to VW in Snowpack outputsWhen providing VW_MAX and VW to Snowpack, VW_MAX gets set to the same values as VW in the outputs.When providing VW_MAX and VW to Snowpack, VW_MAX gets set to the same values as VW in the outputs.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/674Hand hardness & melt forms2018-04-04T16:11:23ZMathias BavayHand hardness & melt formsOnce a layer has reached ""melt forms"", it seems that its hardness remains 5 until liquid water percolates to the element. In the code, it should not be so... (see for example the station *CDF1 for Winter 2018)Once a layer has reached ""melt forms"", it seems that its hardness remains 5 until liquid water percolates to the element. In the code, it should not be so... (see for example the station *CDF1 for Winter 2018)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/593surface fluxes without layers2017-01-27T09:11:34ZMathias Bavaysurface fluxes without layersCurrently, when there are no layers left (ie simulation without soil and no more snow), the surface fluxes (for example Sdata.qs) will be printed out with wrong values (often a few thousands).
In order to improve these outputs, we shou...Currently, when there are no layers left (ie simulation without soil and no more snow), the surface fluxes (for example Sdata.qs) will be printed out with wrong values (often a few thousands).
In order to improve these outputs, we should set the fluxes to nodata (or undefined) in SurfaceFluxes::collectSurfaceFluxes() and properly handle the averaging that happens later.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/591HN24, PSUM24, etc2016-12-19T09:50:21ZMathias BavayHN24, PSUM24, etcAccumulated parameters such as the 24 hours new snow height, 72 hours new snow height, 24 hours precipitation, etc are corrupted when using a CALCULATION_STEP_LENGTH different than 15 minutes. The code that generates these parameters (bo...Accumulated parameters such as the 24 hours new snow height, 72 hours new snow height, 24 hours precipitation, etc are corrupted when using a CALCULATION_STEP_LENGTH different than 15 minutes. The code that generates these parameters (both for the .haz and for these parameters in the .met) assumes that 15 minutes timesteps are used.
Unfortunately, the required changes are a little too widespread to fix this bug before the next release. It is therefore delayed until after the upcoming release.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/539Ugly Hack for .pro files2016-04-05T13:10:49ZMathias BavayUgly Hack for .pro filesThe first header line that contains the date and the user name that ran Snowpack is only written out when out_haz==true. This was to avoid troubles with Alpine3D but this also makes the files different in pure Snowpack simulations depend...The first header line that contains the date and the user name that ran Snowpack is only written out when out_haz==true. This was to avoid troubles with Alpine3D but this also makes the files different in pure Snowpack simulations depending on the out_haz user key...https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/501NIED Water transport routine obsolete2015-12-23T08:54:48ZFierzNIED Water transport routine obsoleteThe NIED Water Transport routine is obsolete.
Switch and routine should be taken out of the codeThe NIED Water Transport routine is obsolete.
Switch and routine should be taken out of the codehttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/469New stability index from Fabiano2016-03-29T16:57:17ZMathias BavayNew stability index from FabianoIntegrate Fabiano's stability index into Snowpack. For more flexibility, setup an object factory controlled by config keys to choose the stability index (such as sk38, etc) as well as the structural stability (such as relative threshold ...Integrate Fabiano's stability index into Snowpack. For more flexibility, setup an object factory controlled by config keys to choose the stability index (such as sk38, etc) as well as the structural stability (such as relative threshold approach). It could also be possible to add the stability classification (combination of the two or even of a third one).
**Attachments**:
* [SSSi_calc_REV.R](/uploads/2a38c89137a6025ca4f4c5ced4210175/SSSi_calc_REV.R)
* [RDA_index_simulated_profiles.R](/uploads/685eca68e2cf3cfdb9922c780e462cbb/RDA_index_simulated_profiles.R)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/417Adapt PRO format2023-05-05T14:47:20ZMathias BavayAdapt PRO formatSurface hoar should now be handled as extra layer in order to be ""compatible"" with CAAML and SnopViz.Surface hoar should now be handled as extra layer in order to be ""compatible"" with CAAML and SnopViz.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/123Radiation absorption2011-02-01T17:07:16ZFierzRadiation absorptionThe radiation absorption scheme has to be updated => see ISSW08The radiation absorption scheme has to be updated => see ISSW08