airGR issueshttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues2022-07-19T08:54:50+02:00https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/156RunModel_Lag: wrong values in parameter screening2022-07-19T08:54:50+02:00Dorchies DavidRunModel_Lag: wrong values in parameter screeningLag parameter screening values are currently:
```r
ParamTSD <- matrix(c(+1.25,
+2.50,
+5.00), ncol = 1, byrow = TRUE)
```
These values corresponds to a correct definition for **Real** paramete...Lag parameter screening values are currently:
```r
ParamTSD <- matrix(c(+1.25,
+2.50,
+5.00), ncol = 1, byrow = TRUE)
```
These values corresponds to a correct definition for **Real** parameters but, as we see that all other model screening values are between -10 and 10, **Transformed** parameters should be used here.
This wrong screening could explain the trend of the calibration to converge to high values of celerity when sensibility to this parameter is low.
As the range of the real parameter celerity is defined in the range `[0, 20]`, corresponding transformed parameters should be:
```r
ParamTSD <- matrix(c(-8.75,
-7.50,
-5.00), ncol = 1, byrow = TRUE)
```v1.8Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/145CreateIniStates: Mistake when checking if IntStore is not NULL with another m...2022-02-03T08:42:39+01:00Tilmant FrancoisCreateIniStates: Mistake when checking if IntStore is not NULL with another model than GR5HThere is a mistake in the check of IntStore when using another model than GR5H.
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/blob/dev/R/CreateIniStates.R#L77
It should be : <br>
`if (!(identical(FUN_MOD, RunModel_GR5H) | identical(FUN_...There is a mistake in the check of IntStore when using another model than GR5H.
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/blob/dev/R/CreateIniStates.R#L77
It should be : <br>
`if (!(identical(FUN_MOD, RunModel_GR5H) | identical(FUN_MOD, RunModel_CemaNeigeGR5H)) & !is.null(IntStore))` <br>
instead of : <br>
`if ((!identical(FUN_MOD, RunModel_GR5H) | identical(FUN_MOD, RunModel_CemaNeigeGR5H)) & !is.null(IntStore))`v1.7https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/144Extraction of Zlayers in DataAltiExtrapolation_Valery function2022-02-02T18:35:09+01:00Tilmant FrancoisExtraction of Zlayers in DataAltiExtrapolation_Valery functionWhen using a vector of 101 values for `HypsoData` for 5 layers, the selected indexes are wrong (one less than what is expected).
For example, the elevation of the 3rd layer should be the median elevation of the catchment (HypsoData[51]) ...When using a vector of 101 values for `HypsoData` for 5 layers, the selected indexes are wrong (one less than what is expected).
For example, the elevation of the 3rd layer should be the median elevation of the catchment (HypsoData[51]) but the selected index is 50.v1.7https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/137Fix .ExtractOutputsModel function to manage the new elements of OutputsModel2022-02-15T08:39:07+01:00Delaigue OlivierFix .ExtractOutputsModel function to manage the new elements of OutputsModelThe `.ExtractOutputsModel()` function no longer works because of the addition of the `Param` and `WarmUpQsim` elements in the `OutputsModel` object.
There are several solutions to solve the problem:
- handle each exception in the fu...The `.ExtractOutputsModel()` function no longer works because of the addition of the `Param` and `WarmUpQsim` elements in the `OutputsModel` object.
There are several solutions to solve the problem:
- handle each exception in the function `.ExtractOutputsModel()` (not recommended from my point of view)
- manage the `Param` and `WarmUpQsim` elements as the different elements of `StateEnd`, i.e. in a list
If the second solution is chosen, we need to mange the `.GetOutputsModelGR()` (UtilsRunModel.R) as following. But the fact that the `WarmUpQsim` element has a specific `"WarmUpOutputsModelItem"` class is also a problem.
```r
if ("WarmUpQsim" %in% RunOptions$Outputs_Sim) {
OutputsModel$RunOptions$WarmUpQsim <- RESULTS$Outputs[seq_len(length(RunOptions$IndPeriod_WarmUp)),
which(FortranOutputs == "Qsim")]
class(OutputsModel$RunOptions$WarmUpQsim) <- c("WarmUpOutputsModelItem", class(OutputsModel$RunOptions$WarmUpQsim))
}
if ("Param" %in% RunOptions$Outputs_Sim) {
OutputsModel$RunOptions$Param <- Param
}
```
`.ExtractOutputsModel()`:
```
if (!is.null(x$RunOptions)) {
res$RunOptions <- x$RunOptions
}
```v1.7https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/136Decreased performance of calibration execution time2021-11-03T11:17:53+01:00Dorchies DavidDecreased performance of calibration execution timeSince merge of branch 132-runmodel_lag-add-warmupqsim-to-outputsmodel into dev the calibration schedule test lasts more than 60 minutes to run although it lasts less than 25 minutes before.Since merge of branch 132-runmodel_lag-add-warmupqsim-to-outputsmodel into dev the calibration schedule test lasts more than 60 minutes to run although it lasts less than 25 minutes before.v1.7Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/133SeriesAggreg: Reorder regime time series and keep original data.frame column ...2021-07-15T09:56:33+02:00Delaigue OlivierSeriesAggreg: Reorder regime time series and keep original data.frame column names
## Row order
When a user wants to calculate the monthly regime from a time series that does not start in January, the resulting time series is not ordered chronologically:
```r
## loading catchment data
data(L0123002)
## preparation...
## Row order
When a user wants to calculate the monthly regime from a time series that does not start in January, the resulting time series is not ordered chronologically:
```r
## loading catchment data
data(L0123002)
## preparation of the initial time series data frame at the daily time step
TabSeries <- BasinObs[-c(1:100), c("DatesR", "P", "E", "T", "Qmm")]
## monthly regimes
NewTabSeries <- SeriesAggreg(TabSeries,
Format = "%m",
ConvertFun = c("sum", "sum", "mean", "sum"))
NewTabSeries
```
```
DatesR P E T Qmm
25 1985-01-01 4561.75 0.000 -4.38509320 801.5458
1638 1985-02-01 3628.40 137.333 -3.19772073 885.9376
2514 1985-03-01 3285.26 918.967 -0.06520829 1419.2986
3204 1984-04-10 2951.83 1945.714 3.62350569 3228.6649
4204 1984-05-01 3039.24 3060.999 7.44770178 6952.6141
5151 1984-06-01 2550.69 3655.168 11.41753270 5886.3055
6049 1984-07-01 1463.55 3980.017 15.21047230 1728.8110
6857 1984-08-01 1369.97 3609.238 15.05654527 528.8462
7770 1984-09-01 1914.48 2685.482 10.52281546 407.1385
8724 1984-10-01 2596.42 1697.494 4.53778871 487.0308
9587 1984-11-01 4752.38 645.070 -2.62700563 750.2040
10440 1984-12-01 4870.14 44.293 -5.27928687 903.0798
```
This can lead to a counter-intuitive behavior...
```r
plot(NewTabSeries[, c("DatesR", "Qmm")], type = "l")
```
![image](/uploads/c1dbe9fff6950039947a5eb5446976f1/image.png)
One possibility is to reorder the table by the date culumn. The other solution, which I prefer, is to impose the same year (which doesn't really make sense).
## Column names
Another problem that we have already talked about. But the function automatically renames the date column of a data.frame, which is not very polite to the user.
```r
## preparation of the initial time series data frame at the daily time step
TabSeries <- BasinObs[-c(1:100), c("DatesR", "P", "E", "T", "Qmm")]
colnames(TabSeries) <- LETTERS[1:5]
## monthly regimes
NewTabSeries <- SeriesAggreg(TabSeries,
Format = "%m",
ConvertFun = c("sum", "sum", "mean", "sum"))
head(NewTabSeries)
```
```
DatesR B C D E
25 1985-01-01 4561.75 0.000 -4.38509320 801.5458
1638 1985-02-01 3628.40 137.333 -3.19772073 885.9376
2514 1985-03-01 3285.26 918.967 -0.06520829 1419.2986
3204 1984-04-10 2951.83 1945.714 3.62350569 3228.6649
4204 1984-05-01 3039.24 3060.999 7.44770178 6952.6141
5151 1984-06-01 2550.69 3655.168 11.41753270 5886.3055
```v1.7https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/131RunModel_Lag: extra `names` attribute on `OutputsModel$Qsim`2021-07-09T18:56:19+02:00Dorchies DavidRunModel_Lag: extra `names` attribute on `OutputsModel$Qsim`Following the modifications of #123, *airGRiwrm* has failed tests as described in in-wop/airGRiwrm#50
When using `Qupstream` for initial states of the lag model, `OutputsModel$Qsim` has an attribute "names" with empty strings.
This att...Following the modifications of #123, *airGRiwrm* has failed tests as described in in-wop/airGRiwrm#50
When using `Qupstream` for initial states of the lag model, `OutputsModel$Qsim` has an attribute "names" with empty strings.
This attribute must be removed in any case.v1.7Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/108RunModel_Lag crashes when called from RunModel2021-04-18T07:52:00+02:00Dorchies DavidRunModel_Lag crashes when called from RunModelTry this:
```
library(airGR)
example(RunModel_Lag)
OutputsModel <- RunModel(InputsModel = InputsModel,RunOptions = RunOptions, Param = Velocity, FUN_MOD = RunModel_Lag)
```
The following error occurs:
`Error in rep(0, floor(PT[x] + 1))...Try this:
```
library(airGR)
example(RunModel_Lag)
OutputsModel <- RunModel(InputsModel = InputsModel,RunOptions = RunOptions, Param = Velocity, FUN_MOD = RunModel_Lag)
```
The following error occurs:
`Error in rep(0, floor(PT[x] + 1)) : invalid 'times' argument`
@olivier.delaigue and @guillaume.thirel, despite what we discussed, I think it looks like a normal way of using the model as we use the other ones.v1.6.11Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/106RunModel_CemaNeige fails in CreateInputsModel at the hourly time step2021-04-23T10:50:55+02:00François BourginRunModel_CemaNeige fails in CreateInputsModel at the hourly time stepThe description of `RunModel_CemaNeige {airGR}` states:
> Function which performs a single run for the CemaNeige snow module at the daily or hourly time step.
Unfortunately, `CreateInputsModel` does not work at the hourly time step beca...The description of `RunModel_CemaNeige {airGR}` states:
> Function which performs a single run for the CemaNeige snow module at the daily or hourly time step.
Unfortunately, `CreateInputsModel` does not work at the hourly time step because of the following lines:
```
if (identical(FUN_MOD, RunModel_CemaNeige)) {
ObjectClass <- c(ObjectClass, "daily", "CemaNeige")
TimeStep <- as.integer(24 * 60 * 60)
BOOL <- TRUE
}
```v1.6.11https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/105Using wrong precipitation inputs when calling GR5H in CemaNeigeGR5H ?2021-03-23T16:55:24+01:00François BourginUsing wrong precipitation inputs when calling GR5H in CemaNeigeGR5H ?I was trying to understand why CemaNeigeGR5H was not as good as CemaNeigeGR4H on my case study and I found a difference in the two calls for .Fortran functions (``frun_gr4h`` and ``frun_gr5h``):
In CemaNeigeGR4H:
``InputsPrecip = CatchM...I was trying to understand why CemaNeigeGR5H was not as good as CemaNeigeGR4H on my case study and I found a difference in the two calls for .Fortran functions (``frun_gr4h`` and ``frun_gr5h``):
In CemaNeigeGR4H:
``InputsPrecip = CatchMeltAndPliq``
In CemaNeigeGR5H:
``InputsPrecip = InputsModel$Precip[IndPeriod1]``
Does it mean that the snow melt is not taken into account in CemaNeigeGR5H ?
CemaNeigeGR5J looks fine.v1.6.11https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/104RunModel_Lag: `StateEnd` is wrong if upstream flow is in mm / time step2021-04-06T15:01:00+02:00Dorchies DavidRunModel_Lag: `StateEnd` is wrong if upstream flow is in mm / time stepIn the lag model upstream flows related to a sub-basin are converted from mm / time step to m3 / time step. Initial states and upstream flows are merged in order to have the memory of the upstream flows before the simulation period but n...In the lag model upstream flows related to a sub-basin are converted from mm / time step to m3 / time step. Initial states and upstream flows are merged in order to have the memory of the upstream flows before the simulation period but no conversion is applied to initial states.
So the initial states should either be converted if they are stored in mm/ts or stored in m3/ts.
There are pro and cons for the 2 solutions:
1. store states in mm / ts and converted in simulation: `Qupstream` is already in mm/ts so it seems consistent to store the corresponding initial state (which is `Qupstream` before the simulation period) in the same unity.
2. store states in m3/ts and use it directly in simulation which can avoid a computation burden due to a conversion at each run.
Concerning the second solution, maybe it could be a good idea to also convert `Qupstream` in m3/ts in `CreateInputsModel` in order to avoid an "on-the-fly" conversion at each run of `RunModel_Lag`. So, all upstream flows (States + Qupstream) would be in m3/ts and no computation burden would occur due to conversion.v1.6.11Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/103RunModel_Lag: `StateEnd` is wrong in case of more than 1 upstream basin2021-03-24T14:41:19+01:00Dorchies DavidRunModel_Lag: `StateEnd` is wrong in case of more than 1 upstream basinThe code refers to the variable `Qupstream` which is the flow of the last upstream flow processed in the loop of lag calculation:
```r
OutputsModel$StateEnd$SD <- lapply(seq(NbUpBasins), function(x) {
Qupstream[(LengthTs - floor(...The code refers to the variable `Qupstream` which is the flow of the last upstream flow processed in the loop of lag calculation:
```r
OutputsModel$StateEnd$SD <- lapply(seq(NbUpBasins), function(x) {
Qupstream[(LengthTs - floor(PT[x])):LengthTs]
})
```
It should refer to `InputsModel$Qupstream` which is the matrix of all upstream flows.v1.6.11Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/102RunModel_Lag returns 2 values for a one time step run2021-03-24T14:41:19+01:00Dorchies DavidRunModel_Lag returns 2 values for a one time step runThe example below tries to run a daily SD model for the time step `1990-01-01` (adapted from `tests\testthat\test-RunModel_Lag.R`):
```r
library(airGR)
data(L0123001)
BasinAreas <- c(BasinInfo$BasinArea, BasinInfo$BasinArea)
# Qupstream...The example below tries to run a daily SD model for the time step `1990-01-01` (adapted from `tests\testthat\test-RunModel_Lag.R`):
```r
library(airGR)
data(L0123001)
BasinAreas <- c(BasinInfo$BasinArea, BasinInfo$BasinArea)
# Qupstream = sinusoid synchronised on hydrological year from 0 mm to mean value of Qobs
Qupstream <- floor((sin((seq_along(BasinObs$Qmm)/365*2*3.14))+1) * mean(BasinObs$Qmm, na.rm = TRUE))
InputsModel <- CreateInputsModel(
FUN_MOD = RunModel_GR4J,
DatesR = BasinObs$DatesR,
Precip = BasinObs$P,
PotEvap = BasinObs$E,
Qupstream = matrix(Qupstream, ncol = 1),
LengthHydro = 1000,
BasinAreas = BasinAreas
)
Ind_Run <- seq(which(format(BasinObs$DatesR, format = "%Y-%m-%d") == "1990-01-01"),
which(format(BasinObs$DatesR, format = "%Y-%m-%d") == "1990-01-01"))
RunOptions <- suppressWarnings(CreateRunOptions(FUN_MOD = RunModel_GR4J,
InputsModel = InputsModel,
IndPeriod_Run = Ind_Run))
Param <- c(1., 257.237556, 1.012237, 88.234673, 2.207958)
OutputsModel <- RunModel(InputsModel = InputsModel, RunOptions = RunOptions, Param = Param, FUN_MOD = RunModel_GR4J)
OutputsModel$Qsim
```
The output of this code is:
```r
> OutputsModel$Qsim
[1] 1.709998 1.715785
```
The error comes from the lines in `R\RunModel_Lag.R`:
```r
OutputsModel$Qsim <- OutputsModel$Qsim +
c(IniStates[[upstream_basin]][-length(IniStates[[upstream_basin]])],
Qupstream[1:(LengthTs - floor(PT[upstream_basin]))]) *
HUTRANS[1, upstream_basin] +
c(IniStates[[upstream_basin]],
Qupstream[1:(LengthTs - floor(PT[upstream_basin]) - 1)]) *
HUTRANS[2, upstream_basin]
```
Especially from the expression `(LengthTs - floor(PT[upstream_basin]) - 1)` which is equal to zero when `LengthTs = 1`. Initial states and Qupstream should be merge only if we need to address them.
I tried locally to solve the problem with this solution:
```r
Qupstream1 <- c(IniStates[[upstream_basin]][-length(IniStates[[upstream_basin]])], Qupstream[1:(LengthTs - floor(PT[upstream_basin]))])
Qupstream2 <- IniStates[[upstream_basin]]
if(LengthTs - floor(PT[upstream_basin]) - 1 > 0) Qupstream2 <- c(Qupstream2, Qupstream[1:(LengthTs - floor(PT[upstream_basin]) - 1)])
OutputsModel$Qsim <- OutputsModel$Qsim +
Qupstream1 * HUTRANS[1, upstream_basin] +
Qupstream2 * HUTRANS[2, upstream_basin]
```v1.6.11Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/101Fix vignette "Plugging in new calibration algorithms in airGR"2021-03-25T16:25:03+01:00François BourginFix vignette "Plugging in new calibration algorithms in airGR"The starting points used for the multi-start approach are in the real space, while they should be in the transformed space.
The line
```
startGR4J <- expand.grid(data.frame(CalibOptions$StartParamDistrib))
```
should be replaced by
`...The starting points used for the multi-start approach are in the real space, while they should be in the transformed space.
The line
```
startGR4J <- expand.grid(data.frame(CalibOptions$StartParamDistrib))
```
should be replaced by
```
StartParamDistrib <- matrix(c(+5.13, -1.60, +3.03, -9.05,
+5.51, -0.61, +3.74, -8.51,
+6.07, -0.02, +4.42, -8.06), ncol = 4, byrow = TRUE)
startGR4J <- expand.grid(data.frame(StartParamDistrib))
```
or perhaps, by a more diverse list of starting points sampled in the transformed space if we want to find local optima.v1.6.11https://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/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/73Check conditionnal test in Calibration2021-01-06T11:49:19+01: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/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 Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/65PotEvap and Precip are reversed in RunModel_GR1A outputs2021-01-07T17:44:39+01:00Delaigue OlivierPotEvap and Precip are reversed in RunModel_GR1A outputsPotEvap and Precip are reversed in the RunModel_GR1A outputs.
The code of the GR1A is duplicated in the `RunModel_GR1A()` function. The code is written in R and in Fortran. It is the R code that is used to run the model. All `RunModel_*(...PotEvap and Precip are reversed in the RunModel_GR1A outputs.
The code of the GR1A is duplicated in the `RunModel_GR1A()` function. The code is written in R and in Fortran. It is the R code that is used to run the model. All `RunModel_*()` functions return first PotEvap and second Precip, but it is inversed in the GR1A R code (not in the Fortran code):
```
PEQ <- rbind(c(NA,NA,NA),cbind(P1,E1,Q1))
```
Maybe it is a good idea to remove this R code.v1.6.10