snowpack issueshttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues2024-03-26T12:36:48Zhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/889Ski pen in .pro files2024-03-26T12:36:48ZFlorian HerlaSki pen in .pro filesSkier penetration depth is a necessary component in computing Stephie Mayer's p_unstable. It would be great to write it to .pro files, potentially as code 0607.Skier penetration depth is a necessary component in computing Stephie Mayer's p_unstable. It would be great to write it to .pro files, potentially as code 0607.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/888sk38_min always -9992024-01-17T21:47:45ZRueschsk38_min always -999it seems that after a switch from snowpack version commit fcee9f1d -> bf3660a8 we always get sk38_min -999
My guess would be that the change of the initial values in https://gitlabext.wsl.ch/snow-models/snowpack/-/commit/bf3660a8c2acc5eb...it seems that after a switch from snowpack version commit fcee9f1d -> bf3660a8 we always get sk38_min -999
My guess would be that the change of the initial values in https://gitlabext.wsl.ch/snow-models/snowpack/-/commit/bf3660a8c2acc5eb63d03691e6f70539b13c2aef
there could now be a problem by taking the minimum. This was probably the reason why the initial value 999 was used in that case.
@nwever fyihttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/885SNOWPACK can crash with no snow and no soil2023-12-05T15:52:52ZNander WeverSNOWPACK can crash with no snow and no soilSNOWPACK can crash in WaterTransport::compTopFlux if there is no soil, and no snow (i.e., nE==0), and ql > 0, because then there is a reference to EMS[nE-1], which doesn't exist.SNOWPACK can crash in WaterTransport::compTopFlux if there is no soil, and no snow (i.e., nE==0), and ql > 0, because then there is a reference to EMS[nE-1], which doesn't exist.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/883Wrong version number when not using gitlab hash2023-08-08T13:44:25ZMathias BavayWrong version number when not using gitlab hashThe version number that is used by default (when not using version number from gitlab hash) is still 3.0.0... This is confusing for the users! But we can not change it right away, as it will trigger a release generation by the Gitlab jobs.The version number that is used by default (when not using version number from gitlab hash) is still 3.0.0... This is confusing for the users! But we can not change it right away, as it will trigger a release generation by the Gitlab jobs.Mathias BavayMathias Bavayhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/882Fill NodeData.water_flux when using Bucket scheme2023-07-26T10:17:57ZNander WeverFill NodeData.water_flux when using Bucket schemeCurrently, commit 37109aa1ec3bcc76a5e62430f13fcf3bd72da5c5 implements a NodeData.water_flux variable to document the water fluxes across the nodes. This variable is only filled when using Richards Equation, while it is kept at 0. when us...Currently, commit 37109aa1ec3bcc76a5e62430f13fcf3bd72da5c5 implements a NodeData.water_flux variable to document the water fluxes across the nodes. This variable is only filled when using Richards Equation, while it is kept at 0. when using the Bucket scheme. It must be pretty easy to also store the water fluxes across nodes (i.e., between elements) when using the Bucket scheme (in WaterTransport.cc). This could be necessary or useful when doing runoff modeling in Alpine3D. Runoff variables in Alpine3D should be correct now when at least soil is solved with Richards Equation.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/881Document water transport, including pref flow2023-06-21T12:28:12ZMathias BavayDocument water transport, including pref flowIn order to use PREF_FLOW, a new column must be present in the sno files. This should be documented somewhere (as well as a note in Inishell) and checked in the SNO plugin. Most probably, the best option would be:
* write a documentatio...In order to use PREF_FLOW, a new column must be present in the sno files. This should be documented somewhere (as well as a note in Inishell) and checked in the SNO plugin. Most probably, the best option would be:
* write a documentation in WaterTransport.cc that explains how water transport works and how ti can be configured (with links to the papers)
* implement checks in SmetIO.cc and other plugins (if any) that read SNO data to make sure that when such an option is toggled, the user will get an appropriate error message if the SNO files does not contain the necessary columns
* add some information about the SNO files in Inishell
The same should also be done with SEA_ICE...https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/880Keys to document and put in Inishell2023-06-15T16:43:31ZMathias BavayKeys to document and put in InishellThe following keys are currently not in Inishell and not necessarily documented:
ICE_RESERVOIR, SnowpackAdvanced
READ_DSM, SnowpackAdvanced
RIME_INDEX, SnowpackAdvanced
NEWSNOW_LWC, SnowpackAdvanced
HAZ_WRITE, Output (this one will prob...The following keys are currently not in Inishell and not necessarily documented:
ICE_RESERVOIR, SnowpackAdvanced
READ_DSM, SnowpackAdvanced
RIME_INDEX, SnowpackAdvanced
NEWSNOW_LWC, SnowpackAdvanced
HAZ_WRITE, Output (this one will probably be renamed as needed for the operational migration)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/879Height of new snow2023-06-29T08:04:39ZMathias BavayHeight of new snowThe various versions of height of new snow (hn24, hn6, hn3...) are only written out to the IMIS database. Therefore these outputs should also be available in the Ascii and Smet plugins (with a configurable key in the ini file?)The various versions of height of new snow (hn24, hn6, hn3...) are only written out to the IMIS database. Therefore these outputs should also be available in the Ascii and Smet plugins (with a configurable key in the ini file?)2023-08-15https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/878Soil problems2022-11-04T23:49:04ZMathias BavaySoil problemsThis issue is a follow up of issue #874. Further work with soil and relatively high ice/water/voids fractions have shown more issues. More synthetic simulations have been designed in order to identify where the problems might come from. ...This issue is a follow up of issue #874. Further work with soil and relatively high ice/water/voids fractions have shown more issues. More synthetic simulations have been designed in order to identify where the problems might come from.
- One such simulation consists in setting all parameters constant (TA=0°C, ISWR=0, ILWR=OLWR, PSUM=0) with a soil made of a single layer set at 0°C and with many elements. When running with bucket, besides a slow freezing coming from the soil surface and diffusing into the soil, everything is constant, as expected. When running with Richards, there are temperature oscillations as well as soil water content variations. See the required files for the simulation (it relies on the new MeteoIO's plugin "SYNTH") [io_all_cst.ini](/uploads/fb7ce4cc7638045979a22ca1eb7ea5ea/io_all_cst.ini), [stb2.sno](/uploads/41331f742d96fb99ae2553a8c5420197/stb2.sno) as well as a result when running with Richards: ![all_cst](/uploads/0df387e333e3beb4132cf2a0159040c0/all_cst.jpg)
- Another simulation builds on the first one but generates a sudden warming and precipitation event (the warming is there to allow for liquid precipitation). In this case, we see the same artifacts during the constant phase and then a behavior totally different from what was simulated with the old-trunk branch of Snowpack (ie before the merge of the water vapor transport modeling). See the files required for the simulation: [io_sudden_precip.ini](/uploads/299742175eab956792d3a8ece9fff428/io_sudden_precip.ini), [stb2_warm.sno](/uploads/4511c6f0889a83fefec519c9c7d1f8b5/stb2_warm.sno) and a comparison plot: ![psum_step](/uploads/4179deeb215b514aa1020c36d87e621c/psum_step.jpg)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/877CAAMLIO adaptions (temperature profile and secondary grain type)2022-10-13T09:41:34ZMichi BinderCAAMLIO adaptions (temperature profile and secondary grain type)1. Add a maximum layer thickness when reading the CAAML profile. It should be possible to define it via the ini-file to define some kind of resolution of the profile at readin. This should improve the temperature profile, which depends o...1. Add a maximum layer thickness when reading the CAAML profile. It should be possible to define it via the ini-file to define some kind of resolution of the profile at readin. This should improve the temperature profile, which depends on the layer resolution!
2. Consider the secondary grain type for parameterizing the dendricity, sphericity, ... (reversed way as used for the output possible?)
I might have time to work on these two topics by the end of the year...https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/876Projecting precipitation on the slope2022-10-19T10:17:20ZMathias BavayProjecting precipitation on the slopeWhen using Snowpack on a slope (not a virtual slope, a station that only exists on the slope), the precipitation is only reprojected to the slope if per_to_slope==false. Should we not always reproject the precipitation (sine it is always...When using Snowpack on a slope (not a virtual slope, a station that only exists on the slope), the precipitation is only reprojected to the slope if per_to_slope==false. Should we not always reproject the precipitation (sine it is always measured on the horizontal)? (see Main.cc: line 571)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/875PSUM buffer (?) Snowpack not starting2022-08-19T15:36:58ZAdrien MichelPSUM buffer (?) Snowpack not starting1. When a beginning date (-b arg) corresponding exactly to the starting date of the meteo data in the smet is provided, snowpack complains about missing precip `missing { precipitation } on ...`. This does not arise somehow with the res1...1. When a beginning date (-b arg) corresponding exactly to the starting date of the meteo data in the smet is provided, snowpack complains about missing precip `missing { precipitation } on ...`. This does not arise somehow with the res1exp example but with the data in attachment (which is at hourly resolution and not 30 minutes).
[MUT2.smet.zip](/uploads/02f3db44f33e1270381e9ad8b3bd6730/MUT2.smet.zip)
2. When no beginning date is provided, snowpack will refuse to start if the meteo is at hourly resolution. Either is complains about precip, either about missing TA TSG RH sw_radiation precipitation precip_splitting depending if data starts at 00:00 or later.
For 1, I imagine this is because meteoio/snowpack wants to accumulate PSUM over HH-timestep:HH. However this is highly inconvenient and non intuitive for users (how to guess they have to start one time-step later than the starting date of the meteo input?). We can imagine that snowpack checks it before starting and eventually uses the first PSUM value as input. Moreover, MeteoSwiss PSUM at hourly resolution is always HH-1:HH (I don't know if this is an international standard), so anyway snowpack should use PSUM at timestep + 1 insteaad of - 1 (then the problem will arise at the end...).
For 2, either data starts at 00:00 and we fallback to 1, or when starting later than midnight it seems that when no -b is provided snowpack tries to start at midnight, which is also non intuitive at all.
Edit: IT seems that ProfileDate in the sno file is used when no -b is provided. Is this the case? If yes, again not intuitive ;)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/872Adjust the turbulent heat fluxes coefficients according to the station's elev...2022-06-15T09:59:34ZMathias BavayAdjust the turbulent heat fluxes coefficients according to the station's elevationAs the air density depends on the [station's elevation](https://www.eoas.ubc.ca/courses/atsc113/flying/met_concepts/02-met_concepts/02a-std_atmos-P/index.html) and the [turbulent fluxes depend on the air density](https://www.cambridge.or...As the air density depends on the [station's elevation](https://www.eoas.ubc.ca/courses/atsc113/flying/met_concepts/02-met_concepts/02a-std_atmos-P/index.html) and the [turbulent fluxes depend on the air density](https://www.cambridge.org/core/journals/annals-of-glaciology/article/turbulent-fluxes-above-the-snow-surface/E461D2AF2781F020E3C65B75F59BE70D), this should be accounted for. This could explain some problems trying to run simulations with the exact same ini file for low elevation and high elevation stations.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/871stability correction verification2022-06-14T09:37:41ZMathias Bavaystability correction verificationThis January, we found some inconsistencies in the atmospheric stability correction. We must settle the matter!This January, we found some inconsistencies in the atmospheric stability correction. We must settle the matter!LehningLehning2022-08-31https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/870Sørensen (1991) wrongly implemented2022-07-01T02:50:11ZNander WeverSørensen (1991) wrongly implementedAs brought to our attention during a review process, the equation for saltation mass flux implemented in SNOWPACK, based on Sørensen (1991), is expressed in the wrong units. See https://doi.org/10.5194/gmd-2022-28-RC1. The coefficients w...As brought to our attention during a review process, the equation for saltation mass flux implemented in SNOWPACK, based on Sørensen (1991), is expressed in the wrong units. See https://doi.org/10.5194/gmd-2022-28-RC1. The coefficients would need to be converted from g/cm/s to kg/m/s.
According to Vionnet, 2012 (https://pastel.archives-ouvertes.fr/tel-00781279v3/document, Fig. 5.3) and Eq. 11 in Vionnet et al. 2014 (https://doi.org/10.5194/tc-8-395-2014), Sørensen (2004) may be a better option for calculating the saltation mass flux.https://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/867Snowpack has strange behavour when exporting CAAML format snow-file2021-09-28T06:41:22ZChristoph MittererSnowpack has strange behavour when exporting CAAML format snow-fileHi,
we encountered a strange behaviour when trying to export a snow-file into CAAML format.
Data used: MST96 example data set with example ini-file io_res1exp.ini (see also attachment)[io_res1exp.ini]
Machine setup: Ubuntu 20.04.2 LTS
...Hi,
we encountered a strange behaviour when trying to export a snow-file into CAAML format.
Data used: MST96 example data set with example ini-file io_res1exp.ini (see also attachment)[io_res1exp.ini]
Machine setup: Ubuntu 20.04.2 LTS
Snowpack version 3.60 compiled on Jul 1 2021 15:51:26
Libsnowpack 3.60 compiled on Jul 1 2021 15:50:30
MeteoIO 3.00 compiled on Jul 1 2021 15:45:43
Expected outcome: a *.caaml file describing a full snow profile for a desired time step
Result obtained: a *.sno file describing a full snow profile for a desired time step
Funnily, when changing to another OS (Mac OS High Sierra 10.13.6) and using
the identical data and ini-file setup w[io_res1exp.ini]ith
Snowpack version 3.60 compiled on Oct 16 2020 22:09:29
Libsnowpack 3.60 compiled on Oct 16 2020 22:08:30
MeteoIO 2.90 compiled on Oct 16 2020 21:55:33
we obtain what we want.
Thanks Christoph
[io_res1exp.ini](/uploads/c4fc71e8975109a88dc57d2fe7f3bffb/io_res1exp.ini)
[MST96.smet](/uploads/b53bac3ff344eaace410378e1f211135/MST96.smet)
[MST96.sno](/uploads/e5201bd6974a1d0a20864e5b5f9af7ea/MST96.sno)Mathias BavayMathias Bavayhttps://gitlabext.wsl.ch/snow-models/snowpack/-/issues/865MS_TOTALMASS2020-11-10T09:11:33ZAdrien MichelMS_TOTALMASSSnowpack has an inner SN_TOTALMASS variable, which is redundant with MS_SWE. While MS_SWE is updated at every time step, SN_TOTALMASS is not, so mass loss by sublimation or water to the soil seems not to be taken into account. I think th...Snowpack has an inner SN_TOTALMASS variable, which is redundant with MS_SWE. While MS_SWE is updated at every time step, SN_TOTALMASS is not, so mass loss by sublimation or water to the soil seems not to be taken into account. I think this variable should be removed because it is not updated at every time step and thus misleading.https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/840Soil surface temprature behave wrongly2020-06-06T18:06:07ZMathias BavaySoil surface temprature behave wrongly**This issue was reported by Vincent Sasseville.**
Steps to reproduce the problem:
1. Prepare a simulation with the soil module of snowpack.
2. Use Variant=ANTARCTICA and HN_DENSITY=EVENT
3. Make a multi-layer soil with a layer at the s...**This issue was reported by Vincent Sasseville.**
Steps to reproduce the problem:
1. Prepare a simulation with the soil module of snowpack.
2. Use Variant=ANTARCTICA and HN_DENSITY=EVENT
3. Make a multi-layer soil with a layer at the surface thinner than 2 meters
Expected result: A complete simulation
Actual result: After a couple of steps, the temperature of the surface layer seems to diverge, and becomes too warm. The simulation stops with this message:
""[Snowpack.cc:916] Runtime error in compTemperatureProfile""
I have attached a folder with the input I use. In the .sno file, you can swap between the 2 last lines to change the thickness of the surface layer. The thinner one (2m) makes the simulation crash while the thicker one (5m) makes the simulation successful.
I launch the simulation using this line:
>snowpack -c config/Standart.ini -e 2015-06-30
Snowpack version 3.50
MeteoIO 2.80
**Attachment**:
* [176_209_8_32.rar](/uploads/5809fa2bef84fb07aba38ad176e9a8ff/176_209_8_32.rar)https://gitlabext.wsl.ch/snow-models/snowpack/-/issues/799Flexible reading of SMET2019-11-12T08:44:42ZMathias BavayFlexible reading of SMETAfter Hiroyuki's commit to dev, it is quite urgent to redo the SMET reading for sno files: we should check which fields are present and properly read data only from the available fields.After Hiroyuki's commit to dev, it is quite urgent to redo the SMET reading for sno files: we should check which fields are present and properly read data only from the available fields.