airGR issueshttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues2020-02-12T10:11:16+01:00https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/3Improve Error message in CreateInputsCrit2020-02-12T10:11:16+01:00Thirel GuillaumeImprove Error message in CreateInputsCritThe Error message `"'BoolCrit' and 'InputsModel' series must have the same length"` is wrong in CreateInputsCrit. Indeed, the check is done between `length(InputsModel$DatesR[RunOptions$IndPeriod])` and `length(iListArgs2$BoolCrit`. As a...The Error message `"'BoolCrit' and 'InputsModel' series must have the same length"` is wrong in CreateInputsCrit. Indeed, the check is done between `length(InputsModel$DatesR[RunOptions$IndPeriod])` and `length(iListArgs2$BoolCrit`. As a consequence, I recommend the following Error message : `"'BoolCrit' and the period defined in RunOptions must have the same length`https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/8Correction of stop message in CreateInputsModel2020-02-12T10:13:34+01:00Thirel GuillaumeCorrection of stop message in CreateInputsModel`stop("time series could not be trunced since missing values were detected at the list time-step")` should be replaced with `stop("time series could not be trunced since missing values were detected at the last time-step")` in CreateInpu...`stop("time series could not be trunced since missing values were detected at the list time-step")` should be replaced with `stop("time series could not be trunced since missing values were detected at the last time-step")` in CreateInputsModelhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/13GR5H with interception store2022-09-08T18:51:56+02:00Thirel GuillaumeGR5H with interception storeWe plan to introduce in airGR the GR5H model with (and without) interception.
Here is a list of changes that should be made :
In `CreateRunOptions`, we should:
- add a `IsIntStore` boolean argument to choose or not to use the intercep...We plan to introduce in airGR the GR5H model with (and without) interception.
Here is a list of changes that should be made :
In `CreateRunOptions`, we should:
- add a `IsIntStore` boolean argument to choose or not to use the interception store
- add an "Interception" class to the `RunOptions` object
- Verify the checks made on `IniStates`. especially, if `!inherits(IniStates, "Interception")`, then no interception store state is possible. Waiting for Andrea to tell us what the importance is of initialising this state.
In `Calibration_Michel` and `CreateCalibOptions`, we should add some checks whether `IsIntStore` is TRUE for the `TransfoParam` step.
In `Create_IniStates`, we should:
- add `IntStore` state (to verify with Andrea)
- add some checks
In `Create_InputsModel`, nothing to do so far, but later it will be modified to account for diverse time steps.
In Utils, we should add the `IntStore` output in `.FortranOutputs`.
We should create `RunModel_GR5H`, `RunModel_CemaNeigeGR5H` and `TransfoParam_GR5H` (use GR4H functions for inspiration).
Of course we need a Fortran `frun_gr5` code.https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/15Warning during compilation - variable not initialised2020-02-12T10:12:22+01:00Pelletier AntoineWarning during compilation - variable not initialisedThe compiler throws a warning while updating the package.
My install is R 3.6.1 with x86_64-suse-linux-gnu platform (OpenSUSE Leap 15.1). I was installing airGR 1.3.2.42 from Lyon 1 CRAN repository. The compiler is GNU Fortran 7.4.1.
T...The compiler throws a warning while updating the package.
My install is R 3.6.1 with x86_64-suse-linux-gnu platform (OpenSUSE Leap 15.1). I was installing airGR 1.3.2.42 from Lyon 1 CRAN repository. The compiler is GNU Fortran 7.4.1.
The message is the following :
```
gfortran -fno-optimize-sibling-calls -fpic -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -c frun_cemaneige.f -o frun_cemaneige.o
frun_cemaneige.f:115:0:
IF (G.LT.Glocalmax.AND.Gratio.EQ.1.) Glocalmax=G !Update in case of potential melt and G lower than Gseuil
Warning: ‘glocalmax’ may be used uninitialized in this function [-Wmaybe-uninitialized]
```
As far as I can understand the source code in `frun_cemaneige.f`, this is unlikely to create a bug, as `glocalmax` is initialised and used only when `IsHystBool` is set to `TRUE`.https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/17Specifying in and/or out for the arguments of the Fortran functions2020-02-12T10:11:41+01:00Thirel GuillaumeSpecifying in and/or out for the arguments of the Fortran functionsThe Fortran subroutines do not contain any specification of whether their arguments are in, out or inout variables. That does not help the reading of these functions.The Fortran subroutines do not contain any specification of whether their arguments are in, out or inout variables. That does not help the reading of these functions.Thirel GuillaumeThirel Guillaumehttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/21Speed-up of the hyperbolic tangent function2020-02-12T09:00:27+01:00Thirel GuillaumeSpeed-up of the hyperbolic tangent functionAs proposed by V. Mansanarez, we could use the function below, applied to 2*Val, instead of the function we currently have:
```
!**********************************************************************
FUNCTION tanHyp2(Val) ! Function t...As proposed by V. Mansanarez, we could use the function below, applied to 2*Val, instead of the function we currently have:
```
!**********************************************************************
FUNCTION tanHyp2(Val) ! Function that calculates the hyperbolic tangent of Val/2
!**********************************************************************
! Inputs
! Val ! Real, value
! Outputs
! tanHyp ! Real, value of the hyperbolic tangent
Implicit None
!! dummies
! in
doubleprecision, intent(in) :: Val
! out
doubleprecision :: tanHyp
!! locals
doubleprecision :: ValExp
ValExp=EXP(Val)
tanHyp=(ValExp - 1.)/(ValExp + 1.)
RETURN
ENDFUNCTION
!**********************************************************************
```https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/29Adding outputs to GR4H2020-02-12T08:30:03+01:00Delaigue OlivierAdding outputs to GR4HIt would be nice for the RunModel_GR4H function to return:
* `Pn`
* `Ps`
* `AExch1`
* `AExch2`
It is necessary to modify:
* `RunModel_GR4H()` R function
* `frun_GR4H` Fortran subroutineIt would be nice for the RunModel_GR4H function to return:
* `Pn`
* `Ps`
* `AExch1`
* `AExch2`
It is necessary to modify:
* `RunModel_GR4H()` R function
* `frun_GR4H` Fortran subroutinehttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/34Semi-distributed version of airGR models2020-10-14T18:32:33+02:00Thirel GuillaumeSemi-distributed version of airGR modelsA semi-distributed version of the models present in airGr have been mentioned several times in the past and recently:
- requests from external/internal users
- possibility of discarding GRSD for having a more flexible and user-friendly s...A semi-distributed version of the models present in airGr have been mentioned several times in the past and recently:
- requests from external/internal users
- possibility of discarding GRSD for having a more flexible and user-friendly semi-distributed modelling framework
- need for an HYDRO intern to have rapidly the possibility to model simple catchments with one or two upstream nested catchments.
We brainstormed (Olivier, Charles, Mamoun and myself) 2 days ago. Here is a summary of an option of semi-distribution of airGR models we could easily and somehow rapidly implement:
Concept:
- the user would be supposed to know the dependency between catchments
- the user would implement a loop that browses the dependency tree
- for upstream catchments, run/calibrate normally the GR models
- for downstream catchments, run/calibrate GR models on the downstream contributive area only, and add the lagged upstream simulated discharge
- it means that for each subcatchment, specifying the specific InputsModel, RunOptions and CalibOptions would still be necessary
Implementation:
- Upgrade the CreateInputsModel function to add the following (optional for catchments that have upstream catchments): a matrix of upstream simulated discharges, a matrix of upstream areas + downstream area (to convert discharges from mm to m3/s), a matrix of upstream hydraulic lengths
- create a RunModel_SD (or preferably upgrade the RunModel function) that takes into account the upgraded InputsModel and a Param vector that also contains the LAG parameter: this RunModel_SD function would simply be the addition of downstream discharge and the convolution product between lag and upstream discharge (see code below)
- Upgrade the CreateCalibOptions function to add 1 to the number of parameters for the SD case, add quantiles and a transformation for this parameter and add a "SD" type
- Create a TransfoParam_Lag function (same transfo as X4?).
This options would work well for sequential calibration of catchments (not for conjoint calibration of clusters of catchments).
Old RunModel
```
function (InputsModel, RunOptions, Param, FUN_MOD)
{
FUN_MOD <- match.fun(FUN_MOD)
return(FUN_MOD(InputsModel = InputsModel, RunOptions = RunOptions,
Param = Param))
}
```
New RunModel
```
function (InputsModel, RunOptions, Param, FUN_MOD)
{
FUN_MOD <- match.fun(FUN_MOD)
Q_down <- FUN_MOD(InputsModel = InputsModel, RunOptions = RunOptions,
Param = Param)
if (SEMI_Distributed) {
Q_tot <- Q_down + SUM(of lagged (cf Param$LAG) upstream discharges given in InputsModel)
} else {
return(Q_down)
}
}
```v1.6.10Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/37Argument verification using partial matching2021-01-07T17:52:14+01:00Delaigue OlivierArgument verification using partial matchingSimplification of function input argument checks. This concerns the following functions and arguments:
- `CreateInputsCrit()`
- `VarObs`
- `PE_Oudin()`
- `LatUnit`
- `TimeStepIn`
- `TimeStepOut`
- `plot.OutputsModel()`
- `whic...Simplification of function input argument checks. This concerns the following functions and arguments:
- `CreateInputsCrit()`
- `VarObs`
- `PE_Oudin()`
- `LatUnit`
- `TimeStepIn`
- `TimeStepOut`
- `plot.OutputsModel()`
- `which`
- `SeriesAggreg()`
- `TimeFormat`
- `NewTimeFormat`
In the one-argument form `match.arg(arg)`, the choices are obtained from a default setting for the formal argument `arg` of the function from which `match.arg` was called. (Since default argument matching will set arg to choices, this is allowed as an exception to the `length one unless several.ok is TRUE` rule, and returns the first element.)v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/47Loop improvement of the frun_CEMANEIGE subroutine2020-04-14T18:47:14+02:00Thirel GuillaumeLoop improvement of the frun_CEMANEIGE subroutineThe calculation of Pliq and Psol is done in the time loop. I think we can extract it from that loop.
I.e. modify
```
!--------------------------------------------------------------
! Time loop
!----------------------...The calculation of Pliq and Psol is done in the time loop. I think we can extract it from that loop.
I.e. modify
```
!--------------------------------------------------------------
! Time loop
!--------------------------------------------------------------
DO k=1,LInputs
! SolidPrecip and LiquidPrecip
Pliq=(1.-InputsFracSolidPrecip(k))*InputsPrecip(k)
Psol=InputsFracSolidPrecip(k)*InputsPrecip(k)
```
to
```
! SolidPrecip and LiquidPrecip
Pliq=(1.-InputsFracSolidPrecip)*InputsPrecip
Psol=InputsFracSolidPrecip*InputsPrecip
!--------------------------------------------------------------
! Time loop
!--------------------------------------------------------------
DO k=1,LInputs
```
and then replace all `Pliq `and `Psol `by `Pliq(k)` and `Psol(k)`.
Does it run faster @olivier.delaigue?
A proposition of code is attached. [frun_CEMANEIGE.f90](/uploads/9e4dc141c105313dfd8c76f74e37dab4/frun_CEMANEIGE.f90)https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/49Add GR5H diagram in the RunModel_GR5H function help2021-01-12T17:00:34+01:00Thirel GuillaumeAdd GR5H diagram in the RunModel_GR5H function helpWe need to add the GR5H diagram in the `RunModel_GR5H()` function help.We need to add the GR5H diagram in the `RunModel_GR5H()` function help.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/51Add Ps in the outputs of GR2M2021-01-07T17:49:29+01:00Delaigue OlivierAdd Ps in the outputs of GR2MIn order to display the GR2M model diagram in the airGRteaching GUI, *Ps* (part of P filling the production store) has to be returned by the `frun_GR2M` Fortran subroutine. The `.FortranOutputs()` R function has to be updated.
See https...In order to display the GR2M model diagram in the airGRteaching GUI, *Ps* (part of P filling the production store) has to be returned by the `frun_GR2M` Fortran subroutine. The `.FortranOutputs()` R function has to be updated.
See https://gitlab.irstea.fr/HYCAR-Hydro/airgrteaching/-/issues/14v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/52Implement automatic tests in the package2021-01-08T04:59:26+01:00Dorchies DavidImplement automatic tests in the packageThis should be done following instruction in http://r-pkgs.had.co.nz/tests.html
These tests will be automatically checked with the command `R CMD check`.
First easy tests to implement could be to check that the scripts called in the vi...This should be done following instruction in http://r-pkgs.had.co.nz/tests.html
These tests will be automatically checked with the command `R CMD check`.
First easy tests to implement could be to check that the scripts called in the vignettes are running and are always giving the same result.v1.6.10Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/56Remove useless time step checks in the plot.OutputsModel function2021-04-19T09:08:06+02:00Delaigue OlivierRemove useless time step checks in the plot.OutputsModel functionThe time step of the `OutputsModel` argument is checked by the `plot.OutputsModel()` function (the time step is checked by comparing with the calculation of the difference of the last two time steps). This seems useless, because we alrea...The time step of the `OutputsModel` argument is checked by the `plot.OutputsModel()` function (the time step is checked by comparing with the calculation of the difference of the last two time steps). This seems useless, because we already check the class of this object, which is therefore assumed to be necessarily valid.
In addition, this stops the function from being used on an aggregated series returned by the `SeriesAggreg2.OutputsModel ()` function.https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/59Add comparative tests with master branch on examples2020-10-15T09:35:34+02:00Dorchies DavidAdd comparative tests with master branch on examplesTODO:
* add a script in order to install airGR package from cran, browse manual files and for each run the example and record all the variables created by each example. This record will be a file saved in artefact for use in next CI jobs...TODO:
* add a script in order to install airGR package from cran, browse manual files and for each run the example and record all the variables created by each example. This record will be a file saved in artefact for use in next CI jobs. This script should be notices in `.Rbuildignore`.
* Modify `.gitlab-ci.yml` this script should be run before build and test of the package.
* Add test that run the examples and compare the variables with the one coming from the example executed from the CRAN version package.v2.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/63Calibration on discontinuous periods2020-11-24T08:06:04+01:00Delaigue OlivierCalibration on discontinuous periodsMany people have questions about how to calibrate the model on discontinuous periods. Most of the time they think that the `IndPeriod_Run` argument of the `CreateRunOptions()` function should be used, while the `BoolCrit` argument of the...Many people have questions about how to calibrate the model on discontinuous periods. Most of the time they think that the `IndPeriod_Run` argument of the `CreateRunOptions()` function should be used, while the `BoolCrit` argument of the `CreateInputsCrit()` function should be used instead.
The manual of the `CreateRunOptions()` function should probably be improved to refer to that.
In the **Details** part, it should be explained that to keep the continuity of the internal model states, `IndPeriod_Run` must also be continuous.v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/79Improve description of Output from CemaNeige functions2021-01-06T08:01:31+01:00Thirel GuillaumeImprove description of Output from CemaNeige functionsTo improve the understanding of CemaNeige outputs (cf a misunderstanding a user recently had), I suggest we replace
`[numeric] series of snow pack [mm]`
with
`[numeric] series of snow pack (snow water equivalent) [mm]`To improve the understanding of CemaNeige outputs (cf a misunderstanding a user recently had), I suggest we replace
`[numeric] series of snow pack [mm]`
with
`[numeric] series of snow pack (snow water equivalent) [mm]`v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/82Opening of usable functions in SeriesAggreg2021-01-11T10:34:06+01:00Dorchies DavidOpening of usable functions in SeriesAggreg"min", "max" and "median" should be usable besides "sum" and "mean" functions currently available in SeriesAggreg. But also other functions as below:
## Quantile (percentile)
A call to a function named "qn" should be interpreted as `qu..."min", "max" and "median" should be usable besides "sum" and "mean" functions currently available in SeriesAggreg. But also other functions as below:
## Quantile (percentile)
A call to a function named "qn" should be interpreted as `quantile(x, probs = n)` (i.e. "q90" as `probs = 0.9`)
## Any function
Any function taking a vector as first argument and returning a single value.v1.6.10Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/86Gitlab-CI: correctly handle WARNING and NOTE in checks2021-06-22T08:53:02+02:00Dorchies DavidGitlab-CI: correctly handle WARNING and NOTE in checksCurrently, check fails only if in an ERROR occurs especially because some warnings or notes occur because of reasons outside the scope of the package itself (dependency to 'qpdf' or curl issues like in https://gitlab.irstea.fr/HYCAR-Hydr...Currently, check fails only if in an ERROR occurs especially because some warnings or notes occur because of reasons outside the scope of the package itself (dependency to 'qpdf' or curl issues like in https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/jobs/142218).
airGRiwrm now implements a new CI procedure that correcly handle WARNING in check by putting the job and the pipeline in failure state (See: https://gitlab.irstea.fr/in-wop/airGRiwrm/-/commits/master/.gitlab-ci.yml). This way of doing seems reasonable because of the CRAN's requirements which doesn't allow any WARNING in the check of a package submission.
This procedure can be implemented in airGR, especially the part using R tidyverse docker image hosted on the server hosted at INRAE Lyon.
A new concept "don't stop on failure" exists in Gitlab-CI (See: https://docs.gitlab.com/ee/ci/yaml/#allow_failure) that allows to continue a pipeline on a job failure and to display corresponding job and pipeline in an "orange warning state". That could be useful if we want to be aware of NOTEs in checks without setting all the check process in a red failure state.v1.6.11Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/87Rename Actual Exchange variable in the GR2M outputs2021-01-13T09:32:21+01:00Thirel GuillaumeRename Actual Exchange variable in the GR2M outputsThe `EXCH` variable in the GR2M Fortran code represents the actual exchange, not the potential exchange. I suggest renaming it `AEXCH` as for other models.
Enclose is the FORTRAN updated.
I will adapt the manual accordingly.
@olivie...The `EXCH` variable in the GR2M Fortran code represents the actual exchange, not the potential exchange. I suggest renaming it `AEXCH` as for other models.
Enclose is the FORTRAN updated.
I will adapt the manual accordingly.
@olivier.delaigue I guess you have to adapt `.FortranOutputs`
[frun_GR2M.f90](/uploads/9eb41e58436e7a48981baeb698820b71/frun_GR2M.f90)v1.6.10https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/104RunModel_Lag: `StateEnd` is wrong if upstream flow is in mm / time step2021-04-06T15:01:00+02:00Dorchies DavidRunModel_Lag: `StateEnd` is wrong if upstream flow is in mm / time stepIn the lag model upstream flows related to a sub-basin are converted from mm / time step to m3 / time step. Initial states and upstream flows are merged in order to have the memory of the upstream flows before the simulation period but n...In the lag model upstream flows related to a sub-basin are converted from mm / time step to m3 / time step. Initial states and upstream flows are merged in order to have the memory of the upstream flows before the simulation period but no conversion is applied to initial states.
So the initial states should either be converted if they are stored in mm/ts or stored in m3/ts.
There are pro and cons for the 2 solutions:
1. store states in mm / ts and converted in simulation: `Qupstream` is already in mm/ts so it seems consistent to store the corresponding initial state (which is `Qupstream` before the simulation period) in the same unity.
2. store states in m3/ts and use it directly in simulation which can avoid a computation burden due to a conversion at each run.
Concerning the second solution, maybe it could be a good idea to also convert `Qupstream` in m3/ts in `CreateInputsModel` in order to avoid an "on-the-fly" conversion at each run of `RunModel_Lag`. So, all upstream flows (States + Qupstream) would be in m3/ts and no computation burden would occur due to conversion.v1.6.11Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/109RunModel_Lag: Add an argument `QcontribDown` to `RunModel_Lag`2021-04-06T10:53:40+02:00Dorchies DavidRunModel_Lag: Add an argument `QcontribDown` to `RunModel_Lag`Currently, the runoff contribution of the downstream sub-basin is included in the `InputsModel`object by copying the `OutputsModel` object of the GR simulation (extracted from `RunModel_lag` example script):
```
# Add the output of the ...Currently, the runoff contribution of the downstream sub-basin is included in the `InputsModel`object by copying the `OutputsModel` object of the GR simulation (extracted from `RunModel_lag` example script):
```
# Add the output of the precipitation-runoff model in the InputsModel object
InputsModel$OutputsModel <- OutputsModelDown
# Run the lag model which routes precipitation-runoff model and upstream flows
OutputsModel <- RunModel_Lag(InputsModel = InputsModel,
RunOptions = RunOptions, Param = Velocity)
```
This way of proceeding is:
- ugly :sweat_smile:
- not generic if you want to inject another contribution than a GR model output
- cumbersome because we don't need to copy all informations contained in `OutputsModel`, only `Qsim`
Using a new argument `QcontribDown` in `RunModel_Lag` for the runoff contribution of the downstream sub-basin would be cleaner and more generic.v1.6.11Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/issues/110SD model: add an argument `unit` in CreateInputsModel and store `Qupstream` i...2021-04-15T21:35:10+02:00Dorchies DavidSD model: add an argument `unit` in CreateInputsModel and store `Qupstream` in m3/time stepThe current implementation mixes units in `Qupstream` depending on the fact the upstream flow is related to an area or not and this leads to on-the-fly conversion in `RunModel_Lag` (See #104).
Moreover, the presence of different units i...The current implementation mixes units in `Qupstream` depending on the fact the upstream flow is related to an area or not and this leads to on-the-fly conversion in `RunModel_Lag` (See #104).
Moreover, the presence of different units in `Qupstream` can be confusing for the user.
Implementation of `Qupstream` in m3/time-step in the `InputsModel` object would avoid unnecessary conversions during simulation but upstream flow provided by GR models are in mm/time-step, so giving the choice of the unit to the user appears to be a good trade-off.
Here a proposition of the `unit` parameter definition:
```
\item{unit}{(optional) [character] unit of the flow in the parameter \code{Qupstream}, available units are: "mm" for mm/time-step (default), "m3" for m3/time-step, "m3/s" and "l/s". See details}
\item{Qupstream}{(optional) [numerical matrix] time series of upstream flows (catchment average), its unit is defined by the \code{unit} parameter, required to create the SD model inputs. See details}
(...)
\details{
(...)
Users wanting to use a semi-distributed (SD) lag model should provide valid \code{Qupstream}, \code{LengthHydro}, and \code{BasinAreas} parameters. Each upstream sub-catchment is described by an upstream flow time series (one column in \code{Qupstream} matrix), a distance between the downstream outlet and the upstream inlet (one item in \code{LengthHydro}) and an area (one item in \code{BasinAreas}).
The order of the columns or of the items should be consistent for all these parameters. \code{BasinAreas} should contain one extra information (stored in the last item) which is the area of the downstream sub-catchment.
Upstream flows that are not related to a sub-catchment such as release or withdraw spots are identified by an area equal to \code{NA}, and if \code{unit="mm"} the upstream flow must be expressed in m3/time step instead of mm/time step which is not possible in absence of a related area.
Please note that the use of SD lag model require to use the \code{\link{RunModel}} function instead of \code{\link{RunModel_GR4J}} or the other \code{RunModel_*} functions.
```v1.6.11Dorchies DavidDorchies Davidhttps://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.0https://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/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/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/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/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/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.6