airGR issueshttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues2021-11-03T14:12:37+01:00https://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/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/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/98Calculate computation times for each CRAN version2021-11-03T14:13:11+01:00Thirel GuillaumeCalculate computation times for each CRAN versionIn order to keep trace of the evolution of the computing times after modifications of the packages, I think we should automatically calculate the computation times in a similar way as done in Coron et al. (2017) (https://doi.org/10.1016/...In order to keep trace of the evolution of the computing times after modifications of the packages, I think we should automatically calculate the computation times in a similar way as done in Coron et al. (2017) (https://doi.org/10.1016/j.envsoft.2017.05.002), Table B.3.
I propose that:
- each former CRAN version is tested now
- each future new version of the package is tested (before submission for detecting problems(?) and after publication on the CRAN)
- all tests done in Tab. B.3 are performed (i.e. runs and calibrations over 10 years for each hydrological + snow model combinations, 100 tries)
- other functions like `Imax`, `PE_Oudin`, `DataAltiExtrapolation_Valery` are tested (configuration to determine)
- at least one Windows machine and one Linux machine are tested, Mac if possible.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/116Manage the number of days by a year according to the complete leap cycle of 4...2021-11-03T14:11:43+01:00Delaigue OlivierManage the number of days by a year according to the complete leap cycle of 400 yearsIt's not important, but it doesn't cost anything to change (except the temporary setting in the .regressionignore file).
Currently airGR use `365.25` day by a year. According to the complete leap cycle of 400 years, he true value should...It's not important, but it doesn't cost anything to change (except the temporary setting in the .regressionignore file).
Currently airGR use `365.25` day by a year. According to the complete leap cycle of 400 years, he true value should be `365.2425`.
Have to be take into account in the following functions:
- `CreateRunOptions()`
- `plot.OutputsModel()`
- `.GetFeatModel()`v1.8https://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/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/121Calculate test coverage for the package2021-11-03T14:13:07+01:00Delaigue OlivierCalculate test coverage for the packageMaybe it would be good to add a package coverage test to get an idea of missing or inchoate tests (even if it doesn't make sense to reach 100 %).
I did a test to get an idea of the results (not everything seems right: e.g. 'frun_PE.f90...Maybe it would be good to add a package coverage test to get an idea of missing or inchoate tests (even if it doesn't make sense to reach 100 %).
I did a test to get an idea of the results (not everything seems right: e.g. 'frun_PE.f90')
```
> covr::package_coverage(type = "all")
airGR Coverage: 68.78%
R/PEdaily_Oudin.R: 0.00%
R/RunModel_CemaNeigeGR4H.R: 0.00%
R/RunModel_CemaNeigeGR5H.R: 0.00%
R/TransfoParam_CemaNeige.R: 0.00%
R/TransfoParam_CemaNeigeHyst.R: 0.00%
R/TransfoParam_GR1A.R: 0.00%
R/TransfoParam_GR2M.R: 0.00%
R/TransfoParam_GR4H.R: 0.00%
R/TransfoParam_GR5H.R: 0.00%
R/TransfoParam_GR5J.R: 0.00%
R/TransfoParam_GR6J.R: 0.00%
src/frun_PE.f90: 0.00%
R/CreateCalibOptions.R: 41.04%
R/CreateInputsModel.R: 53.55%
R/PE_Oudin.R: 54.55%
R/CreateRunOptions.R: 65.72%
R/CreateIniStates.R: 68.16%
R/UtilsErrorCrit.R: 69.41%
R/TransfoParam_Lag.R: 70.59%
R/RunModel_GR6J.R: 71.26%
R/RunModel_GR1A.R: 71.67%
R/RunModel_GR4H.R: 72.29%
R/RunModel_GR5J.R: 72.29%
R/CreateInputsCrit.R: 72.43%
R/RunModel_GR2M.R: 73.08%
R/Imax.R: 74.07%
R/RunModel_GR5H.R: 74.19%
R/DataAltiExtrapolation_Valery.R: 76.09%
R/Utils.R: 77.14%
R/RunModel_CemaNeigeGR6J.R: 77.56%
R/RunModel_CemaNeigeGR4J.R: 78.29%
R/RunModel_CemaNeigeGR5J.R: 78.29%
R/RunModel_GR4J.R: 78.31%
R/ErrorCrit_KGE2.R: 79.31%
src/frun_GR5H.f90: 79.41%
R/RunModel_CemaNeige.R: 79.59%
R/plot.OutputsModel.R: 80.37%
R/SeriesAggreg.list.R: 83.19%
R/RunModel_Lag.R: 83.33%
R/SeriesAggreg.data.frame.R: 84.56%
R/UtilsSeriesAggreg.R: 87.50%
R/ErrorCrit_KGE.R: 87.76%
R/TransfoParam_GR4J.R: 88.00%
src/utils_D.f90: 88.57%
R/Calibration_Michel.R: 89.43%
R/Calibration.R: 90.00%
R/ErrorCrit_RMSE.R: 90.48%
R/ErrorCrit_NSE.R: 91.30%
R/ErrorCrit.R: 93.88%
src/frun_GR6J.f90: 98.35%
R/RunModel.R: 100.00%
R/SeriesAggreg.InputsModel.R: 100.00%
R/SeriesAggreg.OutputsModel.R: 100.00%
R/SeriesAggreg.R: 100.00%
R/TransfoParam.R: 100.00%
src/airGR.c: 100.00%
src/frun_CEMANEIGE.f90: 100.00%
src/frun_GR1A.f90: 100.00%
src/frun_GR2M.f90: 100.00%
src/frun_GR4H.f90: 100.00%
src/frun_GR4J.f90: 100.00%
src/frun_GR5J.f90: 100.00%
src/utils_H.f90: 100.00%
```v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/124RunOptions always warning "model states initialisation not defined" on GR1A m...2022-07-07T14:10:06+02:00Dorchies DavidRunOptions always warning "model states initialisation not defined" on GR1A modelThe following code:
```r
library(airGR)
data(L0123001)
InputsModel <- CreateInputsModel(FUN_MOD = RunModel_GR4J,
DatesR = BasinObs$DatesR,
Precip = BasinObs$P,
...The following code:
```r
library(airGR)
data(L0123001)
InputsModel <- CreateInputsModel(FUN_MOD = RunModel_GR4J,
DatesR = BasinObs$DatesR,
Precip = BasinObs$P,
PotEvap = BasinObs$E)
# conversion of InputsModel to target time step
InputsModel <- SeriesAggreg(InputsModel, Format = "%Y")
Ind_WarmUp <- seq(
which(format(InputsModel$DatesR, format = "%Y")=="1985"),
which(format(InputsModel$DatesR, format = "%Y")=="1985")
)
Ind_Run <- seq(
which(format(InputsModel$DatesR, format = "%Y")=="1986"),
which(format(InputsModel$DatesR, format = "%Y")=="2011")
)
# preparation of the RunOptions object
RunOptions <- CreateRunOptions(FUN_MOD = RunModel_GR1A,
InputsModel = InputsModel,
IndPeriod_Run = Ind_Run,
IndPeriod_WarmUp = Ind_WarmUp)
```
results with the following warning:
```
Warning message:
In CreateRunOptions(FUN_MOD = RunModel_GR1A, InputsModel = InputsModel, :
model states initialisation not defined: default configuration used
```
If I let the default warm up, the warning appears with the usual default warm-up warning:
```r
RunOptions <- CreateRunOptions(FUN_MOD = RunModel_GR1A,
InputsModel = InputsModel,
IndPeriod_Run = Ind_Run)
```
There is still a warning indicating a wrong initialisation...
```
Warning messages:
1: In CreateRunOptions(FUN_MOD = RunModel_GR1A, InputsModel = InputsModel, :
model warm up period not defined: default configuration used
the year preceding the run period is used
2: In CreateRunOptions(FUN_MOD = RunModel_GR1A, InputsModel = InputsModel, :
model states initialisation not defined: default configuration used
```
Is it a normal behavior? I don't see any clue about this in the documentation.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/125Remove warnings about parameter threshold during GR5H calibration2022-07-07T14:10:40+02:00Dorchies DavidRemove warnings about parameter threshold during GR5H calibrationTry this:
```r
library(airGR)
example("RunModel_GR5H")
str(RunOptions) # Line ignored when all lines are copy-paste together. Don't know why
CalibOptions <- CreateCalibOptions(RunModel_GR5H)
OutputsCalib <- Calibration(InputsModel = Inp...Try this:
```r
library(airGR)
example("RunModel_GR5H")
str(RunOptions) # Line ignored when all lines are copy-paste together. Don't know why
CalibOptions <- CreateCalibOptions(RunModel_GR5H)
OutputsCalib <- Calibration(InputsModel = InputsModel, RunOptions = RunOptions,
InputsCrit = InputsCrit, CalibOptions = CalibOptions,
FUN_MOD = RunModel_GR5H)
```
You get:
```
Grid-Screening in progress (0% 20% 40% 60% 80% 100%)
Screening completed (243 runs)
Param = 55.147, -0.400, 228.149, 11.050, 0.126
Crit. NSE[Q] = 0.0650
Steepest-descent local search in progress
Calibration completed (68 iterations, 913 runs)
Param = 451.901, -0.494, 143.170, 3.555, 0.188
Crit. NSE[Q] = 0.9184
There were 24 warnings (use warnings() to see them)
```
And then:
```
> warnings()
Warning messages:
1: In FUN_MOD(InputsModel = InputsModel, RunOptions = RunOptions, ... :
Param[4] (X4: unit hydrograph time constant [h]) < 0.50
X4 set to 0.50
2: In FUN_MOD(InputsModel = InputsModel, RunOptions = RunOptions, ... :
Param[4] (X4: unit hydrograph time constant [h]) < 0.50
X4 set to 0.50
...
```
I suppose that the bounds of the parameter should be correctly handled in the calibration to avoid this kind of warnings.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/126Add a parameter to the plot.OutputsModel function in order to choose the comp...2023-10-26T11:26:32+02:00Delaigue OlivierAdd a parameter to the plot.OutputsModel function in order to choose the comparison period between dischargeIt might be a good idea to add an argument to choose either the simulated flows corresponding to the period in common with the observed flows, or all the simulated flows. This for two graphs:
- regimes
- classified flows
It would be nic...It might be a good idea to add an argument to choose either the simulated flows corresponding to the period in common with the observed flows, or all the simulated flows. This for two graphs:
- regimes
- classified flows
It would be nice to specify it directly on both graphs.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/130Aggregation on a selected period of time with SeriesAggreg2023-10-26T11:26:37+02:00Thirel GuillaumeAggregation on a selected period of time with SeriesAggregIt would be useful to allow users to provide a selection of dates on which the aggregation is wanted.It would be useful to allow users to provide a selection of dates on which the aggregation is wanted.v1.8https://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/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/141Vignette about CemaNeige hysteresis to complete2022-02-21T11:13:52+01:00Thirel GuillaumeVignette about CemaNeige hysteresis to completeAs explained in Riboust et al. (2019)'s paper, the CemaNeige hysteresis must be used with a MeanAnSolidPrecip argument of CreateRunOptions set to different values for each elevation zone. As a consequence, we must add/modify a couple of ...As explained in Riboust et al. (2019)'s paper, the CemaNeige hysteresis must be used with a MeanAnSolidPrecip argument of CreateRunOptions set to different values for each elevation zone. As a consequence, we must add/modify a couple of things in the vignette showing how to use it, as well as in the example of RunModel_CemaNeigeGR4J.
In the vignette:
```r
SolidPrecip_Cal <- rep(0, 5)
SolidPrecip_Val <- rep(0, 5)
for(iLayer in 1:5){
SolidPrecip_Cal[iLayer] <- mean(InputsModel$LayerFracSolidPrecip[[iLayer]][Ind_Cal]*InputsModel$LayerPrecip[[iLayer]][Ind_Cal]);
SolidPrecip_Val[iLayer] <- mean(InputsModel$LayerFracSolidPrecip[[iLayer]][Ind_Val]*InputsModel$LayerPrecip[[iLayer]][Ind_Val]);
}
if(inherits(InputsModel,"hourly" )){ Factor <- 365.25*24; }
if(inherits(InputsModel,"daily" )){ Factor <- 365.25; }
if(inherits(InputsModel,"monthly")){ Factor <- 12; }
if(inherits(InputsModel,"yearly" )){ Factor <- 1; }
SolidPrecip_Cal <- SolidPrecip_Cal*Factor
SolidPrecip_Val <- SolidPrecip_Val*Factor
## preparation of RunOptions object
RunOptions_Cal <- CreateRunOptions(FUN_MOD = RunModel_CemaNeigeGR4J,
InputsModel = InputsModel, IndPeriod_Run = Ind_Cal, IsHyst = TRUE,
MeanAnSolidPrecip = SolidPrecip_Cal)
## preparation of RunOptions object
RunOptions_Val <- CreateRunOptions(FUN_MOD = RunModel_CemaNeigeGR4J,
InputsModel = InputsModel, IndPeriod_Run = Ind_Val, IsHyst = TRUE,
MeanAnSolidPrecip = SolidPrecip_Val)
```
In the example:
```r
SolidPrecip <- rep(0, 5)
for(iLayer in 1:5){
SolidPrecip[iLayer] <- mean(InputsModel$LayerFracSolidPrecip[[iLayer]][Ind_Run]*InputsModel$LayerPrecip[[iLayer]][Ind_Run]);
}
if(inherits(InputsModel,"hourly" )){ Factor <- 365.25*24; }
if(inherits(InputsModel,"daily" )){ Factor <- 365.25; }
if(inherits(InputsModel,"monthly")){ Factor <- 12; }
if(inherits(InputsModel,"yearly" )){ Factor <- 1; }
SolidPrecip <- SolidPrecip*Factor
## preparation of the RunOptions object
RunOptions <- CreateRunOptions(FUN_MOD = RunModel_CemaNeigeGR4J, InputsModel = InputsModel,
IndPeriod_Run = Ind_Run, IsHyst = TRUE, MeanAnSolidPrecip = SolidPrecip)
```
@olivier.delaigue, please make it R beautiful. :D
I'm doing some tests and confirm tomorrow.
Thanks @francois.bourgin for spotting that.v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/142Adjust TransfoParam_CemaNeige, TransfoParam_CemaNeigeHyst and CreateCalibOptions2023-10-26T11:25:58+02:00François BourginAdjust TransfoParam_CemaNeige, TransfoParam_CemaNeigeHyst and CreateCalibOptionsThe `degree-day melt coefficient` is in mm/timestep
See also https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/140The `degree-day melt coefficient` is in mm/timestep
See also https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/140v1.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/149SeriesAggreg: handling diverse input time steps correctly2023-10-26T11:25:22+02: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
```v1.8https://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/158Improve description of the StartParamList and StartParamDistrib arguments in ...2022-07-18T17:38:40+02:00Thirel GuillaumeImprove description of the StartParamList and StartParamDistrib arguments in CreateCalibOptionsFrom 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.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/160Conversion of LayerFracSolidPrecip in SeriesAggreg2023-10-26T11:24:38+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.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/163Allow using CreateInputsCrit_Lavenne with composite criteria2023-10-26T11:24:21+02:00Thirel GuillaumeAllow using CreateInputsCrit_Lavenne with composite criteriaWe 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.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/164Using Epsilon in CreateInputsCrit2023-10-26T11:24:26+02:00Thebault CyrilUsing Epsilon in CreateInputsCritI 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.8https://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/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/167CreateRunOptions: crash with RunModel_Lag2022-11-27T10:04:52+01:00Dorchies DavidCreateRunOptions: crash with RunModel_LagThe 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.8Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/170Move the project in the airGRgalaxy repository2023-02-14T13:02:13+01:00Delaigue OlivierMove 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 filev1.8https://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/177RunModel_Lag: negative Qsim during Calibration produces NaNs2024-03-27T14:24:06+01:00Dorchies DavidRunModel_Lag: negative Qsim during Calibration produces NaNsIn 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.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/179RunModel_CemaNeige fails in CreateIniStates at the hourly time step2023-10-26T11:23:22+02:00Thebault CyrilRunModel_CemaNeige fails in CreateIniStates at the hourly time stepWhen 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.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/181CreateRunOptions and RunModel_GR5H* do not crash when Imax set to NULL2023-10-26T11:23:17+02:00Thirel GuillaumeCreateRunOptions and RunModel_GR5H* do not crash when Imax set to NULLSee
```
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.8https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/185Add 'hydroPSO' package in the 'Suggests' list2023-10-26T10:58:38+02:00Delaigue OlivierAdd 'hydroPSO' package in the 'Suggests' listWhen 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` fileWhen 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` filev1.8