snowpack issueshttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues2013-01-04T16:07:10Zhttps://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 thoughhttps://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/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/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/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/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.