airGR issueshttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues2020-02-12T08:58:26+01:00https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/27Add the possibility to plot any internal variable of the GR models with the a...2020-02-12T08:58:26+01:00Thirel GuillaumeAdd the possibility to plot any internal variable of the GR models with the airGR::plot functionIt could be linked to the "ts" category.
NB: AE was added (see https://gitlab.irstea.fr/HYCAR-Hydro/airgr/issues/2).It could be linked to the "ts" category.
NB: AE was added (see https://gitlab.irstea.fr/HYCAR-Hydro/airgr/issues/2).https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/30Create a RunModel_CemaNeigeGR2M function2022-12-06T15:46:59+01:00Thirel GuillaumeCreate a RunModel_CemaNeigeGR2M functionCoupling GR2M with CemaNeige has been requested a couple of times. Indeed, when much snow is present, it impacts monthly discharge significantly.
There is no reason why CemaNeige could not work at a monthly time step. However, the temp...Coupling GR2M with CemaNeige has been requested a couple of times. Indeed, when much snow is present, it impacts monthly discharge significantly.
There is no reason why CemaNeige could not work at a monthly time step. However, the temperature gradient (gradT) applied in DataAltiExtrapolation_Valery (and maybe more things in this function) should take into account the case of a monthly time step.https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/32Enable the GR models to ingest ensembles2020-02-27T10:39:43+01:00Thirel GuillaumeEnable the GR models to ingest ensemblesEnsembles are useful for data assimilation and probabilistic forecasting applications. It might be useful to add the possibility to give ensembles of meteorological forcing to the GR models. Presently ensembles are dealt with through loo...Ensembles are useful for data assimilation and probabilistic forecasting applications. It might be useful to add the possibility to give ensembles of meteorological forcing to the GR models. Presently ensembles are dealt with through loops on each member, but providing directly the ensembles could fasten the execution of the GR models (indeed, the present loops necessitate to relaunch the GR models at each time step).https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/33Merge airGR and airGRplus functions2022-09-12T10:24:24+02:00Delaigue OlivierMerge airGR and airGRplus functionsLinked to the airGRplus project:
https://gitlab.irstea.fr/HYCAR-Hydro/airGRplus/issues/2Linked to the airGRplus project:
https://gitlab.irstea.fr/HYCAR-Hydro/airGRplus/issues/2v2.0https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/36Avoid checks to increase the speed of use of a function2021-06-16T19:24:35+02:00Thirel GuillaumeAvoid checks to increase the speed of use of a functionSince the many checks in the different functions are quite often the code elements that require a major part of the CPU time, what about proposing a mode that skips all checks?
This would be somehow (but not exactly, as we are not talki...Since the many checks in the different functions are quite often the code elements that require a major part of the CPU time, what about proposing a mode that skips all checks?
This would be somehow (but not exactly, as we are not talking about compilation) like the Release and Debug modes of (gfortran) CodeBlocks.
I would see it as a check.mode argument in the functions, if `check.mode == true` we do as usual, and otherwise `check.mode == false` then we skip all of them. The recommandation would then be to do some tests with `check.mode == true` and then run the actual applications with `check.mode == false`. A vos risques et périls. ;)
Just an idea...https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/39Allow different altitudes for meteorological variables in CemaNeige2020-11-24T09:01:51+01:00Delaigue OlivierAllow different altitudes for meteorological variables in CemaNeigeIn the `DataAltiExtrapolation_Valery` function, it would be preferable to be able to set the average elevation of the precipitation and temperature series in two separate variables. Measurements are not always taken at the same geographi...In the `DataAltiExtrapolation_Valery` function, it would be preferable to be able to set the average elevation of the precipitation and temperature series in two separate variables. Measurements are not always taken at the same geographical position, and therefore at different altitudes.https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/40Set time series of altitudes in CemaNeige2020-03-29T04:59:35+02:00Delaigue OlivierSet time series of altitudes in CemaNeigeIn the `DataAltiExtrapolation_Valery()` function, it would be desirable to be able to provide a time series of altitudes because :
- the geographical position of the meteorological station may change over time
- time series of meteorolog...In the `DataAltiExtrapolation_Valery()` function, it would be desirable to be able to provide a time series of altitudes because :
- the geographical position of the meteorological station may change over time
- time series of meteorological data can be computed from the interpolation of several stations, the number of which varies over timehttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/42Add new function to manage time steps2021-04-19T09:09:56+02:00Delaigue OlivierAdd new function to manage time stepsIt is maybe a good idea to create an internal function to manage the time steps in order to avoid command lines in many functions:
```
if ("daily" %in% class(XXXXXXX)) {
TimeStep <- 60 * 60 * 24
}
if ("hourly" %in% class(XXXXXXX)) {
...It is maybe a good idea to create an internal function to manage the time steps in order to avoid command lines in many functions:
```
if ("daily" %in% class(XXXXXXX)) {
TimeStep <- 60 * 60 * 24
}
if ("hourly" %in% class(XXXXXXX)) {
TimeStep <- 60 * 60
}
```https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/45Deprecate verbose and warning arguments2021-01-11T18:14:55+01:00Delaigue OlivierDeprecate verbose and warning arguments@guillaume.thirel, are `warning` and `verbose` arguments really useful?
The use of the `suppresseMessages()` and `suppressWarnings()` functions allows you to do the same thing.
Furthermore, in some functions the argument is named `verbos...@guillaume.thirel, are `warning` and `verbose` arguments really useful?
The use of the `suppresseMessages()` and `suppressWarnings()` functions allows you to do the same thing.
Furthermore, in some functions the argument is named `verbose`, but it is used to suppress warning messages (e.g. `SeriesAggreg()`)...v2.0https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/48Improve computation time of the Imax function2021-04-19T08:20:53+02:00Delaigue OlivierImprove computation time of the Imax functionComputation time of the `Imax()` function needs to be improved.The use of the double loop slows down the code strongly.Computation time of the `Imax()` function needs to be improved.The use of the double loop slows down the code strongly.https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/54Add a dam module with the lumped GR models2021-04-27T08:11:42+02:00Thirel GuillaumeAdd a dam module with the lumped GR modelsFollowing the PhD thesis of Jean-Luc Payan and the work of Morgane Terrier, we have pieces of `airGR `codes that allow to take into account the impact of dams in the GR4J and GR5J models. Knowing a time series of delta V, i.e. the variat...Following the PhD thesis of Jean-Luc Payan and the work of Morgane Terrier, we have pieces of `airGR `codes that allow to take into account the impact of dams in the GR4J and GR5J models. Knowing a time series of delta V, i.e. the variation of the volume of water in a dam, it is possible to subtract water from the production store and to release in the the routing store.
Not sure about GR6J, Morgane told me it caused issues with the exponential store, to be checked with @charles.perrin .
Eventual inclusion of this module in `airGR `should be thought of considering parallel works on semi-distribution.
Also important will be how to deal with this additional input data (observed delta V time series).https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/57Set number of IniStates and StateEnd values when only CemaNeige is used2021-11-03T14:12:37+01:00Thirel GuillaumeSet number of IniStates and StateEnd values when only CemaNeige is usedFor initial states (e.g. `RunOptions$IniStates`) or final states (`OutputsModel$StateEnd`, we store `7 + 60(*24) + Nlayers*4` states at the daily or hourly time steps. This is not useful when only `CemaNeige `is used. For exemple, for `G...For initial states (e.g. `RunOptions$IniStates`) or final states (`OutputsModel$StateEnd`, we store `7 + 60(*24) + Nlayers*4` states at the daily or hourly time steps. This is not useful when only `CemaNeige `is used. For exemple, for `GR2M `we store only `2` states, not `7 + 60`.
I propose to modify `CreateRunOptions `lines accordingly:
```r
NState <- NULL
if ("GR" %in% ObjectClass | "CemaNeige" %in% ObjectClass) {
if ("hourly" %in% ObjectClass) {
NState <- 7 + 3 * 24 * 20+ 4 * NLayers
}
if ("daily" %in% ObjectClass) {
NState <- 7 + 3 * 20 + 4 * NLayers
}
if ("monthly" %in% ObjectClass) {
NState <- 2
}
if ("yearly" %in% ObjectClass) {
NState <- 1
}
}
```
should become :
```r
NState <- 0
if ("GR" %in% ObjectClass) {
if ("hourly" %in% ObjectClass) {
NState <- 7 + 3 * 24 * 20
}
if ("daily" %in% ObjectClass) {
NState <- 7 + 3 * 20
}
if ("monthly" %in% ObjectClass) {
NState <- 2
}
if ("yearly" %in% ObjectClass) {
NState <- 1
}
}
if ("CemaNeige" %in% ObjectClass) {
if (!"yearly" %in% ObjectClass) {
NState <- NState + 4 * NLayers
}
}
```
In addition, `RunModel_CemaNeige.R` and `CreateIniStates.R` should be modified accordingly. This will ease the implementation of `RunModel_CemaNeigeGR2M`.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/58T gradient in DataAltiExtrapolation_Valery only valid in Northern hemisphere2021-01-11T12:02:48+01:00Thirel GuillaumeT gradient in DataAltiExtrapolation_Valery only valid in Northern hemisphereI suspect that the DataAltiExtrapolation_Valery T gradient defined in GradT_Valery2010() is only valid for the Northern hemisphere.I suspect that the DataAltiExtrapolation_Valery T gradient defined in GradT_Valery2010() is only valid for the Northern hemisphere.v2.0https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/60Migrate TransfoParam functions and CreateCalibOptions to S3 methods2021-06-03T11:50:21+02:00Dorchies DavidMigrate TransfoParam functions and CreateCalibOptions to S3 methodsThe main idea is to facilitate the model chaining (e.g. CemaNeige + GR4J + LAG) in order to reduce the current code complexity and facilitate extension to new models in the future. S3 class concepts are a good candidate to tackle this i...The main idea is to facilitate the model chaining (e.g. CemaNeige + GR4J + LAG) in order to reduce the current code complexity and facilitate extension to new models in the future. S3 class concepts are a good candidate to tackle this issue. A Proof of Concept written in Rmarkdown showing how model chaining can be operated is available here :
[PoC_airGR_S3_classes.Rmd](/uploads/4492a10c93c3c7ba4547c76bf6f19896/PoC_airGR_S3_classes.Rmd)
## Starting point
Currently in `master` and `dev` branches, depending on the `FUN_MOD` provided to `CreateCalibOptions` a serie of conditions assign a `FUN1` variable corresponding to a `TransfoParam_GR*` function and a `FUN2` variable corresponding to either `TransfoParam_CemaNeige` or `TransfoParam_CemaNeigeHyst` depending on `isHyst` parameter. If several models are involved (e.g. CemaNeige + GR4J), then a "meta" FUN_TRANSFO function is written, binding columns of the output matrix with outputs of each model. In the `SD` branch the complexity of the process is again complicated by adding parameters of the LAG model.
## Proposition
- Modify CreateCalibOption in order to assign classes corresponding to the models involved in the model chain to the and call a generic function `TransfoParam`
- Change the name of `transfoParam_*` function to `TransfoParam.*` methods
- Rewrite `TransfoParam` generic function in order to automatically bind columns of the matrix `ParamT`
## Pitfalls
If we assume a generic form of the model chaining and put in correspondence the order of the model with the order of the parameters, the current order in `SD` implementation is not compliant: the current order is : `param = c(GRparam, CemaneigeParam, LAGparam)`. If we considere `Cemaneige` as a pretreatment of the rain, before running a `GR` model and `LAG` a routing model applied after GR model, this order of parameter is not logical.
To solve this issue, as the order of parameter between `GR` and `Cemaneige` is already fixed on older versions and SD model is not public yet, I propose to adopt this order of parameters: `param = c(LAGparam, GRparam, CemaneigeParam)`.v2.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/81Remove of the oldest deprecated arguments and functions2022-07-07T14:10:53+02:00Delaigue OlivierRemove of the oldest deprecated arguments and functionsCheck the box when the argument or function is removed.
### 1.0.9.64 Release Notes (2017-11-10)
- [x] `RunSnowModule` argument is now deprecated in `CreateRunOptions()`.
### 1.0.14.1 Release Notes (2018-09-28)
- [x] `LatRad` argum...Check the box when the argument or function is removed.
### 1.0.9.64 Release Notes (2017-11-10)
- [x] `RunSnowModule` argument is now deprecated in `CreateRunOptions()`.
### 1.0.14.1 Release Notes (2018-09-28)
- [x] `LatRad` argument is now deprecated in `PEdaily_Oudin()` and replaced by the `Lat` argument.
- [x] unused `Ind_zeroes` argument of the `CreateInputsCrit()` function is now deprecated.
- [x] `verbose` argument is now deprecated in `CreateInputsCrit()` and replaced by the `warnings` argument.
### 1.2.13.16 Release Notes (2019-04-03)
- [x] `Qobs` argument is now deprecated in `CreateInputsCrit()` and has been renamed `Obs`.
- [x] `FUN_CRIT` argument is now deprecated in `ErrorCrit()`. This function now gets this information from the `InputsCrit` argument.
- [ ] `FUN_CRIT` argument is now deprecated in `Calibration_Michel()`. This function now gets this information from the `InputsCrit` argument.
### 1.3.2.23 Release Notes (2019-06-20)
- [x] `PEdaily_Oudin()` function is deprecated and his use has been replaced by the use of `PE_Oudin()`.
### 1.6.8.44 Release Notes (2021-01-08)
- [ ] `TimeFormat` argument is now deprecated in `SeriesAggreg()`.
- [ ] `NewTimeFormat` argument is now deprecated in `SeriesAggreg()` and replaced by the `Format` argument.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/84Add the use of '['.OutputsModel in plot.OutputsModel2021-07-14T10:14:45+02:00Delaigue OlivierAdd the use of '['.OutputsModel in plot.OutputsModelIt could be nice to simplify the code of the `plot.OutputsModel()` function by the use of '['.OutputsModel in order to manage the `IndPeriod_Plot` argument.It could be nice to simplify the code of the `plot.OutputsModel()` function by the use of '['.OutputsModel in order to manage the `IndPeriod_Plot` argument.v2.0https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/91Remove plot.OutputsModel from NAMESPACE2021-01-15T08:47:47+01:00Delaigue OlivierRemove plot.OutputsModel from NAMESPACEThe `plot.OutputsModel()` function has been export again in order not to break the reverse dependency of the current version of airGRteaching (v0.2.9.25) available on the CRAN (see #89, ab853bd3). This break has already been fixed in the...The `plot.OutputsModel()` function has been export again in order not to break the reverse dependency of the current version of airGRteaching (v0.2.9.25) available on the CRAN (see #89, ab853bd3). This break has already been fixed in the development version of airGRteaching ([v0.2.10](https://gitlab.irstea.fr/HYCAR-Hydro/airgrteaching/-/milestones/1)) that will be submitted to CRAN shortly after airGR [v1.6](https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/milestones/2).
Once the new versions of airGR and airGRteaching will be available on CRAN. This function can be removed from the NAMESPACE again from the development version of airGR.v2.0https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/96Parallelize the grid-screening step during calibration2021-11-03T14:13:16+01:00Delaigue OlivierParallelize the grid-screening step during calibrationIt is possible to parallelize the grid-screening step during calibration, this would speed up the calibration when the model used has many parameters, especially for some 'airGRplus' models.
We can use the 'parallel' package in order no...It is possible to parallelize the grid-screening step during calibration, this would speed up the calibration when the model used has many parameters, especially for some 'airGRplus' models.
We can use the 'parallel' package in order not to depend to an external package, because this one is automatically installed with R.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/97Parallelize CemaNeige2021-03-02T09:59:34+01:00Thirel GuillaumeParallelize CemaNeigeSimilarly to https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/96, the computation done on several altitude bands of CemaNeige could be parallelized. This remark is potentially valid both for `RunModel_CemaNeige*` calculation but also ...Similarly to https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/96, the computation done on several altitude bands of CemaNeige could be parallelized. This remark is potentially valid both for `RunModel_CemaNeige*` calculation but also for `DataAltiExtrapolation_Valery`.https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/115Add PCICt date format management2023-09-05T09:54:33+02:00Delaigue OlivierAdd PCICt date format managementTom Chitso & Katie A. Smith from CEH
Friday, March 5, 2021 11:17:28 AM
> I am replying on behalf of Katie and I, as I am running the airGR package as part of our ongoing research.
> The error comes when using `POSIXct` dates with 360-d...Tom Chitso & Katie A. Smith from CEH
Friday, March 5, 2021 11:17:28 AM
> I am replying on behalf of Katie and I, as I am running the airGR package as part of our ongoing research.
> The error comes when using `POSIXct` dates with 360-day years. `POSIXct` does not accept the 29th and 30th February as dates, so gives them NA values. When I use this with `CreateInputsModel` I get the error:
```
“Error in CreateInputsModel(FUN_MOD = get(paste0("RunModel_", model)), :
'DatesR' must not include duplicated values”
```
> I have tried running CreateInputsModel with PCICt dates (which accepts 360 day years), but this gives the error:
```
“Error in CreateInputsModel(FUN_MOD = get(paste0("RunModel_", model)), :
'DatesR' must be defined as 'POSIXlt' or 'POSIXct'”
```
> I have run the model successfully using a dummy set of `POSIXct` dates, and then converted back to the original dates at the end of the process. Is this approach acceptable?
> I have also seen your previous conversation with Katie, but could not quite understand the solution. Do you suggest duplicating the 28th February data to act as in-fill data for the 29th and 30th February?v2.0