airGR issueshttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues2021-01-27T13:40:43+01:00https://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/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/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/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/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/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/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/79Improve description of Output from CemaNeige functions2021-01-06T08:01:31+01:00Thirel GuillaumeImprove description of Output from CemaNeige functionsTo improve the understanding of CemaNeige outputs (cf a misunderstanding a user recently had), I suggest we replace
`[numeric] series of snow pack [mm]`
with
`[numeric] series of snow pack (snow water equivalent) [mm]`To improve the understanding of CemaNeige outputs (cf a misunderstanding a user recently had), I suggest we replace
`[numeric] series of snow pack [mm]`
with
`[numeric] series of snow pack (snow water equivalent) [mm]`v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/78States handling on Lag model2021-01-07T17:47:27+01:00Dorchies DavidStates handling on Lag model## Analysis of the existing situation
In the lag model, upstream flows are added to the downstream flow with a delay. At the beginning of the simulation during this delay time, zero are currently added downstream because upstream flow b...## Analysis of the existing situation
In the lag model, upstream flows are added to the downstream flow with a delay. At the beginning of the simulation during this delay time, zero are currently added downstream because upstream flow before the beginning of the simulation are not known. This period can be regarded as a warming period with initial zero flow upstream which lasts few days (Few time steps for a daily time step model).
## Requirements
The package **airGRiwrm** will need to run the model time step by time step without warming period (See in-wop/airGRiwrm#19). So we need to be able to handle states of the Lag model both as initial states and states at the end of the simulation.
- the `IniStates` object embedded in `RunOptions` should store a list of vector, each vector containing the flows during the delay time of the upstream flow.
- the `OutputsModel` object should contains this same list in the `StateEnd` item.
Lag model would not be the only hydraulic propagation model, so the implementation needs to be generic for other hydraulic propagation models.
## Proposition of realisation
### Storage
Adding a `SD` item in both `IniStates` object and `StateEnd` item of `OutputsModel`. Its contents will be model dependant. For the lag model it consists in a list ordered by the upstream connections and each item of the list will store the flow for the time steps during the delay time of each upstream flow.
### Implementation
- [x] Modification of `createIniStates` with a new parameter `SD` default `NULL` and copy this parameter in the `IniStates` object
- [x] Modification of `CreateRunOptions` for handling the new `SD` item
- [x] Modification of `RunModelLag` to use the hydraulic initial states provided by `RunOptions` instead of zeros
- [x] Modification of `RunModelLag` to add hydraulic states at the end of the simulation in `OutputsModel$StateEnd$SD`v1.6.10Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/77Warn users in SeriesAggreg when ConvertFun is not provided2021-01-06T10:07:56+01:00Delaigue OlivierWarn users in SeriesAggreg when ConvertFun is not providedIt may be a good idea to return a message when `SeriesAggreg()` is applied on a unknown object (e.g. not `InputsModel ` or `OutputsModel` objects) and `ConvertFun` is also not provided.It may be a good idea to return a message when `SeriesAggreg()` is applied on a unknown object (e.g. not `InputsModel ` or `OutputsModel` objects) and `ConvertFun` is also not provided.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/76Group release history of non submited versions2021-01-08T04:57:39+01:00Delaigue OlivierGroup release history of non submited versionsExcept for the very first versions of the packages. Only the package versions submitted to CRAN is subject to a history. Therefore, in the NEWS file, the information for the version 1.6.3.73 and the latest version should be grouped toget...Except for the very first versions of the packages. Only the package versions submitted to CRAN is subject to a history. Therefore, in the NEWS file, the information for the version 1.6.3.73 and the latest version should be grouped together (nota: the latest version on the CRAN is the 1.4.3.65.)v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/75Improve X6 parameter description2021-01-06T08:08:15+01:00Delaigue OlivierImprove X6 parameter description@vazken.andreassian, friday 18 December 2020 16:06:59
> @olivier.delaigue and @charles.perrin,
>
> I don't like the name of the X6 parameter in the airGR help file:
>
> - GR6J X1 production store capacity [mm]
> - GR6J X2 intercat...@vazken.andreassian, friday 18 December 2020 16:06:59
> @olivier.delaigue and @charles.perrin,
>
> I don't like the name of the X6 parameter in the airGR help file:
>
> - GR6J X1 production store capacity [mm]
> - GR6J X2 intercatchment exchange coefficient [mm/d]
> - GR6J X3 routing store capacity [mm]
> - GR6J X4 unit hydrograph time constant [d]
> - GR6J X5 intercatchment exchange threshold [-]
> - **GR6J X6 coefficient for emptying exponential store [mm]**
>
> I didn't find the name that was given to him in the publications...
>
> Wouldn't "parameter of the exponential store" or "exponential store depletion coefficient" be better?v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/74Add imported basics packages in the DESCRIPTION file2021-01-06T09:06:02+01:00Delaigue OlivierAdd imported basics packages in the DESCRIPTION fileTo be more secure, it is better to add the following import packages in the DESCRIPTION file:
- "graphics"
- "grDevices"
- "stats"
- "utils"To be more secure, it is better to add the following import packages in the DESCRIPTION file:
- "graphics"
- "grDevices"
- "stats"
- "utils"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/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/69Regression tests are not functionning2020-11-24T08:05:37+01:00Dorchies DavidRegression tests are not functionningThe commit 87be8b19da952e5bbd5843ed049d520590bdd395 modify the variable `OutputsModel` produced by `RunModel_GR1A`. Consequently the regression test should have failed on the comparison of this variable with the result produced by airGR ...The commit 87be8b19da952e5bbd5843ed049d520590bdd395 modify the variable `OutputsModel` produced by `RunModel_GR1A`. Consequently the regression test should have failed on the comparison of this variable with the result produced by airGR currently published on CRAN.
The tests didn't detect anything.
The variables stored during the job "regression_test" on Gitlab CI (available at https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/jobs/130833/artifacts/download) show that there is a difference between the two variables:
```
OMref <- readRDS("C:/DocDD/tmp/ref/RunModel_GR1A/OutputsModel.rds")
> OMpatched <- readRDS("C:/DocDD/tmp/patched/RunModel_GR1A/OutputsModel.rds")
> identical(OMref, OMpatched)
[1] FALSE
```
So maybe the regression are not executed during the `check_not_cran` job as it is initially planned.v1.6.10Dorchies DavidDorchies David