snowpack issueshttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues2018-09-20T15:38:03Zhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/719Runoff unit in output .smet file2018-09-20T15:38:03ZMathias BavayRunoff unit in output .smet file**This issue was reported by Louis Quéno.**
When AVGSUM_TIME_SERIES is set to TRUE (default value), the runoff (MS_SN_Runoff) in the output smet file is expressed in kg/m2/TS_DAYS_BETWEEN (time step chosen for the smet output), and not ...**This issue was reported by Louis Quéno.**
When AVGSUM_TIME_SERIES is set to TRUE (default value), the runoff (MS_SN_Runoff) in the output smet file is expressed in kg/m2/TS_DAYS_BETWEEN (time step chosen for the smet output), and not in kg/m2/h as said in the header.
When AVGSUM_TIME_SERIES is set to FALSE, it is expressed in kg/m2/CALCULATION_STEP_LENGTH.
The units header could thus be misleading. This is probably the case for other fluxes.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/718Classify grain types according to ICSSG2018-09-12T17:21:16ZMathias BavayClassify grain types according to ICSSG**This issue was reported by Simon Horton.**
Are there any internal routines to classify grain types according to the international classification instead of the old-fashion Swiss codes? This would be more convenient than post-processing.**This issue was reported by Simon Horton.**
Are there any internal routines to classify grain types according to the international classification instead of the old-fashion Swiss codes? This would be more convenient than post-processing.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/700HAZARD_WRITE option to supress hazard writing hazard data2018-07-13T19:39:07ZMathias BavayHAZARD_WRITE option to supress hazard writing hazard data**This issue was reported by Simon Horton.**
Why are .haz files the only output format that are not optional? I usually make a hack to the code to suppress them or just delete these files after running the model. A config file option wo...**This issue was reported by Simon Horton.**
Why are .haz files the only output format that are not optional? I usually make a hack to the code to suppress them or just delete these files after running the model. A config file option would be cleaner.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/698Exception at one station kills app2018-06-27T22:45:24ZMathias BavayException at one station kills app**This issue was reported by Simon Horton.**
Steps to reproduce the problem:
1. Have multiple stations in an ini file
2. Run snowpack app
3. One station has some type of issue that causes an exception (e.g. missing value, crazy temp, et...**This issue was reported by Simon Horton.**
Steps to reproduce the problem:
1. Have multiple stations in an ini file
2. Run snowpack app
3. One station has some type of issue that causes an exception (e.g. missing value, crazy temp, etc.)
Expected result: The app moves on to the next station
Actual result: Program aborts after the exceptionhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/644FORCE_SW_MODE Issue2019-03-04T13:00:15ZAdrien MichelFORCE_SW_MODE IssueI compared the meteo input given as input, the processed meteo outputted by snowpack (i.e. the meteoio processed values) and the meteo outputed by snowpack (the met file that should be the values actually used for the computation).
I di...I compared the meteo input given as input, the processed meteo outputted by snowpack (i.e. the meteoio processed values) and the meteo outputed by snowpack (the met file that should be the values actually used for the computation).
I did not find any difference between the input meteo and the mio processed meteo (except what we expect for the used filters).
Regarding the outputted ISWR in the met file, I found a significant difference with respect to the input meteo data.
You have two plots in attachment, one for Bern with my data, one for Grossalp with Nander's data. The only difference is Nander's data contain TSS, which Bern data does not.
One the first page of these pdf, you can see the difference in ISWR over few years simulation period and the mean of this difference. We observe that in Grossalp the is no problem during winter.
In the next plots you see the two times series for some particular weeks and months of the year 2011, we see that :
- The met ISWR suddenly jumps from measurements to a nice sinus curve, explaining the added ISWR
- The fact that the is no issue in Grossalp during winter suggests that when there is snow there is no issue. However, in the week/month plot I also plotted the snow height (scaled to fit) and we see that this is not always the case. The problem might occur when there is snow (see Bern 20-21 jan) and inversely. Maybe it is related to the jumps in boundary conditions.
I made also several tests with/without canopy, the effect is still here. The bucket/richards choice makes also, as expected no, difference.
I made tests with alpine 3D output, and it looks like there is no issue in A3D.
Michi had a look to the source code, and one guess is that it maybe comes from the SurfacesFluxes Sdata object used in AsciiIo::writeTimeSeries method, so it is perhaps only an output issue (but in this case why we do not have this issue in A3D? doesn't' it use snowpack io module to write met files?)
Finally, note that I did not get any warning during the runs and I used LAPACK on MacOS.
**Attachments**:
* [ISWR_ISSUE_BER_STD_SOIL.pdf](/uploads/2a4d5eb4f5231e09559ebdc8db6c953a/ISWR_ISSUE_BER_STD_SOIL.pdf)
* [ISWR_ISSUE_GROSSALP.pdf](/uploads/ed2e17ec0c35ab660e289c4b0c18fef2/ISWR_ISSUE_GROSSALP.pdf)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/624Caaml xsd2017-07-13T12:29:54ZMathias BavayCaaml xsdSnowpack produced caaml files should come with an xsd...Snowpack produced caaml files should come with an xsd...https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/606Refactoring Richards equation code2017-05-19T11:56:07ZNander WeverRefactoring Richards equation codeHere, I document steps I need to take to refactor ReSolver1d.cc.
- The van genuchten class needs a
std::iostream& operator<<(std::iostream& os, const ElementData& data) and the Edata operator << needs to be adjustedHere, I document steps I need to take to refactor ReSolver1d.cc.
- The van genuchten class needs a
std::iostream& operator<<(std::iostream& os, const ElementData& data) and the Edata operator << needs to be adjustedhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/569Some I/O issues (b) writing forcing data2016-08-15T12:07:46ZFierzSome I/O issues (b) writing forcing dataSteps to reproduce the problem:
1. Use ""-e NOW"" and ask for writing a smet file of forcing data
Expected result: Final time step corresponding to last input time step
Actual result: Last time step is today's date. Creates huge files ...Steps to reproduce the problem:
1. Use ""-e NOW"" and ask for writing a smet file of forcing data
Expected result: Final time step corresponding to last input time step
Actual result: Last time step is today's date. Creates huge files hardly loadable by SnopVizhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/567Missing MeteoData::DW2016-11-28T17:42:01ZFierzMissing MeteoData::DWSee Main.cc:359
if (md(MeteoData::VW) ==mio::IOUtils::nodata || md(MeteoData::DW) ==mio::IOUtils::nodata)
miss_wind=true;
I agree that we check whether DW is missing.
But as DW is not used further in SNOWPACK except to be written out ...See Main.cc:359
if (md(MeteoData::VW) ==mio::IOUtils::nodata || md(MeteoData::DW) ==mio::IOUtils::nodata)
miss_wind=true;
I agree that we check whether DW is missing.
But as DW is not used further in SNOWPACK except to be written out in AsciiIO.cc:1972, SNOWPACK should not be stopped if no DW is found! A warning should suffice and Mdata.dw can be safely set to zero.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/562variants2016-08-16T17:22:46ZMathias BavayvariantsWhen using inishell and selecting a ""variant"", there is no way to see what are the default values for this variant. Since variants are only defined in Snowpack, there is no easy/clean way to implement a proper, user friendly behaviour....When using inishell and selecting a ""variant"", there is no way to see what are the default values for this variant. Since variants are only defined in Snowpack, there is no easy/clean way to implement a proper, user friendly behaviour.
The cleanest solution would be to get rid of the variants and simply add a new documentation page that would list recommended values for specific cases (like Antarctica, Japan...)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/375Energy balance with very shallow snowpacks (<20cm)2014-05-13T10:12:42ZNander WeverEnergy balance with very shallow snowpacks (<20cm)The energy balance improved significantly with commit 571, 572 and 573. However, problems are still present in shallow snow covers (< ca. 20cm). I leave it here now, but as a hint for future development:
The problem is likely related wi...The energy balance improved significantly with commit 571, 572 and 573. However, problems are still present in shallow snow covers (< ca. 20cm). I leave it here now, but as a hint for future development:
The problem is likely related with determining the soil heat flux in combination with penetrating short wave radiation which is absorbed in the top node of the soil. The latter might be considered an energy loss of the snowpack, as it is incoming energy at the surface which is transferred directly to the soil. However, it also influences the gradient in the upper soil layer and thereby the soil energy flux. It's not clear what is the best way to deal with this.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/364Clarification of lower boundary conditions2014-03-06T08:49:58ZFierzClarification of lower boundary conditionsCurrently, with soil, lower Dirichlet boundary conditions can be imposed on the soil/snow column by setting SNP_SOIL=true and SOIL_FLUX=false. Thereby, CurrentMeteo.ts0 is assigned MeteoData::TSG. This procedure is not transparent though...Currently, with soil, lower Dirichlet boundary conditions can be imposed on the soil/snow column by setting SNP_SOIL=true and SOIL_FLUX=false. Thereby, CurrentMeteo.ts0 is assigned MeteoData::TSG. This procedure is not transparent though.
Accordingly, we should aim at having two input fields MeteoData::TB(ase) and MeteoData::TG(round). The prescribed temperature at the base of the snow/soil column would then be given by CurrentMeteo.tb in SNOWPACK (instead of CurrentMeteo.ts0). If both MeteoData::TB and MeteoData::TG are given, we will also have differing CurrentMeteo.tb and CurrentMeteo.tg in SNOWPACK, otherwise these two variables will be equal. Finally, MeteoData::TSG would be dropped [or moved to TGS= temperature ground surface].
Accordingly changes are required in MeteoIO, Alpine3D (3 lines, SnowpackInterfaceWorker), SNOWPACK, and INIshell.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/128Merge elements for A3D2015-06-16T08:29:32ZFierzMerge elements for A3DMerging elements could reduce computation time especially for A3D applications. A suitable scheme should be proposed that does not effect stand alone SNOWPACK simulationsMerging elements could reduce computation time especially for A3D applications. A suitable scheme should be proposed that does not effect stand alone SNOWPACK simulationshttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/125Grain code to be adapted to 2009 classification2015-05-03T18:12:03ZFierzGrain code to be adapted to 2009 classificationNice to have ;-)Nice to have ;-)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/120Drift Index2015-05-03T18:14:53ZFierzDrift IndexWe need to test whether the value for WIND_SLAB_DENSITY is still up to date.
At the same time, the wind scaling factors should be re-computed from sdb.We need to test whether the value for WIND_SLAB_DENSITY is still up to date.
At the same time, the wind scaling factors should be re-computed from sdb.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/739wrong merging of elements (elements over differnt layers are merged)2019-02-11T22:33:53ZMathias Bavaywrong merging of elements (elements over differnt layers are merged)**This issue was reported by Thiemo Theile.**
Steps to reproduce the problem:
1. run snowpack with the attached files (and WFJ_optimaldataset_v7.smet) for one time step: -c iowfjref2.ini -e 2008-05-16T09:00
2. compare the input-caaml an...**This issue was reported by Thiemo Theile.**
Steps to reproduce the problem:
1. run snowpack with the attached files (and WFJ_optimaldataset_v7.smet) for one time step: -c iowfjref2.ini -e 2008-05-16T09:00
2. compare the input-caaml and the output-caaml (for example using niviz.org)
Expected result:
output-caaml should look like the input-caaml
Actual result:
elements from the MF-layer and the RG-layer are merged to a new layer. This should not happen!
I followed the problem up to WaterTransport.cc. If I switch off the function mergingElements (around line 1258), the problem disappears. If I switch off the key ""COMBINE_ELEMENTS"" in [SNOWPACKADVANCED] in the ini-file, the problem remains.
Is there a bug in the function WaterTransport::mergingElements? Is this merging necessary?
**Attachments**:
* [iowfjref2.ini](/uploads/0c54f8727fbfc26dc2a92c4c4c57eacf/iowfjref2.ini)
* [199712310830.SimpleProfile_sdbo.caaml](/uploads/1da252850de3417822cd352c4d93502d/199712310830.SimpleProfile_sdbo.caaml)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/370SkyViewFraction vs DirectThroughFall2014-04-22T10:31:12ZMathias BavaySkyViewFraction vs DirectThroughFall**This issue was reported by Isabelle igouttevin.**
The cn_TotalAlbedo function from Canopy.cc uses ""SkyViewFactor"" as formal parameter. The function is however called with ""Xdata.Cdata.direct_throughfall"" as actual argument. This i...**This issue was reported by Isabelle igouttevin.**
The cn_TotalAlbedo function from Canopy.cc uses ""SkyViewFactor"" as formal parameter. The function is however called with ""Xdata.Cdata.direct_throughfall"" as actual argument. This is in my opinion misleading as physically, SkyViewFactor and direct_throughFall are not equal.
SkyViewFraction is the hemispheric fraction of sky seen from a point on the ground.
DirectThroughFall is the projected fraction of canopy gaps on the ground.
Ref : Jennings et al., 1999; Rasmus et al., 2013.
Therefore I suggest to use a formal parameter called ""DirectThroughFall"" in the cn_TotalAlbedo function.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/333TSG and too few soil layers2013-10-29T19:08:26ZMathias BavayTSG and too few soil layersWhen the user uses TSG as a lower boundary condition, there need to be enough soil layers, otherwise we run into numerical troubles (crazy temperatures, strong variations between time steps, etc).
We should consider warning the user if...When the user uses TSG as a lower boundary condition, there need to be enough soil layers, otherwise we run into numerical troubles (crazy temperatures, strong variations between time steps, etc).
We should consider warning the user if there is not enough soil to dampen the temperature variations (either on number of layers, or soil depth or thermal capacity).https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/281SNO file generator2013-02-21T16:41:20ZMathias BavaySNO file generatorA small Java application able to generate a sno file would be a great help for beginners.A small Java application able to generate a sno file would be a great help for beginners.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/169Snowpack object constructed/destroyed at every time step2011-11-04T19:53:12ZMathias BavaySnowpack object constructed/destroyed at every time stepKeeping a permanent snowpack object through the computation of a virtual slope might be a nice speed improvement. We should look at providing a reset() call (so that Alpine3D could keep the same object for all pixels, but reset it betwee...Keeping a permanent snowpack object through the computation of a virtual slope might be a nice speed improvement. We should look at providing a reset() call (so that Alpine3D could keep the same object for all pixels, but reset it between pixels) and check that no data would have to be deleted between time steps in this object.