snowpack issueshttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues2021-01-13T15:25:53Zhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/864Support older versions of osX2021-01-13T15:25:53ZMathias BavaySupport older versions of osXMac binaries have been produced with Catalina and do not work anymore on High Sierra. The solution would be to specify MACOSX_DEPLOYMENT_TARGET to a lower version of osX (High Sierra is probably a good target for now). See https://cmake....Mac binaries have been produced with Catalina and do not work anymore on High Sierra. The solution would be to specify MACOSX_DEPLOYMENT_TARGET to a lower version of osX (High Sierra is probably a good target for now). See https://cmake.org/cmake/help/latest/envvar/MACOSX_DEPLOYMENT_TARGET.htmlhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/788Improper treatment of *SMET in SNOWPACK - ILWR not consistent in virtual slop...2020-03-04T08:46:14ZMathias BavayImproper treatment of *SMET in SNOWPACK - ILWR not consistent in virtual slope simulations**This issue was reported by Bettina Richter.**
Steps to reproduce the problem:
1. Perform slope simulation with SNOWPACK
2. io.ini:
No special commands:
Flat field uses measured ILWR
Slope does not use ILWR
3. io.ini:
[SnowpackAdvan...**This issue was reported by Bettina Richter.**
Steps to reproduce the problem:
1. Perform slope simulation with SNOWPACK
2. io.ini:
No special commands:
Flat field uses measured ILWR
Slope does not use ILWR
3. io.ini:
[SnowpackAdvanced]
MEAS_INCOMING_LONGWAVE=True
-> ILWR is used for both, flat field and slope
4. io.ini:
[SnowpackAdvanced]
MEAS_INCOMING_LONGWAVE=False
-> ILWR is used for flat field
-> ILWR is not used for slope
4. io.ini:
[SnowpackAdvanced]
MEAS_INCOMING_LONGWAVE=False
[Input]
*::EXCLUDE = ILWR
-> ILWR is not used for flat field
-> ILWR is not used for slope
5. This should be standardized, since it is not in line with the an Alpine3D simulation using the same input and values in io.inihttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/787Improper treatment of *SMET in SNOWPACK - PSUM scales with window size and ac...2019-10-22T12:57:03ZMathias BavayImproper treatment of *SMET in SNOWPACK - PSUM scales with window size and accumulation period of 1D interpolation**This issue was reported by Bettina Richter.**
PSUM input will be scaled with windowsize for 1D interpolation and accumulation period in SNOWPACK
Steps to reproduce the problem:
1. Run a simulation with Alpine3D
[Interpolations1D]
WIN...**This issue was reported by Bettina Richter.**
PSUM input will be scaled with windowsize for 1D interpolation and accumulation period in SNOWPACK
Steps to reproduce the problem:
1. Run a simulation with Alpine3D
[Interpolations1D]
WINDOW_SIZE = 86400
PSUM::resample = accumulate
PSUM::accumulate::period = 3600
result: maximum snow height 2m
2. Run the simulation using the same input with SNOWPACK
[Snowpack]
ENFORCED_MEASURED_SNOW_HEIGHTS = FALSE
result: maximum snow height 7m
3. SNOWPACK produces 7meters snow, Alpine3D produces 2m
4. Run SNOWPACK simulation with a different accumulation period:
PSUM::accumulate::period = 900 -> SNOWPACK produces 2m
PSUM::accumulate::period = 1800 -> SNOWPACK produces 4m
WINDOW_SIZE = 43200 -> SNOWPACK also scales PSUM input
Expected result: 2 meters
Actual result: 7 metershttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/758Improper treatment of nodata value in *SMET files2019-07-10T22:38:06ZNander WeverImproper treatment of nodata value in *SMET filesWhen the nodata value specified in a *SMET file is different from -999, and the *SMET file does not explicitly specify slope_angle and slope_azi, the slope angle in SNOWPACK is extreme (-279)!
Steps to reproduce the problem:
1. Consider...When the nodata value specified in a *SMET file is different from -999, and the *SMET file does not explicitly specify slope_angle and slope_azi, the slope angle in SNOWPACK is extreme (-279)!
Steps to reproduce the problem:
1. Consider the res1exp example, the slope angle of a simulation is 0.
2. Change the nodata value in header of input/MST96.smet to -9999
3. Run the simulation again, and verify the output. It is now on an extreme slope!
Actual result:
The header of the *pro file shows:
SlopeAngle= -279.00
SlopeAzi= -279.00
Expected result:
The header of the *.pro file should show:
SlopeAngle= 0.00
SlopeAzi= 0.00https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/612Flexible comb_thresh_l2017-05-02T13:41:14ZNander WeverFlexible comb_thresh_lThe comb_thresh_l is hard-coded in SNOWPACK, thereby limiting the effect of HEIGHT_NEW_ELEM, which can be specified in the ini file:
const double SnowStation::comb_thresh_l = 0.015;
For example, in the ice-layer paper in The Cryosphere,...The comb_thresh_l is hard-coded in SNOWPACK, thereby limiting the effect of HEIGHT_NEW_ELEM, which can be specified in the ini file:
const double SnowStation::comb_thresh_l = 0.015;
For example, in the ice-layer paper in The Cryosphere, I was using high resolution simulations, in which case I had to adjust both the ini file and the source code, in order to maintain high vertical resolution. Of course, I could also have set COMBINE_ELEMENTS to false in the ini-file, but that was increasing the computational load for the dual domain approach, without additional improvement in simulation accuracy. Optimal setting was achieved by modifying comb_thresh_l in the source code.
My suggestion would be that either:
- comb_thresh_l becomes a key in ini file
- or the source code specifies a fixed ratio between HEIGHT_NEW_ELEM and comb_thresh_l, such that the latter is scaled according to the prescribed HEIGHT_NEW_ELEM.
Any (other) ideas?https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/601Soil, no geo_heat, no TSG2017-04-03T15:36:10ZMathias BavaySoil, no geo_heat, no TSGWhen running with soil, but no geothermal heat flux and no lower temperature, the simulation should not run (it currently does run but uses geo_heat=Cst::undefined, so a strongly negative heat flux).
SNP_SOIL = TRUE
SOIL_FLUX = FALSE
;G...When running with soil, but no geothermal heat flux and no lower temperature, the simulation should not run (it currently does run but uses geo_heat=Cst::undefined, so a strongly negative heat flux).
SNP_SOIL = TRUE
SOIL_FLUX = FALSE
;GEO_HEAT = 0.06https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/570Companion keys to PROF_ and TS_START2017-03-16T10:40:26ZFierzCompanion keys to PROF_ and TS_STARTSteps to reproduce the problem:
1. In INIshell set any of PROF_WRITE or TS_WRITE to FALSE
2. No companion keys (TS_START, TS_DAYS_BETWEEN, etc.) are written in io.ini, which is a correct behaviour
Expected result: No trouble
Actual res...Steps to reproduce the problem:
1. In INIshell set any of PROF_WRITE or TS_WRITE to FALSE
2. No companion keys (TS_START, TS_DAYS_BETWEEN, etc.) are written in io.ini, which is a correct behaviour
Expected result: No trouble
Actual result: SNOWPACK quits because it expects these companion keys to be defined ...
Note: I proposed a working(?) work around in Main.cc (rev 1108 I believe)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/568Some I/O issues (a) writing smet files2017-03-16T10:50:34ZFierzSome I/O issues (a) writing smet filesSteps to reproduce the problem:
1. run 'virgin' snowpack (no output files exist yet)
2. output smet file does contain only last timestamp of run
3. re-run with same settings: smet file is now complete
Expected result: complete smet file...Steps to reproduce the problem:
1. run 'virgin' snowpack (no output files exist yet)
2. output smet file does contain only last timestamp of run
3. re-run with same settings: smet file is now complete
Expected result: complete smet file after first run
Note: Behaviour also observed with usual time steps of 1 h
However, when using 1 min output time steps, strange behaviour appears: First time step is doubled in *.pro and *.met files ...https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/556Snowpack::compSnowForces never called2016-07-08T14:19:22ZNander WeverSnowpack::compSnowForces never calledThere is no function call to Snowpack::compSnowForces. So it seems to be an old relic. Maybe it would be good if the comments in the function reflect that it is an abandoned approach and why it is abandoned.There is no function call to Snowpack::compSnowForces. So it seems to be an old relic. Maybe it would be good if the comments in the function reflect that it is an abandoned approach and why it is abandoned.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/553Option to write out filtered SMET2016-07-08T12:34:16ZMathias BavayOption to write out filtered SMETIn order to help users working with fishy data, it would be helpful to have a key that would trigger the writing out of a SMET data containing the forcing as it has been received from MeteoIO. This could then be explained in the document...In order to help users working with fishy data, it would be helpful to have a key that would trigger the writing out of a SMET data containing the forcing as it has been received from MeteoIO. This could then be explained in the documentation (showing how MeteoIO processes the data before it enters Snowpack Core) and how to plot it with snopviz.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/551snowpack doesn't compile with Lapack2016-05-18T13:12:02ZNander Weversnowpack doesn't compile with LapackSince the latest changes to the CMakeLists in commit 1009, SNOWPACK doesn't compile with Lapack anymore on my computer:
[ 95%] Built target snowpack
Linking CXX executable ../../bin/snowpack
../../lib/libsnowpack.so.3.3.0: undefined ref...Since the latest changes to the CMakeLists in commit 1009, SNOWPACK doesn't compile with Lapack anymore on my computer:
[ 95%] Built target snowpack
Linking CXX executable ../../bin/snowpack
../../lib/libsnowpack.so.3.3.0: undefined reference to `_gfortran_concat_string'
../../lib/libsnowpack.so.3.3.0: undefined reference to `_gfortran_st_write_done'
../../lib/libsnowpack.so.3.3.0: undefined reference to `_gfortran_pow_i4_i4'
../../lib/libsnowpack.so.3.3.0: undefined reference to `_gfortran_string_len_trim'
../../lib/libsnowpack.so.3.3.0: undefined reference to `_gfortran_st_write'
../../lib/libsnowpack.so.3.3.0: undefined reference to `_gfortran_transfer_integer_write'
../../lib/libsnowpack.so.3.3.0: undefined reference to `_gfortran_compare_string'
../../lib/libsnowpack.so.3.3.0: undefined reference to `_gfortran_transfer_character_write'
../../lib/libsnowpack.so.3.3.0: undefined reference to `_gfortran_stop_string'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/snowpack] Error 1
make[1]: *** [applications/snowpack/CMakeFiles/snowpack.app.dir/all] Error 2
make: *** [all] Error 2
Reverting the changes done in commit 1009 solve the problem, indicating that the problem is caused by commit 1009.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/550Precipitation reaccumulation2016-05-30T09:14:26ZMathias BavayPrecipitation reaccumulationSince many users forget to use an ""accumulate"" ressampling method on their precip, we could test for this key and produce a warning if it is not present (""this is probably an error"")Since many users forget to use an ""accumulate"" ressampling method on their precip, we could test for this key and produce a warning if it is not present (""this is probably an error"")https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/531Inconsistent code in Laws_sn.cc2017-03-23T19:40:36ZNander WeverInconsistent code in Laws_sn.ccIn the comments, Laws_sn.cc: L68-L71, the options 1, 0, and -1 are given:
* - 1 ==> Resistance Approach, see Laws_sn.c
* - 0 ==> Relative Humidity Approach, see Snowpack.cc
* - -1 ==> none, assume saturation pressure and no extra resi...In the comments, Laws_sn.cc: L68-L71, the options 1, 0, and -1 are given:
* - 1 ==> Resistance Approach, see Laws_sn.c
* - 0 ==> Relative Humidity Approach, see Snowpack.cc
* - -1 ==> none, assume saturation pressure and no extra resistance
In L73, the variable is defined as bool:
const bool SnLaws::soil_evaporation = true;
Whereas in L900 the variable is compared against 1:
(SnLaws::soil_evaporation == 1)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/491pro-file format causing syntaxis errors in sngui2021-01-13T15:34:25ZNander Weverpro-file format causing syntaxis errors in snguiThe new file format of the pro-files, by including the nodal data lines (""1nnn""), is causing syntax errors in SN_GUI.
""Line 1157523>>>ERR_LINE_SYNTAX 3, ProDataEntry.ParseDataLine""
Maybe make the nodal data lines (labelled ""1nnn""...The new file format of the pro-files, by including the nodal data lines (""1nnn""), is causing syntax errors in SN_GUI.
""Line 1157523>>>ERR_LINE_SYNTAX 3, ProDataEntry.ParseDataLine""
Maybe make the nodal data lines (labelled ""1nnn"") in agreement with the data format for SN_GUI, or make output of these variables dependent on a switch that can be set in the ini-file?https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/471Richards equation and canopy2017-03-23T19:54:41ZNander WeverRichards equation and canopyCombining Richards equation and the canopy module is not behaving stably under all circumstances.
The problem is that the transpiration is reducing the soil water content without taking into account the water retention curves, causing n...Combining Richards equation and the canopy module is not behaving stably under all circumstances.
The problem is that the transpiration is reducing the soil water content without taking into account the water retention curves, causing numerical problems when solving richards equation.
A solution is feasible, but requires some programmig. One solution is to apply the transpiration as a flux, with the disadvantage of loosing the different root depths from wich water is taken up by roots. But it probably is the fastest thing to program.
Another solution (and the most realistic one) is to use the source/sink term in Richards equation to deal with the transpiration.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/470Adaptive time stepping and canopy module2015-08-11T12:00:41ZNander WeverAdaptive time stepping and canopy moduleThe adaptive time stepping doesn't play well with the canopy module. The problem is that the canopy module is reading the SNOWPACK time step from the configuration object, although the time step may be temporarily reduced in Snowpack.cc....The adaptive time stepping doesn't play well with the canopy module. The problem is that the canopy module is reading the SNOWPACK time step from the configuration object, although the time step may be temporarily reduced in Snowpack.cc. Another issue is that the canopy module is tightly linked to the meteo object, but with adaptive time stepping, the meteo object is called more frequently and possibly more than once during one time step, although the canopy module assumes to be only called once during a time step.
Among the many possible solution, I think the most reasonable way forward is to call the canopy module separately from Snowpack.cc (similar to WaterTransport, SnowCreep, Microstructure, etc), without the nesting in the Meteo object. I don't see the reason for how it is done now anyway. Possibly, some variables from the meteo object are required, but this can be dealt with easily.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/426Support precipitation phase2015-12-04T18:52:12ZMathias BavaySupport precipitation phaseCurrently in Snowpack-dev, we have three ways (+HS) to provide precipitation input. This should be replaced by HNW and the precipitation phase because the current situation leads to numerous bugs (the conditions for testing if there is l...Currently in Snowpack-dev, we have three ways (+HS) to provide precipitation input. This should be replaced by HNW and the precipitation phase because the current situation leads to numerous bugs (the conditions for testing if there is liquid or solid precipitation are now way too complex).https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/416SMET output2017-03-16T11:22:34ZMathias BavaySMET outputA new plugin should be implemented to output the current "".met"" content as SMET. Then SnopViz will be able to display these files with the SMET parser.A new plugin should be implemented to output the current "".met"" content as SMET. Then SnopViz will be able to display these files with the SMET parser.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/414very wrong snow or soil temperatures2015-12-04T18:53:16ZMathias Bavayvery wrong snow or soil temperaturesIn some simulations, at some time steps, the following problems are experienced:
* snow element temperatures above 0C
* very cold snow temperatures
* very cold soil temperatures or very hot soil temperatures
These issues have been exper...In some simulations, at some time steps, the following problems are experienced:
* snow element temperatures above 0C
* very cold snow temperatures
* very cold soil temperatures or very hot soil temperatures
These issues have been experienced by several users with the current SVN version and are making very severe trouble with Alpine3D.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/390SNOWPACK doesn't read in snoold files anymore2014-10-08T10:23:51ZNander WeverSNOWPACK doesn't read in snoold files anymoreSince the latest revisions, SNOWPACK doesn't read in snoold files anymore, even with SNOW = SNOWPACK set in the [Output] section of the ini-file.Since the latest revisions, SNOWPACK doesn't read in snoold files anymore, even with SNOW = SNOWPACK set in the [Output] section of the ini-file.