airGR issueshttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues2023-10-19T13:45:22+02:00https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/38hydroPSO package available again on CRAN2023-10-19T13:45:22+02:00Delaigue OlivierhydroPSO package available again on CRANThe **hydroPSO** package came back on CRAN and can again be suggested in the **DESCRIPTION** file.The **hydroPSO** package came back on CRAN and can again be suggested in the **DESCRIPTION** file.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/73Check conditionnal test in Calibration2023-04-11T09:11:34+02:00Delaigue OlivierCheck conditionnal test in Calibration@guillaume.thirel and @david.dorchies, I'm not sure to understand the following bug. I'm a little lost in the conditions of the `Calibration_Michel()` function (not a surprise!).
```r
library(airGR)
## data.frame of daily observed data...@guillaume.thirel and @david.dorchies, I'm not sure to understand the following bug. I'm a little lost in the conditions of the `Calibration_Michel()` function (not a surprise!).
```r
library(airGR)
## data.frame of daily observed data of a low-land basin
data(L0123001, package = "airGR")
BV_L0123001 <- BasinObs[0001:6000, c("DatesR", "P", "E", "Qmm", "T")]
BI_L0123001 <- BasinInfo
BasinObs <- SeriesAggreg(BV_L0123001[BV_L0123001$DatesR < "2000-06-01",], Format = "%Y%m")
## preparation of the InputsModel object with daily time step data
InputsModel <- CreateInputsModel(FUN_MOD = RunModel_GR2M, DatesR = BasinObs$DatesR,
Precip = BasinObs$P, PotEvap = BasinObs$E)
## conversion of InputsModel to monthly time step
InputsModel <- SeriesAggreg(InputsModel, Format = "%Y%m")
## run period selection
Ind_Run <- seq(which(format(InputsModel$DatesR, format = "%Y-%m") == "1994-01"),
which(format(InputsModel$DatesR, format = "%Y-%m") == "1998-12"))
RunOptions <- CreateRunOptions(FUN_MOD = RunModel_GR2M, InputsModel = InputsModel,
IndPeriod_WarmUp = NULL, IndPeriod_Run = Ind_Run, verbose = FALSE)
InputsCrit <- CreateInputsCrit(FUN_CRIT = ErrorCrit_NSE, InputsModel = InputsModel,
RunOptions = RunOptions, Obs = BasinObs$Qmm[Ind_Run], transfo = "")
CalibOptions <- CreateCalibOptions(FUN_MOD = RunModel_GR2M, FUN_CALIB = Calibration_Michel)
OutputsCalib <- Calibration_Michel(InputsModel = InputsModel, RunOptions = RunOptions,
InputsCrit = InputsCrit, CalibOptions = CalibOptions,
FUN_MOD = RunModel_GR2M)
```
```r
Error in Calibration_Michel(InputsModel = InputsModel, RunOptions = RunOptions, :
'FUN_TRANSFO' was not found (in 'Calibration' function)
```
The function stops at the condition of line 189.
```r
> traceback()
2: stop("'FUN_TRANSFO' was not found (in 'Calibration' function)") at Calibration_Michel.R#189
1: Calibration_Michel(InputsModel = InputsModel, RunOptions = RunOptions,
InputsCrit = InputsCrit, CalibOptions = CalibOptions, FUN_MOD = RunModel_GR2M)
```v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/62Embed Oudin's Fortran code2021-08-04T14:02:11+02:00Delaigue OlivierEmbed Oudin's Fortran codeThe [PREMHYCE](https://gitlab.irstea.fr/HYCAR-Hydro/PREMHYCE) project need a faster version of the `PE_Oudin()` function.
The vectorization of the code is not satisfactory, it would be preferable to integrate the Fortran version of the ...The [PREMHYCE](https://gitlab.irstea.fr/HYCAR-Hydro/PREMHYCE) project need a faster version of the `PE_Oudin()` function.
The vectorization of the code is not satisfactory, it would be preferable to integrate the Fortran version of the code. I think that is a good idea to keep the R version of the code to facilitate the comprehension by the users. In this case we can add an argument to switch from the R code to the Fortran code.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/89Fix airGRteaching 0.2.9.25 reverse dependency2021-06-22T09:46:15+02:00Delaigue OlivierFix airGRteaching 0.2.9.25 reverse dependency> From: "Uwe Ligges"
> To: "airGR"
> Cc: "CRAN-submissions"
> Date: Jeudi 14 Janvier 2021 07:11:06
> Subject: [CRAN-pretest-waiting] CRAN submission airGR 1.6.9.24
>
> Dear maintainer,
>
> package airGR_1.6.9.24....> From: "Uwe Ligges"
> To: "airGR"
> Cc: "CRAN-submissions"
> Date: Jeudi 14 Janvier 2021 07:11:06
> Subject: [CRAN-pretest-waiting] CRAN submission airGR 1.6.9.24
>
> Dear maintainer,
>
> package airGR_1.6.9.24.tar.gz has been auto-processed. The auto-check found problems when checking the first order strong reverse dependencies.
> Please reply-all and explain: Is this expected or do you need to fix anything in your package? If expected, have all maintainers of affected packages been informed well in advance? Are there false positives in our results?
>
> *** Changes to worse in reverse dependencies ***
> Debian: <https://win-builder.r-project.org/incoming_pretest/airGR_1.6.9.24_20210113_193646/reverseDependencies/summary.txt>
>
> Log dir: <https://win-builder.r-project.org/incoming_pretest/airGR_1.6.9.24_20210113_193646/>
> The files will be removed after roughly 7 days.
>
> Pretests:
> Windows: <https://win-builder.r-project.org/incoming_pretest/airGR_1.6.9.24_20210113_193646/Windows/00check.log>
> Debian: <https://win-builder.r-project.org/incoming_pretest/airGR_1.6.9.24_20210113_193646/Debian/00check.log>
```
Changes to worse in reverse depends:
Package: airGRteaching
Check: R code for possible problems
New result: NOTE
plot.CalGR: no visible global function definition for
"plot.OutputsModel"
Undefined global functions or variables:
plot.OutputsModel
```
If I understand well, even when airGRteaching is installed from sources, the package has registered the space from which the functions it depends on are exported.
Summary:
| Package | Version | CRAN | plot.OutputsModel |
| ------ | ------ | ------ | ------ |
| airGR | 1.4.3.65 | yes | exported |
| airGR | 1.6.9.24 | submitted | not exported |
| airGRteaching | 0.2.9.25 | yes | imported from the global environment |
| airGRteaching | 0.2.10.106 | to be submitted | imported from airGR namespace |
```r
library(airGRteaching)
example("CalGR")
```
Using **airGRteaching 0.2.9.25** (current version on the CRAN; it runs well on 0.2.10.106) with **airGR 1.6.9.24**:
```r
plot(CAL)
Error in plot.OutputsModel(x$OutputsModel, Qobs = x$Qobs, ...) :
could not find function "plot.OutputsModel"
```
Nota: inside `plot.CalGR()`, `plot.OutputsModel()` is currently call using `plot(OutputsModel)`
Although I answer to the CRAN team that the future version of airGRteaching will solve the problem, users with the 1.6.9.24 version of airGR and the 0.2.9.25 version of airGRteaching will not be able to use airGRteaching properly and we can't warn them). In order to avoid breaking the reverse dependency of airGRteaching, I suggest :
1. export `plot.OutputsModel()` in **airGR 1.6**
2. call `plot.OutputsModel()` using `airGR:::plot.OutputsModel()` in **airGRteaching 0.2.10**
3. not export `plot.OutputsModel()` in in the **next version of airGR** (2.0)
4. call `plot.OutputsModel()` using `plot()` in the **next version of airGRteaching** (as it is used currently in the version 0.2.9.25)
I think the temporary use of `:::` in airGRteaching will solve the transition smoothly for users and will help to avoid breaking airGRteaching.
@david.dorchies and @guillaume.thirel , do you agree? I think I'll ask the opinion of the CRAN team.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/61Add the use of caRamel in the optimization vignette2021-01-29T11:23:15+01:00Delaigue OlivierAdd the use of caRamel in the optimization vignetteWe may add the use of the [**caRamel**](https://CRAN.R-project.org/package=caRamel) package in the optimization vignette (and the airGR vignette). A code is provided with [this article](https://www.hydrol-earth-syst-sci.net/24/3189/2020/...We may add the use of the [**caRamel**](https://CRAN.R-project.org/package=caRamel) package in the optimization vignette (and the airGR vignette). A code is provided with [this article](https://www.hydrol-earth-syst-sci.net/24/3189/2020/hess-24-3189-2020.html). @guillaume.thirel provided an initial version of this piece of code in his review of the paper.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/94Use of relational operators on POSIXlt on CRAN macOS flavors2021-01-28T22:32:07+01:00Delaigue OlivierUse of relational operators on POSIXlt on CRAN macOS flavorsairGR 1.6.9.27 checks return [errors on masOS](https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/airGR-00check.html) (also see [CRAN_v1.6.9.27](https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/tags/CRAN_v1.6.9.27) tag). Ir works...airGR 1.6.9.27 checks return [errors on masOS](https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/airGR-00check.html) (also see [CRAN_v1.6.9.27](https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/tags/CRAN_v1.6.9.27) tag). Ir works well on Linux and Windows OS.
It seems to be because of the a comparison on POSIXlt dates to return a subset of time series.
In `RunModel_GR1A()` example, I think that the `TabSeries` time series is not the wanted one.
Maybe `2012-09-01` is selected, so `SeriesAggreg()` returns NA values for the last time step. Then, `InputsModel()` return an error.
```r
library(airGR)
## loading catchment data
data(L0123001)
## conversion of example data from daily to yearly time step
TabSeries <- data.frame(DatesR = BasinObs$DatesR,
P = BasinObs$P,
E = BasinObs$E,
Qmm = BasinObs$Qmm)
TabSeries <- TabSeries[TabSeries$DatesR < "2012-09-01", ]
BasinObs <- SeriesAggreg(TabSeries, Format = "%Y",
YearFirstMonth = 09,
ConvertFun = c("sum", "sum", "sum"))
## preparation of the InputsModel object
InputsModel <- CreateInputsModel(FUN_MOD = RunModel_GR1A, DatesR = BasinObs$DatesR,
Precip = BasinObs$P, PotEvap = BasinObs$E)
```
I think that there is a similar problem in "test-SerriesAggreg" (line 64); the `GoodValues` time series is not the wanted one. Then `expect_equal()` detects a difference.
```r
GoodValues <- apply(BasinObs[BasinObs$DatesR >= "1984-09-01" &
BasinObs$DatesR < "1985-09-01",
c("P", "E", "Qmm")], 2, sum)
TestedValues <- unlist(SeriesAggreg(TabSeries,
Format = "%Y",
YearFirstMonth = 9,
ConvertFun = rep("sum", 3))[1, c("P", "E", "Qmm")])
expect_equal(GoodValues, TestedValues)
```
Nota: in `TabSeries$DatesR < "2012-09-01"`, `TabSeries$DatesR` is in UTC and `"2012-09-01"` is in local time, this is normally not a problem at the daily time step.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/93Warning at compilation due to potentially uninitialised variable2021-01-27T17:39:16+01:00Pelletier AntoineWarning at compilation due to potentially uninitialised variableA warning is produced by GCC Fortran compiler while installing airGR version 1.6.9.27, due to a _may be uninitialized variable_.
## How to reproduce the bug?
1. Clone master branch of repository at commit `88db83a415ac97742353fc06245c4...A warning is produced by GCC Fortran compiler while installing airGR version 1.6.9.27, due to a _may be uninitialized variable_.
## How to reproduce the bug?
1. Clone master branch of repository at commit `88db83a415ac97742353fc06245c40255535f6e7`
2. Run `R CMD build airgr`
3. Run `R CMD INSTALL airGR_1.6.9.27.tar.gz`
**Used software:** openSUSE Leap 15.2 with Linux 5.3.18-lp152.60-default kernel; GNU Fortran 11.0.0 20210122 for SUSE Linux; R version 4.0.3
**Compilation flags:** `-fno-optimize-sibling-calls -fpic -std=f2018 -fmessage-length=0 -grecord-gcc-switches -O3 -Wall -pedantic -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection`
## Expected behaviour
Compilation and installation without warning.
## Actual behaviour
Warning while compiling `frun_GR5H.f90`:
```console
gfortran -fno-optimize-sibling-calls -fpic -std=f2018 -fmessage-length=0 -grecord-gcc-switches -O3 -Wall -pedantic -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -c frun_GR5H.f90 -o frun_GR5H.o
frun_GR5H.f90:93:26:
93 | IF (IsIntStore .EQV. .TRUE.) St(3) = StateStart(4)
| ^
Avertissement: « isintstore » may be used uninitialized [-Wmaybe-uninitialized]
frun_GR5H.f90:71:27:
71 | logical :: IsIntStore ! TRUE if interception store is used, FALSE otherwise
| ^
note: « isintstore » déclaré ici
```
## Proposed solution
Change lines 79 and 80 of `frun_GR5H.f90` to an if-else statement:
```fortran
IF (Imax .LT. 0.) THEN
IsIntStore = .FALSE.
ELSE
IsIntStore = .TRUE.
ENDIF
```v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/92Stop Imax when the time series is not complete2021-01-27T13:41:19+01:00Delaigue OlivierStop Imax when the time series is not complete`Imax()` does not work if the aggregated daily time series is not complete.
In this example Ind_Run1 stops at 11 p.m and Ind_Run2 stops at 10 p.m.
```r
library(airGR)
## loading catchment data
data(L0123003)
## preparation of the In...`Imax()` does not work if the aggregated daily time series is not complete.
In this example Ind_Run1 stops at 11 p.m and Ind_Run2 stops at 10 p.m.
```r
library(airGR)
## loading catchment data
data(L0123003)
## preparation of the InputsModel object
InputsModel <- CreateInputsModel(FUN_MOD = RunModel_GR5H, DatesR = BasinObs$DatesR,
Precip = BasinObs$P, PotEvap = BasinObs$E)
## run period selection
Ind_Run1 <- seq(which(format(BasinObs$DatesR, format = "%Y-%m-%d %H:%M")=="2006-01-01 00:00"),
which(format(BasinObs$DatesR, format = "%Y-%m-%d %H:%M")=="2006-12-31 23:00"))
Ind_Run2 <- Ind_Run1[-length(Ind_Run1)]
## Imax computation on Ind_Run1
Imax(InputsModel = InputsModel, IndPeriod_Run = Ind_Run1,
TestedValues = seq(from = 0, to = 3, by = 0.2))
##
## 1.4
##
## Imax computation on Ind_Run1
Imax(InputsModel = InputsModel, IndPeriod_Run = Ind_Run2,
TestedValues = seq(from = 0, to = 3, by = 0.2))
##
## numeric(0)
##
```
This is caused by the new behavior of `SerriesAggreg()` ()line 35 that returns a NA value when the time series is not complete for the aggregated time step.
```
DatesR Precip PotEvap
17377 2006-12-26 0.00 0.10
17401 2006-12-27 0.00 0.20
17425 2006-12-28 0.00 0.38
17449 2006-12-29 1.87 0.38
17473 2006-12-30 6.88 0.52
17497 2006-12-31 NA NA
```
So in this case, it would be better to stop the computation of `Imax()`.
In addition, the code could be simplified using the `[.InputsModel` method (line 32).v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/95Move CemaNeige daily gradients outside DataAltiExtrapolation_Valery2021-01-27T13:40:43+01:00Delaigue OlivierMove CemaNeige daily gradients outside DataAltiExtrapolation_ValeryMove `GradT_Valery2010()` in an utils file, outside `DataAltiExtrapolation_Valery()` in order to make it more readable.
In additon, set `GradP_Valery2010` as a vector and `GradT_Valery2010` as a data.frame instead of functions.
Rename ...Move `GradT_Valery2010()` in an utils file, outside `DataAltiExtrapolation_Valery()` in order to make it more readable.
In additon, set `GradP_Valery2010` as a vector and `GradT_Valery2010` as a data.frame instead of functions.
Rename `GradT_Valery2010` into `.GradT_Valery2010`.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/88Improve GR2M scheme2021-01-13T11:19:33+01:00Thirel GuillaumeImprove GR2M schemeWe could add the actual evapotranspiration and Ps on the diagram, as for other models.We could add the actual evapotranspiration and Ps on the diagram, as for other models.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/87Rename Actual Exchange variable in the GR2M outputs2021-01-13T09:32:21+01:00Thirel GuillaumeRename Actual Exchange variable in the GR2M outputsThe `EXCH` variable in the GR2M Fortran code represents the actual exchange, not the potential exchange. I suggest renaming it `AEXCH` as for other models.
Enclose is the FORTRAN updated.
I will adapt the manual accordingly.
@olivie...The `EXCH` variable in the GR2M Fortran code represents the actual exchange, not the potential exchange. I suggest renaming it `AEXCH` as for other models.
Enclose is the FORTRAN updated.
I will adapt the manual accordingly.
@olivier.delaigue I guess you have to adapt `.FortranOutputs`
[frun_GR2M.f90](/uploads/9eb41e58436e7a48981baeb698820b71/frun_GR2M.f90)v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/85Add the name of the variables as they appear in model schemes2021-01-12T18:53:45+01:00Thirel GuillaumeAdd the name of the variables as they appear in model schemesI propose that in the Value field, we add between parenthesis the name of variables (when possible) as they appear in the schemes.I propose that in the Value field, we add between parenthesis the name of variables (when possible) as they appear in the schemes.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/49Add GR5H diagram in the RunModel_GR5H function help2021-01-12T17:00:34+01:00Thirel GuillaumeAdd GR5H diagram in the RunModel_GR5H function helpWe need to add the GR5H diagram in the `RunModel_GR5H()` function help.We need to add the GR5H diagram in the `RunModel_GR5H()` function help.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/80Use user-defined macros in the manual2021-01-12T14:54:58+01:00Delaigue OlivierUse user-defined macros in the manualIt is possible to use user-defines macros in order not to write a new time the package title, the package description, etc. For references, it is also possible to replace the `href` mark by the `doi` mark.
* `\packageTitle`
* `\packageD...It is possible to use user-defines macros in order not to write a new time the package title, the package description, etc. For references, it is also possible to replace the `href` mark by the `doi` mark.
* `\packageTitle`
* `\packageDescription`
* `\packageAuthor`
* `\packageMaintainer`
* `\packageDESCRIPTION`
* `\packageIndices`
* `\doi`
See *[Writing R Extensions](https://cloud.r-project.org/doc/manuals/R-exts.html#User_002ddefined-macros)*[ (User-defined macros)](https://cloud.r-project.org/doc/manuals/R-exts.html#User_002ddefined-macros)
This avoids, for example, possible differences between the title of the description file and the title of the package's help page.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/83Change the minimum number of time steps to calculate the criterion in .ErrorCrit2021-01-11T18:10:28+01:00Delaigue OlivierChange the minimum number of time steps to calculate the criterion in .ErrorCritThe `.ErrorCrit()` function returns a warning message when the criterion is calculated over too few time steps.
Currently:
- **hourly : 365**
- daily : 365
- monthly : 12
- yearly : 3The `.ErrorCrit()` function returns a warning message when the criterion is calculated over too few time steps.
Currently:
- **hourly : 365**
- daily : 365
- monthly : 12
- yearly : 3v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/64Add precision in PE_Oudin doc2021-01-11T12:01:57+01:00Thirel GuillaumeAdd precision in PE_Oudin docThe Oudin paper used meteorological data at the station level to calculate PE. This is not specified but it is likely that point PE data were then basin averaged. (this is also what we do in our team when we use SAFRAN gridded data)
We ...The Oudin paper used meteorological data at the station level to calculate PE. This is not specified but it is likely that point PE data were then basin averaged. (this is also what we do in our team when we use SAFRAN gridded data)
We should therefore add an advice to do that in the Details of the `PE_Oudin` doc. I propose the following:
> To calculate basin-wide Oudin potential evapotranspiration, it is advised, when possible, to use either station temperature or gridded temperature data to calculate PE and then average these PE values at the basin scale.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/70Improve explanations of GR5 outputs values2021-01-11T11:54:38+01:00Delaigue OlivierImprove explanations of GR5 outputs valuesthe explanations of the outputs of the GR5* models must be improved, because they refer to the use of 2 unit hydrographs whereas there is only one in GR5.
This concerns:
- RunModel_CemaNeigeGR5H
- RunModel_CemaNeigeGR5J
- RunModel_GR5H...the explanations of the outputs of the GR5* models must be improved, because they refer to the use of 2 unit hydrographs whereas there is only one in GR5.
This concerns:
- RunModel_CemaNeigeGR5H
- RunModel_CemaNeigeGR5J
- RunModel_GR5H
- RunModel_GR5J
|value| explanation |
|-----|---------------------------------------------|
| $Q9 | [numeric] series of UH1 outflow (Q9) [mm/d] |
| $Q1 | [numeric] series of UH2 outflow (Q1) [mm/d] |v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/82Opening of usable functions in SeriesAggreg2021-01-11T10:34:06+01:00Dorchies DavidOpening of usable functions in SeriesAggreg"min", "max" and "median" should be usable besides "sum" and "mean" functions currently available in SeriesAggreg. But also other functions as below:
## Quantile (percentile)
A call to a function named "qn" should be interpreted as `qu..."min", "max" and "median" should be usable besides "sum" and "mean" functions currently available in SeriesAggreg. But also other functions as below:
## Quantile (percentile)
A call to a function named "qn" should be interpreted as `quantile(x, probs = n)` (i.e. "q90" as `probs = 0.9`)
## Any function
Any function taking a vector as first argument and returning a single value.v1.6.10Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/67Add '['.InputsModel and '['.OutputsModel functions2021-01-11T08:53:05+01:00Delaigue OlivierAdd '['.InputsModel and '['.OutputsModel functionsWe need have to move the `'['.Inputs.default()` & `'['.InputsModel()` functions from the [airGRdatassim](https://gitlab.irstea.fr/HYCAR-Hydro/airgrdatassim) package to airGR.
See https://gitlab.irstea.fr/HYCAR-Hydro/airgrdatassim/-/issu...We need have to move the `'['.Inputs.default()` & `'['.InputsModel()` functions from the [airGRdatassim](https://gitlab.irstea.fr/HYCAR-Hydro/airgrdatassim) package to airGR.
See https://gitlab.irstea.fr/HYCAR-Hydro/airgrdatassim/-/issues/14v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/23Remove deprecated argument RunSnowModule2021-01-08T05:39:46+01:00Thirel GuillaumeRemove deprecated argument RunSnowModuleThe `RunSnowModule` argument of `CreateRunOptions` is deprecated for more than 2 years (see [https://forge.irstea.fr/issues/4737](https://forge.irstea.fr/issues/4737)).
Can we now remove it?The `RunSnowModule` argument of `CreateRunOptions` is deprecated for more than 2 years (see [https://forge.irstea.fr/issues/4737](https://forge.irstea.fr/issues/4737)).
Can we now remove it?v1.6.10