airGR issueshttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues2023-10-26T11:23:40+02:00https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/176CreateIniStates: Huge computation time spent on GetFeatModel2023-10-26T11:23:40+02:00Dorchies DavidCreateIniStates: Huge computation time spent on GetFeatModelThe 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.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/169Fix GR pathology2023-10-26T11:24:06+02:00Thirel GuillaumeFix GR pathologyIssue 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.0https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/166Update GR5H interception grid-screening parameter quantiles2022-09-13T14:58:36+02:00Delaigue OlivierUpdate GR5H interception grid-screening parameter quantilesAccording 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.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/161RunModel_Lag: proposal for a better transformation and screening of the param...2023-02-02T14:04:02+01:00Dorchies DavidRunModel_Lag: proposal for a better transformation and screening of the parametersThe 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.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/157Improve computation time of propose candidates grid2023-10-19T18:08:30+02:00Delaigue OlivierImprove computation time of propose candidates gridCurrently, the `ProposeCandidatesGrid()` function from `Calibration_Michel()` removes duplicated values after the creation of the table of proposed candidates grid using `expand.grid()` in order to compute all combinations of parameters....Currently, the `ProposeCandidatesGrid()` function from `Calibration_Michel()` removes duplicated values after the creation of the table of proposed candidates grid using `expand.grid()` in order to compute all combinations of parameters.
In addition, the function is not clean because it use the `DistribParamR` external variable (but the result was not wrong).
**Current function**:
```r
ProposeCandidatesGrid <- function(DistribParam) {
NewCandidates <- expand.grid(lapply(seq_len(ncol(DistribParamR)), function(x) DistribParam[, x]))
NewCandidates <- unique(NewCandidates) # to avoid duplicates when a parameter is set
Output <- list(NewCandidates = NewCandidates)
}
```
**Benchmarking**:
It is more efficient to remove duplicated values on each parameter instead of the whole table.
In addition, it is not necessary to return a list.
```r
## original one removing duplcated values on the whole data.frame (but DistribParamR replacedby DistribParam)
ProposeCandidatesGrid1 <- function(DistribParam) {
NewCandidates <- expand.grid(lapply(seq_len(ncol(DistribParam)), function(x) DistribParam[, x]))
NewCandidates <- unique(NewCandidates) # to avoid duplicates when a parameter is set
Output <- list(NewCandidates = NewCandidates)
}
## original one removing duplicated values on the whole data.frame & returning data.frame instead of a list
ProposeCandidatesGrid2 <- function(DistribParam) {
NewCandidates <- expand.grid(lapply(seq_len(ncol(DistribParam)), function(x) DistribParam[, x]))
unique(NewCandidates) # to avoid duplicates when a parameter is set
}
## new one removing duplicated values on each parameter & returning a list
ProposeCandidatesGrid3 <- function(DistribParam) {
NewCandidates <- expand.grid(lapply(seq_len(ncol(DistribParam)), function(x) unique(DistribParam[, x])))
Output <- list(NewCandidates = NewCandidates)
}
## new one removing duplicated values on each parameter & returning data.frame instead of a list
ProposeCandidatesGrid4 <- function(DistribParam) {
expand.grid(lapply(seq_len(ncol(DistribParam)), function(x) unique(DistribParam[, x])))
}
```
```r
ParamT <- matrix(c(+3.60, -1.00, +3.30, -9.10, -0.90, +3.00,
+3.90, -0.50, +4.10, -8.70, +0.10, +4.00,
+4.50, +0.50, +5.00, -8.10, +1.10, +5.00), ncol = 6, byrow = TRUE)
microbenchmark(ProposeCandidatesGrid1(ParamT),
ProposeCandidatesGrid2(ParamT),
ProposeCandidatesGrid3(ParamT),
ProposeCandidatesGrid4(ParamT),
times = 50L,
unit = "milliseconds")
## Unit: milliseconds
## expr min lq mean median uq max neval
## ProposeCandidatesGrid1(ParamT) 1.7160 1.8258 2.176492 1.85945 1.9305 5.4754 50
## ProposeCandidatesGrid2(ParamT) 1.7570 1.8292 2.090968 1.88125 1.9109 5.5252 50
## ProposeCandidatesGrid3(ParamT) 0.2275 0.2456 0.275084 0.26530 0.2881 0.5601 50
## ProposeCandidatesGrid4(ParamT) 0.2337 0.2466 0.318084 0.26510 0.2856 2.7356 50
```
```r
ParamT <- matrix(c(+1.9, +2.7, -1.1, -9.6, -5.5, +1.0, +3.4, -0.2, +4.5, +3.5, +4.3, -1.5, -4.2, -4.4,
+3.5, +3.4, -0.3, -9.2, -1.6, +2.0, +3.7, +0.0, +5.1, +5.3, +5.6, -0.5, -3.6, -2.7),
ncol = 14, byrow = TRUE)
microbenchmark(ProposeCandidatesGrid1(ParamT),
ProposeCandidatesGrid2(ParamT),
ProposeCandidatesGrid3(ParamT),
ProposeCandidatesGrid4(ParamT),
times = 50L,
unit = "milliseconds")
## Unit: milliseconds
## expr min lq mean median uq max neval
## ProposeCandidatesGrid1(ParamT) 88.6652 92.7099 100.529286 96.37210 100.7031 169.4589 50
## ProposeCandidatesGrid2(ParamT) 84.6542 90.4932 104.274102 95.62470 109.4955 167.5425 50
## ProposeCandidatesGrid3(ParamT) 1.3705 1.4359 1.909450 1.50210 1.5678 15.6336 50
## ProposeCandidatesGrid4(ParamT) 1.3880 1.4408 1.503504 1.48280 1.5404 2.2734 50
}
```
```r
ParamT <- matrix(c(+1.9, +2.7, -1.1, -9.6, -5.5, +1.0, +3.4, -0.2, +4.5, +3.5, +4.3, -1.5, -4.2, -4.4,
+3.5, +3.4, -0.3, -9.2, -1.6, +2.0, +3.7, +0.0, +5.1, +5.3, +5.6, -0.5, -3.6, -2.7,
+3.5, +3.4, -0.3, -9.2, -1.6, +4.0, +3.7, +0.0, +5.1, +5.3, +5.6, -0.5, -3.6, -2.7),
ncol = 14, byrow = TRUE)
ParamT [3, ] <- Sacramento[3, ] + 1
microbenchmark(ProposeCandidatesGrid1(ParamT),
ProposeCandidatesGrid2(ParamT),
ProposeCandidatesGrid3(ParamT),
ProposeCandidatesGrid4(ParamT),
times = 50L,
unit = "milliseconds")
## Unit: milliseconds
## expr min lq mean median uq max neval
## ProposeCandidatesGrid1(ParamT) 31527.7280 35190.369 36366.143 36351.8798 38167.122 40490.213 10
## ProposeCandidatesGrid2(ParamT) 31889.5226 33820.050 35162.053 34758.2704 37117.132 38873.993 10
## ProposeCandidatesGrid3(ParamT) 350.7097 371.400 1505.988 481.6215 2297.846 5384.131 10
## ProposeCandidatesGrid4(ParamT) 347.6815 372.925 1410.104 427.5523 2170.164 4755.841 10
```v1.7.6https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/155Add the names of the parameter in Calibration2022-07-18T17:39:08+02:00Dorchies DavidAdd the names of the parameter in CalibrationAdd a names to the final parameters with the complete name of the parametersAdd a names to the final parameters with the complete name of the parametersv1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/153SD: Add Linear Lag and Route propagation model2023-10-26T11:24:53+02:00Dorchies DavidSD: Add Linear Lag and Route propagation modelProcessed by Enola Henrotin.
See the forked project on https://gitlab.irstea.fr/david.dorchies/airgrProcessed by Enola Henrotin.
See the forked project on https://gitlab.irstea.fr/david.dorchies/airgrv2.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/152SD: Add capability to integrate other propagation models2023-10-26T11:24:58+02:00Dorchies DavidSD: Add capability to integrate other propagation modelsAs 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/airgrAs 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/airgrv2.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/150Implemente Daniela Peredo's work2022-07-19T08:50:53+02:00Thirel GuillaumeImplemente Daniela Peredo's workThat 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?https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/143SeriesAggreg: allow to define a unique aggregation function for multiple columns2021-12-16T08:22:17+01:00Dorchies DavidSeriesAggreg: allow to define a unique aggregation function for multiple columns`SeriesAggreg` is very useful for calculating annual or monthly indicators.
For example, I use it to calculate annual hydrologic indicator on data.frame containing the simulated flow for plenty of gauging stations.
For doing that, I ha...`SeriesAggreg` is very useful for calculating annual or monthly indicators.
For example, I use it to calculate annual hydrologic indicator on data.frame containing the simulated flow for plenty of gauging stations.
For doing that, I have to write:
```r
SeriesAggreg(dfQ, Format = "%Y", ConvertFun = rep("calcMyIndicator", ncol(dfQ) - 1))
```
Could we assume that if a unique function is provided by the user for `ConvertFun` therefore it is implicitly applied for all columns?
This syntax would be largely more convenient:
```r
SeriesAggreg(dfQ, Format = "%Y", ConvertFun = "calcMyIndicator")
```https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/140Adjust TransfoParam_GR5H (X2)2023-10-26T11:26:08+02:00Astagneau PaulAdjust TransfoParam_GR5H (X2)There might be an issue with the transformation of X2 in GR5H.
The transformation of X2 (from T to R) in `TransfoParam_GR5J` and `TransfoParam_GR5H` is:
`ParamOut[, 2] <- sinh(ParamIn[, 2])`
For both models, the calculation of potentia...There might be an issue with the transformation of X2 in GR5H.
The transformation of X2 (from T to R) in `TransfoParam_GR5J` and `TransfoParam_GR5H` is:
`ParamOut[, 2] <- sinh(ParamIn[, 2])`
For both models, the calculation of potential intercatchment semi-exchange is:
`EXCH=Param(2)*(St(2)/Param(3)-Param(5))`
X2 is in mm/timestep, which means that X2 is timestep dependant.
The calculation of hourly potential intercatchment semi-exchange is calculated differently by [Le Moine, 2008, p. 173](https://webgr.inrae.fr/wp-content/uploads/2012/07/2008-LE_MOINE-THESE.pdf).
The distribution of X2 over 229 catchments changes when dividing X2 by 24 in the fortran code. ![X2change_distrib_2021-12-07](/uploads/207f5b4cef5917388fa6a41c28371b40/X2change_distrib_2021-12-07.png)
Most X2 values were equal to -0.04 mm/h, which is one of the prefiltering values.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/138Gitlab-CI: Run CI an docker image and checks organisation2022-02-11T13:34:40+01:00Dorchies DavidGitlab-CI: Run CI an docker image and checks organisation# Using docker
Currently the checks are performed on a server hosted by Inrae at CINES Montpellier.
I run directly the checks in the environment of the server and I have manually compiled 3 versions of R:
- oldrel: 3.6.3
- patched: 4....# Using docker
Currently the checks are performed on a server hosted by Inrae at CINES Montpellier.
I run directly the checks in the environment of the server and I have manually compiled 3 versions of R:
- oldrel: 3.6.3
- patched: 4.0.5
- devel: 2020-04-28 r78328
We can see that these version are outdated and maintaining these version updated manually is a bit time-consuming.
Using docker images allows to always work with up-to-date versions of R and moreover allows to use the dedicated Gitlab-runner server managed by Inrae.
On the rocker/tidyverse repository, we can use the following versions (See https://hub.docker.com/r/rocker/tidyverse/tags):
- latest (which correspond today to the 4.1.1 "patched" version).
- devel
There is no alias for "old-rel", but we can manage it manually by picking up an old version we want to assure compatibility (for example `rocker/tidyverse:3.5`).
# Check organisation
Checks "on-cran" and checks "not-cran" are partially redundant. Maybe we can only run checks on "cran" and the totality of the tests to save running time.v1.7.0https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/135Regularisation: handle composite criterion2021-11-03T14:22:18+01:00Dorchies DavidRegularisation: handle composite criterionTest and implement the possibility to use composite criteria (e.g.: KGE(sqrt(Q)) mixed with KGE(1/Q)) with Lavenne regularisation.Test and implement the possibility to use composite criteria (e.g.: KGE(sqrt(Q)) mixed with KGE(1/Q)) with Lavenne regularisation.v1.8Dorchies 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/129Move argument checks and OutputsModel formatting from RunModel* functions to ...2021-06-18T10:30:57+02:00Dorchies DavidMove argument checks and OutputsModel formatting from RunModel* functions to utils functionsThe issue #123 highlights the need to eliminate the code redundancy in `RunModel*` functions.
So I create a separated issue for this specific task with a separated branch in order to be able to run properly regression tests.The issue #123 highlights the need to eliminate the code redundancy in `RunModel*` functions.
So I create a separated issue for this specific task with a separated branch in order to be able to run properly regression tests.v1.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/123Add warm-up period simulated flows in OutputsModel2022-02-03T16:58:11+01:00Dorchies DavidAdd warm-up period simulated flows in OutputsModelSD models need the upstream flows simulated during the end of the warning period in order to be correctly initialised.
Simulated flows during the warm-up period are part of the GR fortran function outputs. Consequently they can be add i...SD models need the upstream flows simulated during the end of the warning period in order to be correctly initialised.
Simulated flows during the warm-up period are part of the GR fortran function outputs. Consequently they can be add in the outputs of the `RunModel_GR*` functions.
We propose to add a new item in `OutputsModel` called "WarmUpQsim" containing this simulated flow.
Unlike the other outputs this one will have the same length as `IndPeriod_Run`. In anticipation of #89 and the future release of the `'[.OutputsModel'` method, this new item should have an attribute specifying that it should not be processed by such methods. This attribute could consist to add a class named "WarmUpOutputsModelItem".v1.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/118plot.OutputsModel: remove case sensitivity to the `which` argument2021-04-26T14:35:21+02:00Dorchies Davidplot.OutputsModel: remove case sensitivity to the `which` argumentIs it possible to have the `which` argument case insensitive?:
```r
> plot(OMinf2nat$CHALO_21, Qinf[I_Run, "CHALO_21"], which = "regime")
Error in plot.OutputsModel(OMinf2nat$CHALO_21, Qinf[I_Run, "CHALO_21"], :
incorrect element fo...Is it possible to have the `which` argument case insensitive?:
```r
> plot(OMinf2nat$CHALO_21, Qinf[I_Run, "CHALO_21"], which = "regime")
Error in plot.OutputsModel(OMinf2nat$CHALO_21, Qinf[I_Run, "CHALO_21"], :
incorrect element found in argument 'which': "regime"
it can only contain "all", "synth", "ts", "perf", "Precip", "PotEvap", "ActuEvap", "Temp", "SnowPack", "Flows", "Error", "Regime", "CumFreq", "CorQQ"
> plot(OMinf2nat$CHALO_21, Qinf[I_Run, "CHALO_21"], which = "Regime")
```https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/117Check the compatibility between the RunOptions and the InputsModel obects2021-11-03T14:24:36+01:00Dorchies DavidCheck the compatibility between the RunOptions and the InputsModel obectsHere the necessary data: [GR4J_crash.RData](/uploads/8f44ff6a10af128a396c78110b9a7e6e/GR4J_crash.RData)
And the code tested on the last `dev` version:
```r
> library(airGR)
> load("GR4J_crash.RData")
> ls()
[1] "InputsModel" "Param" ...Here the necessary data: [GR4J_crash.RData](/uploads/8f44ff6a10af128a396c78110b9a7e6e/GR4J_crash.RData)
And the code tested on the last `dev` version:
```r
> library(airGR)
> load("GR4J_crash.RData")
> ls()
[1] "InputsModel" "Param" "RunOptions"
> Param
[1] 169.017118 -2.375568 20.697233 1.417417
> RunModel_GR4J(InputsModel, RunOptions, Param)
Error in RunModel_GR4J(InputsModel, RunOptions, Param) :
NA/NaN/Inf in foreign function call (arg 2)
```
The error occurs in the Fortran call. I don't know how to debug that...v1.8Delaigue OlivierDelaigue Olivierhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/113Management of missing values in input and output of Fortran codes2021-03-27T07:28:34+01:00Delaigue OlivierManagement of missing values in input and output of Fortran codesAs written by @francois.bourgin, the following lines slow down a lot the `RunModel_*()` functions (especially if the chronicles are long). https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/98#note_34812
By removing the use of the `rou...As written by @francois.bourgin, the following lines slow down a lot the `RunModel_*()` functions (especially if the chronicles are long). https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/98#note_34812
By removing the use of the `round()` function, the functions arec speeded up. https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/98#note_34831
See the discussion on issue https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/98v1.6.11https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/111Add the regularization calibration2022-02-03T16:58:11+01:00Thirel GuillaumeAdd the regularization calibrationIt would be nice to implement the regularisation calibration proposed by de Lavenne et al. (2019) (https://doi.org/10.1029/2018WR024266). That would stabilise parameters for downstream basins.
Basically, we need to consider in the cali...It would be nice to implement the regularisation calibration proposed by de Lavenne et al. (2019) (https://doi.org/10.1029/2018WR024266). That would stabilise parameters for downstream basins.
Basically, we need to consider in the calibration process the distance between calibrated parameter values and parameter values of upstream catchments.
That would be useful for @cyril.thebault as well as Laura and other people using airGR-SD.
I would say that we need for that:
- to have access to upstream parameter values in `Calibration_Michel`
- add a `regul` boolean in CreateCalibOptions and retrieve it in `Calibration_Michel`
- either a new `Error_Crit` that allows to combine any `Error_Crit` with the distance calculation, or implement directly that in `Calibration_Michel`
- distance must be calculated in the transformed space of parameters to avoid having parameters with huge distance (e.g. X1) compared to smaller parameters (e.g. X4)
- certainly other things that will come up when we try to implement it. :)
Who wants to give it a try? :)v1.7.0