airGR issueshttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues2020-02-12T10:11:58+01:00https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/1Error in TransfoParam_GR1A: wrong number of parameters2020-02-12T10:11:58+01:00Thirel GuillaumeError in TransfoParam_GR1A: wrong number of parametersThe number of parameters is wrongly defined in `TransfoParam_GR1A`:
` NParam <- 1L
NParam <- 2L`
The second line is to be removed.
This only impacts the `Calibration_Michel` algorithm, not `RunModel_GR1A`.The number of parameters is wrongly defined in `TransfoParam_GR1A`:
` NParam <- 1L
NParam <- 2L`
The second line is to be removed.
This only impacts the `Calibration_Michel` algorithm, not `RunModel_GR1A`.Delaigue OlivierDelaigue Olivier2019-11-05https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/165Add missing 'IsIntStore' argument in 'CreateCalibOptions'2022-09-12T11:08:54+02:00Delaigue OlivierAdd missing 'IsIntStore' argument in 'CreateCalibOptions'The 'IsIntStore' argument has been unfortunatly removed since commit 29284029.
In fact, this argument is needed to choose the right set of transformed parameter uses at the grid-screening step (see `..StartParamTransfo()` in `CreateCal...The 'IsIntStore' argument has been unfortunatly removed since commit 29284029.
In fact, this argument is needed to choose the right set of transformed parameter uses at the grid-screening step (see `..StartParamTransfo()` in `CreateCalibOptions()`).
Currently the GR5H model used with the interception store uses the set of transformed parameter optimized for GR5H without interception. The paremeter set found during the calibtation step is not as good as expected.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/160Conversion of LayerFracSolidPrecip in SeriesAggreg2022-07-28T17:08:30+02:00Thirel GuillaumeConversion of LayerFracSolidPrecip in SeriesAggreg`LayerFracSolidPrecip` is converted through a sum in `SeriesAggreg`. `LayerFracSolidPrecip` is a fraction, so it cannot be converted with a sum. An average would be less incorrect, although definitely not perfectly correct. A better way ...`LayerFracSolidPrecip` is converted through a sum in `SeriesAggreg`. `LayerFracSolidPrecip` is a fraction, so it cannot be converted with a sum. An average would be less incorrect, although definitely not perfectly correct. A better way would be to recalculate liquid and solid precipitation, to aggregate them, and then to recalculate `LayerFracSolidPrecip` as the ratio.https://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/154Error in vignettes\V03_param_sets_GR4J.Rmd2022-05-18T10:54:53+02:00Dorchies DavidError in vignettes\V03_param_sets_GR4J.RmdLine 203-204:
```r
OutputsModel_Cal <- RunModel(InputsModel = InputsModel, RunOptions = RunOptions_Cal,
Param = OutputsCalib$ParamFinalR, FUN = RunModel_GR4J)
```
The argument should be `FUN_MOD` instead o...Line 203-204:
```r
OutputsModel_Cal <- RunModel(InputsModel = InputsModel, RunOptions = RunOptions_Cal,
Param = OutputsCalib$ParamFinalR, FUN = RunModel_GR4J)
```
The argument should be `FUN_MOD` instead of `FUN`.
This huge bug was not detected before because the chunk is flagged `include=FALSE` instead of `eval=FALSE` so it is not run in the automatic tests.
TODO:
- [ ] Change `FUN` to `FUN_MOD`
- [ ] Change `include` to `eval`https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/149SeriesAggreg: handling diverse input time steps correctly2022-03-14T11:23:19+01:00Dorchies DavidSeriesAggreg: handling diverse input time steps correctlyI tried to aggregate a 15 minutes time step time series to monthly time step and here is the result:
```r
> d <- seq.POSIXt(from = as.POSIXct("2020-01-01 00:00:00", tz = "UTC"),
+ to = as.POSIXct("2021-12-31 23:59:59", ...I tried to aggregate a 15 minutes time step time series to monthly time step and here is the result:
```r
> d <- seq.POSIXt(from = as.POSIXct("2020-01-01 00:00:00", tz = "UTC"),
+ to = as.POSIXct("2021-12-31 23:59:59", tz = "UTC"),
+ by = "15 min")
> df <- data.frame(d = d, v = 1)
> QM <- SeriesAggreg(df, Format = "%Y%m", ConvertFun = "sum")
Warning message:
In SeriesAggreg.data.frame(df, Format = "%Y%m", ConvertFun = "sum") :
the requested time 'Format' is the same as the one in 'x'. No time-step conversion was performed
```
Maybe I was foolish to try to use other time steps than the ones handle by GR models... The strange thing is that yearly aggregation doesn't warn and send a bad result:
```r
> QY <- SeriesAggreg(df, Format = "%Y", ConvertFun = "sum")
> str(QY)
'data.frame': 2 obs. of 2 variables:
$ d: POSIXct, format: "2020-01-01" "2021-01-01"
$ v: num 12 12
```https://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/119Fix 'baseflow' reverse dependency2021-11-03T14:11:39+01:00Delaigue OlivierFix 'baseflow' reverse dependency'airGR' v1.6.11 breaks the CRAN version of the 'baseflow' package. The error was not returned by the automated reverse dependency checking that is running using 'revdepcheck' during the pipeline, but it was detected by the one of the CRA...'airGR' v1.6.11 breaks the CRAN version of the 'baseflow' package. The error was not returned by the automated reverse dependency checking that is running using 'revdepcheck' during the pipeline, but it was detected by the one of the CRAN.
The following error appears only when 'airGR' is not attached before running the example. I don't see where the 'revdepcheck' package does this automatically (by using `library()` or something else that causes the same behavior).
```
Package check result: OK
Changes to worse in reverse depends:
Package: baseflow
Check: examples
New result: ERROR
Running examples in 'baseflow-Ex.R' failed
The error most likely occurred in:
> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: BaseflowFilter
> ### Title: Constructor function of class 'BaseflowFilter'
> ### Aliases: BaseflowFilter
> ### Keywords: manip
>
> ### ** Examples
>
> library(baseflow)
>
> # Loading example data from airGR package
> data(L0123001, package = 'airGR')
>
> # Defining BasinData object
>
> Name <- BasinInfo$BasinName
> startDate <- BasinObs$DatesR[1]
> endDate <- BasinObs$DatesR[length(BasinObs$DatesR)]
> P <- BasinObs$P
> PET <- BasinObs$E
> Qobs <- BasinObs$Qmm
>
> BasinData_Example <- BasinData(Name, startDate, endDate, P, PET, Qobs, fill = "GR4J")
Error in FUN(X[[i]], ...) : object 'RunModel_GR1A' not found
Calls: BasinData ... CreateInputsModel -> .GetFeatModel -> lapply -> FUN
```v1.8https://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.11