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/722Snowpack output to file2021-01-06T12:22:03ZAdrien MichelSnowpack output to fileSince the last version of the dev (I would not be able to say which one exactly) a strange effect has appeared with outputs :
If output is directly printed to terminal, it is fine. But if output is printed to a file, some of the output d...Since the last version of the dev (I would not be able to say which one exactly) a strange effect has appeared with outputs :
If output is directly printed to terminal, it is fine. But if output is printed to a file, some of the output do not appear (e.g. some from prn_msg from CanopyData::initialize in DataClass.cc) and the lines are note anymore printed one by one to the files, the new lines rather appear suddenly as huge chunks after a few minutes.
This has been observed both on Linux and MacOS, something is probably wrong somewhere.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/472snow precipitation rate is not written in the .met output files2015-08-17T16:57:23ZMathias Bavaysnow precipitation rate is not written in the .met output files**This issue was reported by Isabelle igouttevin.**
*** Steps to reproduce the problem:
run a very standard simulation and look at the MeteoInput/Precipitations/Snow & Rain tab in sngui.
*** Expected result:
there is some snowfall in ...**This issue was reported by Isabelle igouttevin.**
*** Steps to reproduce the problem:
run a very standard simulation and look at the MeteoInput/Precipitations/Snow & Rain tab in sngui.
*** Expected result:
there is some snowfall in winter...
*** Actual result:
winter snowfall is not plotted and only rain can be seen.
*** Proposed Solution :
It seems there is a very simple way to fix this (see hereafter) but it should be evaluated by someone more experienced on the many model variables that could be affected !
add ""Sdata.mass[SurfaceFluxes::MS_HNW] += precip_snow;"" after line 1424 in Snowpack.cc, rev. 779 (trunk). See file attached.
**Attachment**:
* [Snowpack.cc](/uploads/925b8bec62e22c03f78adfc8e134ccfa/Snowpack.cc)https://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/291SNO file puts SMETIO into an infinite loop2013-02-15T18:37:00ZMathias BavaySNO file puts SMETIO into an infinite loop**This issue was reported by Till Schumann.**
When using the SMET formatted snow file attached here below, snowpack gets trapped in an infinite loop. After investigations in Kdbg, this happens in SMETReader::read_data_ascii:1056 : all l...**This issue was reported by Till Schumann.**
When using the SMET formatted snow file attached here below, snowpack gets trapped in an infinite loop. After investigations in Kdbg, this happens in SMETReader::read_data_ascii:1056 : all lines that are returned by getline are empty, therefore the line counter is incremented, no line is processed and it never gets out of the loop.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/278Move INCOMING_LONGWAVE to SnowpackAdvanced section2012-12-03T17:44:15ZFierzMove INCOMING_LONGWAVE to SnowpackAdvanced sectionincoming_longwave is nowadays only used to check whether measured longwave is available in virtual slopes (Main.cc:555-556)
Accordingly, this switch MUST be moved to the SnowpackAdvanced section. It may be also envisaged to replace it f...incoming_longwave is nowadays only used to check whether measured longwave is available in virtual slopes (Main.cc:555-556)
Accordingly, this switch MUST be moved to the SnowpackAdvanced section. It may be also envisaged to replace it fully if other checks may do the job.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/165valgrind error message2011-10-14T13:38:37ZFierzvalgrind error messageVery often, Valgrind gives this kind of message:
==11111== Use of uninitialised value of size 4
==11111== at 0x5FE398C: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) (in /usr/lib/libstdc++.so.6.0.13)
==11111==...Very often, Valgrind gives this kind of message:
==11111== Use of uninitialised value of size 4
==11111== at 0x5FE398C: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) (in /usr/lib/libstdc++.so.6.0.13)
==11111== by 0x5FE47AC: std::string::reserve(unsigned int) (in /usr/lib/libstdc++.so.6.0.13)
==11111== by 0x5FE4A1A: std::string::append(char const*, unsigned int) (in /usr/lib/libstdc++.so.6.0.13)
==11111== by 0x5FE4AE4: std::string::append(char const*) (in /usr/lib/libstdc++.so.6.0.13)
==11111== by 0x806AEE8: std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>,
std::allocator<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*) (basic_string.h:2112)
==11111== by 0x4203648: mio::IOException::IOException(std::string const&, std::string const&) (IOExceptions.cc:41)
==11111== by 0x806E3E6: mio::UnknownValueException::UnknownValueException(std::string const&, std::string const&) (IOExceptions.h:150)
==11111== by 0x8070286: void mio::IOUtils::getValueForKey<std::string>(std::map<std::string, std::string, std::less<std::string>, std::allo
cator<std::pair<std::string const, std::string> > > const&, std::string const&, std::string&, unsigned int const&) (IOUtils.h:253)
==11111== by 0x8071E01: void mio::Config::getValue<std::string>(std::string const&, std::string const&, std::string&, mio::Config::Options
const&) const (Config.h:239)
==11111== by 0x4095178: SnowpackConfig::SnowpackConfig(std::string const&) (SnowpackConfig.cc:119)
==11111== by 0x805E139: main (Main.cc:670)
==11111== Uninitialised value was created by a heap allocation
==11111== at 0x4023F7E: malloc (vg_replace_malloc.c:236)
==11111== by 0x61687A1: backtrace_symbols (backtracesyms.c:72)
==11111== by 0x42035BA: mio::IOException::IOException(std::string const&, std::string const&) (IOExceptions.cc:38)
==11111== by 0x806E3E6: mio::UnknownValueException::UnknownValueException(std::string const&, std::string const&) (IOExceptions.h:150)
==11111== by 0x8070286: void mio::IOUtils::getValueForKey<std::string>(std::map<std::string, std::string, std::less<std::string>, std::allo
cator<std::pair<std::string const, std::string> > > const&, std::string const&, std::string&, unsigned int const&) (IOUtils.h:253)
==11111== by 0x8071E01: void mio::Config::getValue<std::string>(std::string const&, std::string const&, std::string&, mio::Config::Options
const&) const (Config.h:239)
==11111== by 0x4095178: SnowpackConfig::SnowpackConfig(std::string const&) (SnowpackConfig.cc:119)
==11111== by 0x805E139: main (Main.cc:670)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 ISSW08https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/122Settlement2013-01-04T16:07:10ZFierzSettlementRevision 56 is ready to use the new settlement scheme. A last effort is required for Antarctic settlement thoughRevision 56 is ready to use the new settlement scheme. A last effort is required for Antarctic settlement though