airGR issues
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues
2023-10-26T10:58:38+02:00
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/185
Add 'hydroPSO' package in the 'Suggests' list
2023-10-26T10:58:38+02:00
Delaigue Olivier
Add 'hydroPSO' package in the 'Suggests' list
When the 'hydroPSO' package will be available again on CRAN, we will have to:
- complete the Suggests' list in the `DESCRIPTION` file
- update the `V02.1_param_optim` vignette
- update the `.vignettechunkignore` file
When the 'hydroPSO' package will be available again on CRAN, we will have to:
- complete the Suggests' list in the `DESCRIPTION` file
- update the `V02.1_param_optim` vignette
- update the `.vignettechunkignore` file
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/181
CreateRunOptions and RunModel_GR5H* do not crash when Imax set to NULL
2023-10-26T11:23:17+02:00
Thirel Guillaume
CreateRunOptions and RunModel_GR5H* do not crash when Imax set to NULL
See
```
library(airGR)
## load of catchment data
data(L0123003)
## preparation of the InputsModel object
InputsModel <- CreateInputsModel(FUN_MOD = RunModel_GR5H, DatesR = BasinObs$DatesR,
Precip = Ba...
See
```
library(airGR)
## load of 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_Run <- 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"))
## preparation of the RunOptions object
RunOptions <- CreateRunOptions(FUN_MOD = RunModel_GR5H, Imax = NULL,
InputsModel = InputsModel, IndPeriod_Run = Ind_Run)
```
It gives a warning for something else, but no error:
```
Warning message:
In CreateRunOptions(FUN_MOD = RunModel_GR5H, Imax = NULL, InputsModel = InputsModel, :
model warm up period not defined: default configuration used
the year preceding the run period is used
```
That is not desirable in my opinion (someone I know just made wrong simulations for this reason due to a bad reading of Imax values).
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/179
RunModel_CemaNeige fails in CreateIniStates at the hourly time step
2023-10-26T11:23:22+02:00
Thebault Cyril
RunModel_CemaNeige fails in CreateIniStates at the hourly time step
When I try to use RunModel_CemaNeige alone (without GR models) at the hourly time step, the following error appear:
`UH1' must be numeric of length 480 (20 * 24)`
The error appear because in CreateIniStates, the following condition `if...
When I try to use RunModel_CemaNeige alone (without GR models) at the hourly time step, the following error appear:
`UH1' must be numeric of length 480 (20 * 24)`
The error appear because in CreateIniStates, the following condition `if ("CemaNeige" %in% ObjectClass & ! "GR" %in% ObjectClass)` leads to a `UH1` set to `rep(Inf, UH1n)` instead of `rep(Inf, UH1n*k)`. This error appear also with `UH2`. Note that the `k` value is defined later in the script as:
```r
if ("hourly" %in% ObjectClass) {
k <- 24
} else {
k <- 1
}
```
I suggest therefore to move this part at the beginning of the function CreateIniStates and after that to define everywhere UH1 and UH2 as
rep(Inf, UH1n*k).
PS: The examples with CemaNeige at the hourly time step can't be run, the U2345030 catchment is not included in the package (and we can't use another catchment included in the package because they either have temperature data or hourly data, but never both).
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/177
RunModel_Lag: negative Qsim during Calibration produces NaNs
2024-03-27T14:24:06+01:00
Dorchies David
RunModel_Lag: negative Qsim during Calibration produces NaNs
In case of a simulation with Direct Injection abstracting to much water, the downstream flow simulated by `RunModel_Lag` can be negative. But there is a piece of code to cap it to zero:
```r
if (length(RunOptions$Outputs_Sim) > 2) {
...
In case of a simulation with Direct Injection abstracting to much water, the downstream flow simulated by `RunModel_Lag` can be negative. But there is a piece of code to cap it to zero:
```r
if (length(RunOptions$Outputs_Sim) > 2) {
if (any(OutputsModel$Qsim[!is.na(OutputsModel$Qsim)] < 0)) {
warning(length(which(OutputsModel$Qsim < 0)), " time steps with negative flow, set to zero.")
OutputsModel$Qsim[OutputsModel$Qsim < 0] <- 0
}
# Warning for NAs
if (any(is.na(OutputsModel$Qsim))) {
warning(length(which(is.na(OutputsModel$Qsim))), " time steps with NA values")
}
}
```
Unfortunately the assignation to zero is in a condition that is not met during calibration. In case of using a square root transformation for the error criterion, the criterion produces NaNs with a lot of warnings.
Planned solution: move the cap to zero outside the condition linked to the warning (see code above) in order to make it systematic.
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/176
CreateIniStates: Huge computation time spent on GetFeatModel
2023-10-26T11:23:40+02:00
Dorchies David
CreateIniStates: Huge computation time spent on GetFeatModel
The Rstudio profiler on airGRiwrm calibration with ungauged nodes returns this result:
![image](/uploads/2a1ef7ba9e8378e269332851c470569c/image.png)
We see that on 3.46 sec of calculation, 1.62 sec are spent in `CreateIniStates` and es...
The Rstudio profiler on airGRiwrm calibration with ungauged nodes returns this result:
![image](/uploads/2a1ef7ba9e8378e269332851c470569c/image.png)
We see that on 3.46 sec of calculation, 1.62 sec are spent in `CreateIniStates` and especially in the call to `.GetFeatModel` which take a lot of time to run `system.file` and `read.table`.
One first quick solution would be to add in `Calibration`, a copy of model features from `RunOptions` to `InputsModel` in order to provide them to `CreateIniStates` through `InputsModel`.
If we think of more structured solution, model features could be attached from the beginning to the `InputsModel` object and propagated to all subsequent objects used in simulation/calibration without the need to call again the expensive `.GetFeatModel` function. This point of view change substantially the call to airGR functions because we would need to precise `IsSD` and `IsHyst` parameters in the `CreateInputsModel` call. This also would simplify the calls to other `Create...` functions which would not need these parameters anymore.
@guillaume.thirel, @olivier.delaigue, if you agree with this point of view, this proposed solution needs further investigation in order to avoid breaking changes and take into account any legacy and new call to airGR functions. Maybe in a separated ticket issue ?
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/170
Move the project in the airGRgalaxy repository
2023-02-14T13:02:13+01:00
Delaigue Olivier
Move the project in the airGRgalaxy repository
- [ ] Move the project into the [airGRgalaxy group](https://gitlab.irstea.fr/HYCAR-Hydro/airgrgalaxy)
- [ ] Update the **URL** and **BugReports** items in the DESCRIPTION file
- [ ] Move the project into the [airGRgalaxy group](https://gitlab.irstea.fr/HYCAR-Hydro/airgrgalaxy)
- [ ] Update the **URL** and **BugReports** items in the DESCRIPTION file
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/169
Fix GR pathology
2023-10-26T11:24:06+02:00
Thirel Guillaume
Fix GR pathology
Issue initially reported to Vazken and Charles by Wouter Knoben on the Excel GR4J in 2017, also reported recently by @laurent.strohmenger on GR5J recently.
Note: this issue concerns airGR but is not specific to the package, it comes fr...
Issue initially reported to Vazken and Charles by Wouter Knoben on the Excel GR4J in 2017, also reported recently by @laurent.strohmenger on GR5J recently.
Note: this issue concerns airGR but is not specific to the package, it comes from the GR implementation.
Under some conditions (i.e. some parameters sets, some climatic conditions), the lower part of the GR models, namely the routing store and the exchange component, enter in a mode where it cannot escape anymore. Due to a positive X2 and a positive exchange larger than the routing store outflow, the routing store comes to an equilibrium and a non null discharge is produced, even though no more rainfall is injected.
This is very annoying, as the simulation quality becomes very poor. This issue may not be found under calibration, because a low objective function would lead to avoid these parameter sets, but some parameter sets can look ok under calibration and then give erroneous simulations, under a different climate for instance (e.g. high rainfall).
Included is the email exchange with Wouter Knoben colleagues.
[GR4J_pathology_Knoben.docx](/uploads/715ff50a3c0232a3125178db848fdc15/GR4J_pathology_Knoben.docx)
Attached also an R code reproducing the bug proposed by @laurent.strohmenger and augmented by the translation in R of the GR5J routing part producing the bug. It shows that X2 does not need to be larger than X3, oppositely to what was discussed in 2017.
[GR5J_bug.R](/uploads/4fc1d93321a41a052546d69d9b435427/GR5J_bug.R)
There is no solution to date, but this must be cured.
v2.0
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/167
CreateRunOptions: crash with RunModel_Lag
2022-11-27T10:04:52+01:00
Dorchies David
CreateRunOptions: crash with RunModel_Lag
The example provided for `RunModel_Lag` is incoherent. Both `CreateInputsModel` and `CreateRunOptions` uses `FUN_MOD = RunModelGR4J` to work. If, in example, we try to change the argument to `FUN_MOD = RunModel_Lag`, CreateRunOptions cra...
The example provided for `RunModel_Lag` is incoherent. Both `CreateInputsModel` and `CreateRunOptions` uses `FUN_MOD = RunModelGR4J` to work. If, in example, we try to change the argument to `FUN_MOD = RunModel_Lag`, CreateRunOptions crashes:
```r
> InputsModelInf <- CreateInputsModel(FUN_MOD = RunModel_Lag, DatesR = BasinObs$DatesR,
+ Precip = BasinObs$P, PotEvap = BasinObs$E,
+ Qupstream = Qupstream, LengthHydro = LengthHydro,
+ BasinAreas = BasinAreas)
> RunOptions <- CreateRunOptions(FUN_MOD = RunModel_Lag,
+ InputsModel = InputsModelInf, IndPeriod_Run = Ind_Run)
Error in rep(0, NState) : invalid 'times' argument
```
This is due to the fact that:
```
> class(InputsModelInf)
[1] "InputsModel" "daily" "SD" "SD"
```
And in `CreateRunOptions` there is a test for defining the size of the initial state vector restricted to `if ("GR" %in% ObjectClass | "CemaNeige" %in% ObjectClass)` and therefore `Nstate` is `NULL` when proceeding to the creation of the initial state vector.
I see 2 solutions:
- Define the default value of `NState <- 0` instead of `NULL` which could be generic to any future model outside GR family assuming the lack of initial state
- Systematically call `CreateIniStates` with proper parameters for the cases where the parameter `IniStates` is NULL (I have tested it with `IniStates = CreateIniStates(RunModel_Lag, InputsModel)`, it works).
v1.8
Dorchies David
Dorchies David
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/166
Update GR5H interception grid-screening parameter quantiles
2022-09-13T14:58:36+02:00
Delaigue Olivier
Update GR5H interception grid-screening parameter quantiles
According to the tests made by @cyril.thebault on the ~579 catchments, it seems to be needed to update the GR5H interception parameter quantiles used during the grid-screening calibration step.
Current values:
```r
GR5Hinterception = ...
According to the tests made by @cyril.thebault on the ~579 catchments, it seems to be needed to update the GR5H interception parameter quantiles used during the grid-screening calibration step.
Current values:
```r
GR5Hinterception = matrix(c(+3.46, -1.25, +4.04, -9.53, -9.34,
+3.74, -0.41, +4.78, -8.94, -3.33,
+4.29, +0.16, +5.39, -7.39, +3.33), ncol = 5, byrow = TRUE)
```
New values (found after 4 convergence loops):
```r
GR5Hinterception = matrix(c(+4.92, -0.17, +4.27, -9.81, -9.29,
+5.42, -0.07, +4.94, -9.66, -7.36,
+6.05, -0.01, +5.63, -9.26, -5.55), ncol = 5, byrow = TRUE)
```
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/165
Add missing 'IsIntStore' argument in 'CreateCalibOptions'
2022-09-12T11:08:54+02:00
Delaigue Olivier
Add 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.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/164
Using Epsilon in CreateInputsCrit
2023-10-26T11:24:26+02:00
Thebault Cyril
Using Epsilon in CreateInputsCrit
I have some issues with the use of epsilon in CreateInputsCrit.
The RDocumentation says:
(optional) [numeric (atomic or list)] small value to add to all observations and simulations **when "log" or "inv" transformations are used** [same...
I have some issues with the use of epsilon in CreateInputsCrit.
The RDocumentation says:
(optional) [numeric (atomic or list)] small value to add to all observations and simulations **when "log" or "inv" transformations are used** [same unit as Obs]. See details
However when we go to the details the epsilon value have an effect on **every transformation except for "boxcox"**.
It's a bit contradictory...
In addition, only "log" and "inv" transformations are checked for the warning "zeroes detected in Obs: the corresponding time-steps will be excluded by the 'ErrorCrit*' functions as the epsilon argument was set to NULL". We should expand this warning to any power function < 0 (ex: transfo = -0.5).
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/163
Allow using CreateInputsCrit_Lavenne with composite criteria
2023-10-26T11:24:21+02:00
Thirel Guillaume
Allow using CreateInputsCrit_Lavenne with composite criteria
We could modify airGR::CreateInputsCrit_Lavenne to allow using composite criteria when a list of Weights is given. The Weights given by the CreateInputsCrit_Lavenne outputs would then be Weights = c((1 - k)*Weights[1], ..., (1 - k)*Weigh...
We could modify airGR::CreateInputsCrit_Lavenne to allow using composite criteria when a list of Weights is given. The Weights given by the CreateInputsCrit_Lavenne outputs would then be Weights = c((1 - k)*Weights[1], ..., (1 - k)*Weights[n], k * max(0, AprCrit)) instead of Weights = c(1 - k, k * max(0, AprCrit)).
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/162
Add the streamflow-streamflow (Q-Q) model within airGR
2022-08-04T18:31:53+02:00
Pierre BRIGODE
Add the streamflow-streamflow (Q-Q) model within airGR
Add the streamflow-streamflow (Q-Q) model used by [Andréassian et al. (2012)](https://doi.org/10.1016/j.jhydrol.2011.10.007) in the airGR package (and then, in the airGRteaching) ?
Add the streamflow-streamflow (Q-Q) model used by [Andréassian et al. (2012)](https://doi.org/10.1016/j.jhydrol.2011.10.007) in the airGR package (and then, in the airGRteaching) ?
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/161
RunModel_Lag: proposal for a better transformation and screening of the param...
2023-02-02T14:04:02+01:00
Dorchies David
RunModel_Lag: proposal for a better transformation and screening of the parameters
The work of Enola Henrotin highlights some issues with the calibration of the lag model. These issues are essentially due to an inadequate transformation of the celerity parameter.
The document below summarizes these issues and proposes...
The work of Enola Henrotin highlights some issues with the calibration of the lag model. These issues are essentially due to an inadequate transformation of the celerity parameter.
The document below summarizes these issues and proposes a new transformation and a set of screening values from experimental measurements of flow velocities in a various rivers:
[Sensibility-of-celerity-parameter-on-Lag-model.html](/uploads/ea137265ad43a30113926721c4497ca1/Sensibility-of-celerity-parameter-on-Lag-model.html)
The proposed formulas are (respectively for the transformed and the real parameter):
```math
C_{T} = \dfrac{120}{299C_{0}} - \dfrac{3010}{299} \\
C_0 = \dfrac{120}{299 (C_T + 3010 / 299)}
```
The proposed screening values of transformed parameter are: -9.7; -8.7; -2.0
Sources of the document:
- [Sensibility_of_celerity_parameter_on_Lag_model.Rmd](/uploads/504b8cafa8763657fa1ee9036dbd9349/Sensibility_of_celerity_parameter_on_Lag_model.Rmd)
- [celerity_sensibility.bib](/uploads/484d9de749caec8781c72fb71ee774a1/celerity_sensibility.bib)
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/160
Conversion of LayerFracSolidPrecip in SeriesAggreg
2023-10-26T11:24:38+02:00
Thirel Guillaume
Conversion 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.
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/158
Improve description of the StartParamList and StartParamDistrib arguments in ...
2022-07-18T17:38:40+02:00
Thirel Guillaume
Improve description of the StartParamList and StartParamDistrib arguments in CreateCalibOptions
From the `CreateCalibOptions` help, the distinction between `StartParamList` and `StartParamDistrib` is not clear.
I suggest adding at the end of the description of `StartParamList `the following:
> Each of the n parameter sets provid...
From the `CreateCalibOptions` help, the distinction between `StartParamList` and `StartParamDistrib` is not clear.
I suggest adding at the end of the description of `StartParamList `the following:
> Each of the n parameter sets provided will be tested in a row.
I suggest adding at the end of the description of `StartParamList` the following:
> Each possible combination of parameter values will be tested in a row.
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/155
Add the names of the parameter in Calibration
2022-07-18T17:39:08+02:00
Dorchies David
Add the names of the parameter in Calibration
Add a names to the final parameters with the complete name of the parameters
Add a names to the final parameters with the complete name of the parameters
v1.8
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/153
SD: Add Linear Lag and Route propagation model
2023-10-26T11:24:53+02:00
Dorchies David
SD: Add Linear Lag and Route propagation model
Processed by Enola Henrotin.
See the forked project on https://gitlab.irstea.fr/david.dorchies/airgr
Processed by Enola Henrotin.
See the forked project on https://gitlab.irstea.fr/david.dorchies/airgr
v2.0
Dorchies David
Dorchies David
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/152
SD: Add capability to integrate other propagation models
2023-10-26T11:24:58+02:00
Dorchies David
SD: Add capability to integrate other propagation models
As for `FUN_MOD` for choosing the GR model, add a `FUN_SD` parameter to allow the user to choose the propagation model in SD models.
This work is processed by Enola Henrotin on the fork https://gitlab.irstea.fr/david.dorchies/airgr
As for `FUN_MOD` for choosing the GR model, add a `FUN_SD` parameter to allow the user to choose the propagation model in SD models.
This work is processed by Enola Henrotin on the fork https://gitlab.irstea.fr/david.dorchies/airgr
v2.0
Dorchies David
Dorchies David
https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/150
Implemente Daniela Peredo's work
2022-07-19T08:50:53+02:00
Thirel Guillaume
Implemente Daniela Peredo's work
That could be useful to add Daniela's work in airGR (see https://www.tandfonline.com/doi/full/10.1080/02626667.2022.2030864).
Maybe @paul.astagneau you have already implented it by the way?
That could be useful to add Daniela's work in airGR (see https://www.tandfonline.com/doi/full/10.1080/02626667.2022.2030864).
Maybe @paul.astagneau you have already implented it by the way?