airGRiwrm issueshttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues2024-03-28T08:30:59+01:00https://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/130Ungauged node: Diversion to Reservoir crashes Calibration2024-03-28T08:30:59+01:00Dorchies DavidUngauged node: Diversion to Reservoir crashes CalibrationThe network below crashes either the donor is "54001" (by default) or "54029" (defined manually) with the error:
```
Error in InputsModel$Qupstream[Runoptions$IndPeriod_Run, i] <-
OutputsModel[[InputsModel$UpstreamNodes[i]]][[InputsMod...The network below crashes either the donor is "54001" (by default) or "54029" (defined manually) with the error:
```
Error in InputsModel$Qupstream[Runoptions$IndPeriod_Run, i] <-
OutputsModel[[InputsModel$UpstreamNodes[i]]][[InputsModel$UpstreamVarQ[i]]] :
number of items to replace is not a multiple of replacement length
```
```mermaid
graph LR
id_54032[54032]
id_54001[54001]
id_54095[54095]
id_54029[54029]
id_54095[54095]
id_Dam[Dam]
id_54001 -->| 45 km| id_54032
id_54095 -->| 42 km| id_54001
id_54029 -->| 32 km| id_54032
id_54095 -->| 10 km| id_Dam
id_Dam -->| 0 km| id_54029
class id_54032,id_54001,id_54029 IntermediateGauged
class id_54095,id_54095 UpstreamUngaugedDiversion
class id_Dam Reservoir
classDef default stroke:#333
classDef UpstreamUngauged fill:#eef
classDef UpstreamGauged fill:#aaf
classDef IntermediateUngauged fill:#efe
classDef IntermediateGauged fill:#afa
classDef DirectInjection fill:#faa
classDef Reservoir fill:#9de
classDef UpstreamUngaugedDiversion fill:#eef, stroke:#faa, stroke-width:3px
classDef UpstreamGaugedDiversion fill:#aaf, stroke:#faa, stroke-width:3px
classDef IntermediateUngaugedDiversion fill:#efe, stroke:#faa, stroke-width:3px
classDef IntermediateGaugedDiversion fill:#afa, stroke:#faa, stroke-width:3px
linkStyle 3 stroke:#faa, stroke-width:2px,stroke-dasharray: 5 5;
```v0.7.0https://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/144Highlight the water deficit at a node due to too much withdrawals2024-03-27T15:11:38+01:00Dorchies DavidHighlight the water deficit at a node due to too much withdrawalsCurrently when the discharge gives negative result due to an over-abstraction there is a warning (saying that the flow is set to zero) but the output is still negative due to a bug in HYCAR-Hydro/airgr#177.
It would be better to get an ...Currently when the discharge gives negative result due to an over-abstraction there is a warning (saying that the flow is set to zero) but the output is still negative due to a bug in HYCAR-Hydro/airgr#177.
It would be better to get an extra field with the over-abstraction value and the simulated flow set to zero.
It seems that this issue should be processed in HYCAR-Hydro/airgr#177 but we can operate a patch in airgriwrm while we wait for the release of airGR with HYCAR-Hydro/airgr#177 solved.v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/142Allowing a calibration against additional variables (e.g. reservoir volume)2023-12-22T17:00:27+01:00Thirel GuillaumeAllowing a calibration against additional variables (e.g. reservoir volume)With airGRiwrm, we simulate more variables that could be linked to physical systems, and sometimes observations exist. We can make the hypothesis that using these additional sources of data for calibration could make the integrated model...With airGRiwrm, we simulate more variables that could be linked to physical systems, and sometimes observations exist. We can make the hypothesis that using these additional sources of data for calibration could make the integrated model more robust (i.e. more temporally or spatially transferable). Therefore, it would be great to allow that. I guess that allowing that would require some changes in airGR (namely, allowing the access to other variables than Qsim, SWE and SCA for calibration).https://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/141Reduce size of `GRiwrmOutputsModel` object2023-10-25T13:24:40+02:00Dorchies DavidReduce size of `GRiwrmOutputsModel` objectFrom @guillaume.thirel, Leonard Santos met issues when modeling a network with thousands of reservoirs. The simulation occupied an overwhelming memory space resulting in the impossibility to simulate more than few years at a time.
By de...From @guillaume.thirel, Leonard Santos met issues when modeling a network with thousands of reservoirs. The simulation occupied an overwhelming memory space resulting in the impossibility to simulate more than few years at a time.
By default, `CreateRunOptions` is run with `Outputs_Sim = "all"` which leads to have all simulation output variables in the resulting object. We must think on how reduce the size of this object by maybe selecting only `DatesR` and `Qsim`, or maybe only `Qsim` since `DatesR` is the same for all the nodes.v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/136Ungauged nodes: crash with a reservoir and several upstrem nodes2023-07-03T10:51:45+02:00Dorchies DavidUngauged nodes: crash with a reservoir and several upstrem nodesThe calibration crashes with a reservoir with 2 upstream nodes with at least one ungauged:
```mermaid
graph LR
id_54001[54001]
id_54029[54029]
id_54032[54032]
id_Dam[Dam]
id_54001 -->| 45 km| id_Dam
id_54029 -->| 32 km| id_Dam
id_Da...The calibration crashes with a reservoir with 2 upstream nodes with at least one ungauged:
```mermaid
graph LR
id_54001[54001]
id_54029[54029]
id_54032[54032]
id_Dam[Dam]
id_54001 -->| 45 km| id_Dam
id_54029 -->| 32 km| id_Dam
id_Dam -->| 0 km| id_54032
class id_54001 UpstreamUngauged
class id_54029 UpstreamGauged
class id_54032 IntermediateGauged
class id_Dam Reservoir
classDef default stroke:#333
classDef UpstreamUngauged fill:#eef
classDef UpstreamGauged fill:#aaf
classDef IntermediateUngauged fill:#efe
classDef IntermediateGauged fill:#afa
classDef DirectInjection fill:#faa
classDef Reservoir fill:#9de
classDef UpstreamUngaugedDiversion fill:#eef, stroke:#faa, stroke-width:3px
classDef UpstreamGaugedDiversion fill:#aaf, stroke:#faa, stroke-width:3px
classDef IntermediateUngaugedDiversion fill:#efe, stroke:#faa, stroke-width:3px
classDef IntermediateGaugedDiversion fill:#afa, stroke:#faa, stroke-width:3px
```v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/133Improve RunModel documentation2023-05-31T09:42:40+02:00Dorchies DavidImprove RunModel documentationAdd details on returned value:
- format of the attribute Qm3s
- data added compared to airGR: Qnat, Qdiv, Qdiv_m3
Improve examples:
- margin of the plot in the final example (Y-axis label is overflowing)
- use dotted line for the minimu...Add details on returned value:
- format of the attribute Qm3s
- data added compared to airGR: Qnat, Qdiv, Qdiv_m3
Improve examples:
- margin of the plot in the final example (Y-axis label is overflowing)
- use dotted line for the minimum flow in the final plotv0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/131CreateInputsModel: Don't allow ungauged donor2023-05-23T09:28:37+02:00Dorchies DavidCreateInputsModel: Don't allow ungauged donorIn case of user defined donor, this one should not be Ungauged otherwise airGR::CreateInputsModel will crash on `FUN_MOD=Ungauged is not a function`In case of user defined donor, this one should not be Ungauged otherwise airGR::CreateInputsModel will crash on `FUN_MOD=Ungauged is not a function`v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/125CreateGRiwrm: several Diversions on the same node do not raise error2023-05-11T13:25:06+02:00Dorchies DavidCreateGRiwrm: several Diversions on the same node do not raise errorTheoretically, it's not possible to have several Diversions on the same node. But CreateGRiwrm does not raise an error in this case.Theoretically, it's not possible to have several Diversions on the same node. But CreateGRiwrm does not raise an error in this case.v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/121Allow several diversions on one node location2023-04-19T14:56:25+02:00Dorchies DavidAllow several diversions on one node location# Background issue
## Limitation for combination with "_Diversion_ nodes"
Currently, _Diversion_ nodes can only be located in nodes with GR model. And this limitation is due to the use of a single matrix `Qobs` (or the new `Qinf` cf. #...# Background issue
## Limitation for combination with "_Diversion_ nodes"
Currently, _Diversion_ nodes can only be located in nodes with GR model. And this limitation is due to the use of a single matrix `Qobs` (or the new `Qinf` cf. #120) for supplying data to _Reservoir_, _Direct injection_, and _Diversion_ nodes. In such cases, because each of this node types needs a dedicated column in `Qobs/Qinf` it's impossible, for instance, to add a _Diversion_ on a _Reservoir_ release.
## Limitation for combining multiple abstractions at the same location
Because only one _Diversion_ can be attached to a GR node, in case of multiple usages in the same node, the user needs to aggregate all abstractions for this location in order to provide the matrix `Qobs/Qinf` of influence flows to `CreateInputsModel`.
# Proposal
## Use specific ID for _Diversion_ nodes
I propose to use a specific ID for _Diversion_ nodes in order to be able to identify each _Diversion_. This ID would be a composition containing the node ID for specifying its location as follow: `[abstraction name]@[node id]`
So we would be able to have _Diversion_ named `irrigation@MyGaugingStation` or `DrinkingWater@MyReservoir`.
These IDs would be then use as column name in `Qobs/Qinf` in order to differentiate the water released by a reservoir and the water diverted immediately downstream the reservoir release.
## Coping the restriction issue in case of multiple _Diversions_
`CreateInputsModel` has a parameter `Qmin` with a default value equals zero. Whatever the user plans to abstract with the _Diversion_, the abstraction will be limited in order that the flow `Qmin` remains in the river downstream the _Diversion_.
Allowing multiple _Diversions_ raises the issue on how dispatching restrictions when the total amount of abstractions exceed to maximum available water related to `Qmin`.
Restriction rule possibilities are infinite and any implementation would consider complexe objects and algorithms that are not relevant here.
So I propose a simple standard solution which consist to apply a restriction of same proportion for each abstraction considering that `Qmin` is unique for all _Derivations_ in a given location.v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/120CreateInputsModel: deprecate `Qobs` parameter and use `Qinf` instead2023-04-19T14:52:50+02:00Dorchies DavidCreateInputsModel: deprecate `Qobs` parameter and use `Qinf` insteadThere is a confusion between the parameter `Qobs` used in `CreateInputsModel` and the parameter `Qobs` used in `CreateInputsCrit`. The first one is used to inject "observed" human influences in the model (for nodes of type _Reservoir_, _...There is a confusion between the parameter `Qobs` used in `CreateInputsModel` and the parameter `Qobs` used in `CreateInputsCrit`. The first one is used to inject "observed" human influences in the model (for nodes of type _Reservoir_, _Direct Injection_, or _Diversion_), the second is used to provide "observed" measured flows at the gauging station for the calibration of the hydrological models.
I propose to use `Qinf` instead of `Qobs` for `CreateInputsModel (standing for "influence flows").
TODO:
- [ ] Create new parameter `Qinf` in `CreateInputsModel`
- [ ] Add Qinf <- Qobs if `Qobs` is provided by the user instead of `Qinf`
- [ ] Disallow the use of both parameter together
- [ ] add a warning for deprecating the parameter `Qobs`v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/118Deprecate the use of `NA` as model for direct injection node2023-03-29T08:25:30+02:00Dorchies DavidDeprecate the use of `NA` as model for direct injection nodeThe use of `NA` as model in the GRiwrm object has many pitfalls:
- it's not homogeneous with other models since new reservoir and diversion nodes
- it's a hell to make clean conditions on the model with `NAs` and it's a source of bugs.
...The use of `NA` as model in the GRiwrm object has many pitfalls:
- it's not homogeneous with other models since new reservoir and diversion nodes
- it's a hell to make clean conditions on the model with `NAs` and it's a source of bugs.
I propose to :
- deprecate `NA` and invite to use "DirectInjection"
- Convert `NA` to "DirectInjection" in `CreateGRiwrm` with a warning
- adapt all the code to this new way of doingv0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/112Allow the use of GR2M and GR1A models2023-02-07T10:42:27+01:00Dorchies DavidAllow the use of GR2M and GR1A modelsThis issue needs a update of airGR. This last does not allow the use of SD models with monthly and yearly time steps: https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/blob/dev/R/CreateInputsModel.R#L138
On airGRiwrm side, a priori, we just ...This issue needs a update of airGR. This last does not allow the use of SD models with monthly and yearly time steps: https://gitlab.irstea.fr/HYCAR-Hydro/airgr/-/blob/dev/R/CreateInputsModel.R#L138
On airGRiwrm side, a priori, we just need to complete the following function in order to add the number of seconds for a monthly and a yearly time step: https://gitlab.irstea.fr/in-wop/airGRiwrm/-/blob/531701b5041047c1e019a9e0371f9b0c6fdca55b/R/CreateInputsModel.GRiwrm.R#L371
This is tricky since months and years don't have the same length. Mixing mm / time step for hydrological models and m3/time step for human influences may interfere in the results.
A "LagZero" model could be useful in order to do not bother the model with lag calibration when it's not needed (especially for yearly time step).https://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/98Outputs_Sim (Subset of OutputSimulation) does not work with CreateRunOptions2022-12-20T16:09:12+01:00Laurent StrohmengerOutputs_Sim (Subset of OutputSimulation) does not work with CreateRunOptionsAirGR allows to subset the outputs using the `Outputs_Sim `argument in `CreateRunOptions`.
However, using `Outputs_Sim `argument for semi-distributed simulation lead to the following error:
_Error RunModel_Lag(InputsModel, RunOptions,...AirGR allows to subset the outputs using the `Outputs_Sim `argument in `CreateRunOptions`.
However, using `Outputs_Sim `argument for semi-distributed simulation lead to the following error:
_Error RunModel_Lag(InputsModel, RunOptions, Param[1], OutputsModel) <br /> Time series WarmUpQsim in 'QcontribDown' should have the same length as 'RunOptions$IndPeriod_WarmUp'_
The error is reproducible with the vignette V02_Calibration_SD_model (https://cloud.r-project.org/web/packages/airGRiwrm/vignettes/V02_Calibration_SD_model.html) with the add of `Outputs_Sim `argument as follows:
```
RunOptions <- CreateRunOptions(
InputsModel,
IndPeriod_WarmUp = IndPeriod_WarmUp,
IndPeriod_Run = IndPeriod_Run,
Outputs_Sim = c("Qsim")
)
```https://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/92Implementation of non gauged station with donor other than a downstream gauge...2022-11-30T14:52:10+01:00Dorchies DavidImplementation of non gauged station with donor other than a downstream gauged stationHere, we try to take care of the following study cases:
- the donor sub-basin is upstream
- the donor sub-basin is on a parallel basin
Current implementation in #42 automatically takes the first downstream gauged node as donor for mode...Here, we try to take care of the following study cases:
- the donor sub-basin is upstream
- the donor sub-basin is on a parallel basin
Current implementation in #42 automatically takes the first downstream gauged node as donor for model and parameters.
We should be able to define the case when we want to inherit model and parameter from au gauged node located upstream of the ungauged node.
## Proposition
We keep the current behavior of auto-definition of the first downstream gauged node as a donor and we:
- [ ] Add a `donor` parameter to `CreateGRiwrm` with the format: `donor = c("Ungauged node id" = "Gauged node id", ...)`
- [ ] Add a warning at `CreateGRiwrm` execution for auto-defined donors: "Node [id] is defined as donor for ungauged node [id]"
- [ ] Modify the `donor` column of the GRiwrm object accordingly
- [ ] Take care of the donor in the sorting of the nodes for simulation (donors should be simulated before receivers)
- [ ] Modify Calibration procedure to take into account the parameter transfer to downstream ungauged nodes (instead of upstream)v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/105`plot.GRiwrmOutputsModel`: handle other units than mm / time step2022-10-28T11:33:02+02:00Dorchies David`plot.GRiwrmOutputsModel`: handle other units than mm / time stepThe method `airGR::plot.OutputsModel` handles results in m3/s if the parameter `BasinArea` is provided (km²). The idea is to be able to use this functionnality through `plot.GRiwrmOutputsModel`.
TODO:
- [ ] embed the *GRiwrm* object in ...The method `airGR::plot.OutputsModel` handles results in m3/s if the parameter `BasinArea` is provided (km²). The idea is to be able to use this functionnality through `plot.GRiwrmOutputsModel`.
TODO:
- [ ] embed the *GRiwrm* object in the attributes of `GRiwrmOutputsModel`
- [ ] add a parameter unit which accepts "mm" and "m3/s" to `plot.GRiwrmOutputsModel` (default "m3/s")
- [ ] use the GRiwrm object to get area of each basin and pass it to each call of `plot.OutputsModel` if unit "m3/s".v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/103Draw a map of the GRiwrm object2022-10-25T13:50:19+02:00Dorchies DavidDraw a map of the GRiwrm objectThis simple example of code plot the GRiwrm nodes on a map:
```r
data(Severn)
sf_Severn <- sf::st_as_sf(Severn$BasinsInfo, coords = c("gauge_lon", "gauge_lat"),
crs = sf::st_crs(4326))
tmap_mode("view")
tm_shap...This simple example of code plot the GRiwrm nodes on a map:
```r
data(Severn)
sf_Severn <- sf::st_as_sf(Severn$BasinsInfo, coords = c("gauge_lon", "gauge_lat"),
crs = sf::st_crs(4326))
tmap_mode("view")
tm_shape(sf_Severn) +
tm_symbols(size = 0.5,
popup.vars = c("Nom" = "gauge_name", "Surf (km²)" = "area",
"Aval" = "downstream_id",
"Distance" = "distance_downstream")) +
tm_text(text = "gauge_id", size = 1, auto.placement = TRUE) +
tm_basemap("Esri.WorldTopoMap")
```
We can imagine to complete the function `plot.GRiwrm` with an argument `map`: `NA` for the mermaid diagram, and as for the function `tmap_mode`, "plot" for a fixed plot, "view" for an interactive view.
We can try to be consistant with the design of the mermaid diagram by using the same colours for the different type of nodes and to draw arrows between nodes.Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/97Add example of management of NAs in controllers2022-09-16T12:32:54+02:00Dorchies DavidAdd example of management of NAs in controllersWrite an example of a fallback order `U` in case of `Y` of a controller is providing a NA value.Write an example of a fallback order `U` in case of `Y` of a controller is providing a NA value.Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/96RunModel.Supervision: add option to choose period of supervision (including w...2022-09-16T12:28:26+02:00Dorchies DavidRunModel.Supervision: add option to choose period of supervision (including warm-up period)Running management model can be necessary during warm-up period for example to get a correct initialisation of a reservoir volume (Thanks @myriam.soutif-bellenger).
I propose to add a new argument on the `CreateRunOptions.GRiwrmInputsMo...Running management model can be necessary during warm-up period for example to get a correct initialisation of a reservoir volume (Thanks @myriam.soutif-bellenger).
I propose to add a new argument on the `CreateRunOptions.GRiwrmInputsModel` function:
`IndPeriod_Supervision = IndPeriod_Run`
- by default, it will acts as the current version
- it allows the user to run the supervision on desired time steps even non-contiguous time steps
- an argument `IndPeriod_Supervision = c(IndPeriod_WarmUp, IndPeriod_Run)` would solve the issue raised by MyriamDorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/91Handle composite criterion at calibration2022-08-04T14:45:07+02:00Dorchies DavidHandle composite criterion at calibrationThere are two reasons why composite criterion are not handled currently:
1. `airGRiwrm::CreateInputsCrit.GRiwrmInputsModel` is currently limited to "Single" criterion.
2. `airGR::CreateInputsCrit_Lavenne` seems to have the same limitati...There are two reasons why composite criterion are not handled currently:
1. `airGRiwrm::CreateInputsCrit.GRiwrmInputsModel` is currently limited to "Single" criterion.
2. `airGR::CreateInputsCrit_Lavenne` seems to have the same limitation.
The easiest way to allow composite criterion is to create a custom `ErrorCrit` function that embed a composite criterion.
A function `CreateCompoErrorCrit` with same arguments as `airGRCreateInputsCrit` would do the trick.v0.7.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/87Reflexions about ungauged and poorly gauged modelling in airGRiwrm2022-07-22T14:58:12+02:00Thirel GuillaumeReflexions about ungauged and poorly gauged modelling in airGRiwrmAlban de Lavenne, Léonard Santos, Laurent Strohmenger and myself tried to brainstorm about all that could be needed to perform airGRiwrm modelling under ungauged or poorly gauged conditions. We mainly discussed methodological and technic...Alban de Lavenne, Léonard Santos, Laurent Strohmenger and myself tried to brainstorm about all that could be needed to perform airGRiwrm modelling under ungauged or poorly gauged conditions. We mainly discussed methodological and technical issues.
This ticket is linked to https://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/42 but I prefer to separate it in order to keep it clear.
There are two types of issues:
- Obtaining parameters for intermediate catchments that have no observed discharge data (ungauged case)
- Obtaining parameters for intermediate catchments that have limited discharge data (poorly gauged case)
**Description of the issues**
_Ungauged case_
There are several cases:
- Ungauged catchment with application of a lumped model. This is not the objective of this ticket. Regionalisation methods already exist. For example, it is advised to calibrate the lumped model over neighbouring catchments that have discharge data and to select the parameter sets of the 5 closest catchments. Then, 5 time series of discharge are produced over the ungauged catchment of interest and the average of the 5 time series is used (see section 3.2.2 of Oudin et al., 2008)
- Ungauged catchment located upstream of a gauged catchment in a semi-distributed model
- Ungauged catchment located downstream of a gauged catchment in a semi-distributed model
- Ungauged catchment located downstream of a gauged catchment and upstream of a gauged catchment in a semi-distributed model
_Poorly gauged case_
Two cases:
- We have data at the time step of the model, but only on a few time steps
- We have instantaneous data obtained from punctual gaugings
**Methods that could be applied**
_Ungauged case_
Option 1:
Regionalising lumped models (cf Oudin et al., 2008) in order to produce simulated discharge time series over ungauged catchments. Then, after averaging the 5 time series, we can use it to calibrate the semi-distributed model.
Option 2:
Using the transfR package (https://cran.r-project.org/web/packages/transfR/index.html) in order to transfer observed discharge from gauged stations towards ungauged catchments. Then, these transfered time series can be used to calibrate the semi-distributed model.
Option 3:
Perform a calibration similarly to the Fortran GRSD model.
If a gauged catchment is available downstream, then we can used the same parameter set for the ungauged catchment (providing we transform X4).
If a gauged catchment is available upstream, we transfer the parameters of the most contributive catchment upstream (providing we transform X4).
It is advised to use the regularisation calibration method in this case. In case a different a priori parameter set is used, then there could be some variability in the parameter values.
_Poorly gauged case_
If we have discharge at the time step of the model:
We can use the wroks from Rojas-Serna et al. (2016). This is a method combining regionalisation from neighbouring catchments and performance.
Step 1: rank the parameter sets of neighbour catchments according to the distance (proximity rank). In the article, they use 20 % of the distance between outlets + 80 % of the distance between centroids. However, we could use something more complex such as the Ghosh distance.
Step 2: use these parameter sets on the poorly gauged catchments and calculate an error criterion (don’t forget to transform the X4 parameter to scale it to the surface); rank the parameter sets according to the performance (performance rank). In the article, they use the RMSE, which is advised if there is not much data.
Step 3: combine ranks, through a weighted average of proximity and performance ranks.
![image](/uploads/c8ecb3a1bf0148950544145158622d11/image.png)
Step 4: use a selection of M parameter sets with the best combined rank and average the simulations on the poorly gauged station.
According to Rojas-Serna et al. (2016), M depends on the model (e.g. M = 7 for GR4J and M = 9 for TOPM). Also, alpha depends on the data availability (alpha is low when there are many data, and vice versa). It seems that when at least 40 observed values are available, alpha is very close to 0. I would therefore say that if we can get enough data (> 40 values), then it means that we can simply use a classical calibration.
If we have only instantaneous discharge data:
It is necessary to transform the instantaneous discharge data into data at the model time step, and then apply the methodology just described above. Using a close catchments that has discharge values at the same time steps could help. It is advised to do that only if the response time of the catchment is higher than the time step of the model, in order to limit the variability.
**Implementation in airGRiwrm**
_Ungauged case_
Option 1
Nothing to do, this is preprocessing.
Option 2
Nothing to do, this is preprocessing.
Option 3
I do not develop, I know that @david.dorchies is on it.
_Poorly gauged case_
The described methodology has to be used before using airGriwrm. Then, we can just provide a fixed parameter set.
**Others**
Laurent is testing the options 1 and 2 with around 600 stations over France, and using 90% of stations for calibration, 10% for evaluation. It could be interesting to test option 3 when it is ready.
In case of pporly gauged catchments, if there are more than 40 observations available, then regionalising neighbouring catchments with a lumped model is advised.
**Miscellaneous**
For Explore2, we can add the stations that were discarded because there are less than 27 years of data (because we want to simulate 4000 catchments over France).
Léonard implemented an API for retrieving quality and quantity data that could help (shorter time series or instantaneous data?).
If discharge data are of poor quality, then the k value of the regularisation could be modified to be higher than 0.15.
Were suggested to perform the 90/10% calibration/evaluation exercise: make a group for small catchments, or other characteristics.
**References **
Oudin, L., V. Andréassian, C. Perrin, C. Michel, and N. Le Moine, 2008. Spatial proximity, physical similarity and ungaged catchments: confrontation on 913 French catchments, Water Resour. Res., 44, W03413, doi:10.1029/2007WR006240.
Rojas-Serna, C., Lebecherel, L., Perrin, C., Andréassian, V. and Oudin, L., 2016. How should a rainfall-runoff model be parameterized in an almost ungauged catchment? A methodology tested on 609 catchments. Water Resour. Res., 52, 6, 4765-4784, doi:10.1002/2015WR018549.