airGR issueshttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues2023-10-19T18:06:50+02:00https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/182Correct vignette due to 'hydroPSO' was removed from the CRAN repository2023-10-19T18:06:50+02:00Delaigue OlivierCorrect vignette due to 'hydroPSO' was removed from the CRAN repositoryProf Brian Ripley
16 October 2023 13:03
```
Dear maintainer,
Please see the problems shown on
<https://cran.r-project.org/web/checks/check_results_airGR.html>.
Please correct before 2023-10-30 to safely retain your package on CRAN.
...Prof Brian Ripley
16 October 2023 13:03
```
Dear maintainer,
Please see the problems shown on
<https://cran.r-project.org/web/checks/check_results_airGR.html>.
Please correct before 2023-10-30 to safely retain your package on CRAN.
Packages in Suggests should be used conditionally: see 'Writing R Extensions'.
This needs to be corrected even if the missing package(s) become available.
It can be tested by checking with _R_CHECK_DEPENDS_ONLY_=true.
The CRAN Team
```v1.7.6https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/178frun_CemaNeige.f90: case dG = 0 not considered2023-10-23T17:34:05+02:00Thirel Guillaumefrun_CemaNeige.f90: case dG = 0 not consideredIn frun_CemaNeige.f90, the case when dG = 0 is not taken into account. It can result in a Gratio that is set and stays equal to 1 when small solid precipitation occurs and melts on the same day. I propose to correct that by modifying lin...In frun_CemaNeige.f90, the case when dG = 0 is not taken into account. It can result in a Gratio that is set and stays equal to 1 when small solid precipitation occurs and melts on the same day. I propose to correct that by modifying line 187
` IF (dG.LT.0.) THEN`
becomes
` IF (dG.LE.0.) THEN`
Attached is the modified file, as well as the output of a simulation where this bug is activated.
Bug identified by @francois.bourgin and Thibault Hallouin.
[frun_CEMANEIGE.f90](/uploads/c8331d51d796ee6d0495b454903f8444/frun_CEMANEIGE.f90)
[bug_sca.csv](/uploads/f48eb420cd3ca73f00724f3813999659/bug_sca.csv)v1.7.6https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/172Correct vignette due to 'Rmalschains' was removed from the CRAN repository2023-10-20T10:20:53+02:00Delaigue OlivierCorrect vignette due to 'Rmalschains' was removed from the CRAN repositoryProf Brian Ripley
3 April 2023 10:05
```
Dear maintainer,
Please see the problems shown on
<https://cran.r-project.org/web/checks/check_results_airGR.html>.
Please correct before 2023-04-17 to safely retain your package on CRAN.
...Prof Brian Ripley
3 April 2023 10:05
```
Dear maintainer,
Please see the problems shown on
<https://cran.r-project.org/web/checks/check_results_airGR.html>.
Please correct before 2023-04-17 to safely retain your package on CRAN.
Packages in Suggests should be used conditionally: see 'Writing R Extensions'.
This needs to be corrected even if the missing package(s) become available.
It can be tested by checking with _R_CHECK_DEPENDS_ONLY_=true.
The CRAN Team
```v1.7.4https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/171Check error: Direct call of 'as.data.frame.POSIXct()' is deprecated. Use 'as...2023-10-24T11:05:59+02:00Dorchies DavidCheck error: Direct call of 'as.data.frame.POSIXct()' is deprecated. Use 'as.data.frame.vector()' or 'as.data.frame()' insteadThis error has raised on the check for devel version of R since 16th of December.
It needs to be fixed for the next release.This error has raised on the check for devel version of R since 16th of December.
It needs to be fixed for the next release.v1.7.6https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/156RunModel_Lag: wrong values in parameter screening2023-10-19T18:08:39+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.7.6Dorchies 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.7.0https://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.7.0https://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.7.0https://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.7.0Dorchies 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.7.0https://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.7.0Dorchies 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.10