airGRiwrm issueshttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues2021-03-07T18:13:38+01:00https://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/31Plot simulated flows of all the nodes in m3/s2021-03-07T18:13:38+01:00Dorchies DavidPlot simulated flows of all the nodes in m3/sFrom the data.frame created by #30, plot the times series of the simulated flows.From the data.frame created by #30, plot the times series of the simulated flows.v0.5.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/30RunModel of GRiwrm networks: add a data.frame of simulated flows in OutputsModel2021-03-07T18:13:36+01:00Dorchies DavidRunModel of GRiwrm networks: add a data.frame of simulated flows in OutputsModelCurrently, `GRiwrmOutputsModel` produced by either `RunModel.GRiwrmInputsModel` or `RunModel.Supervisor` produce a list of `airGR::OutputsModel` where only GR or GRSD outputs are available.
It would be consistant to get a data.frame wit...Currently, `GRiwrmOutputsModel` produced by either `RunModel.GRiwrmInputsModel` or `RunModel.Supervisor` produce a list of `airGR::OutputsModel` where only GR or GRSD outputs are available.
It would be consistant to get a data.frame with dates and one column by node of the complete GRiwrm network in these outputs including flows that don't depend on a model like injected flows (see vignette V03) or flows influenced by a controller.
There are two possibilities for storing such a data.frame in the `GRiwrmOutputsModel` object:
1. add a specific items between other items of the list which are `airGR::OutputsModel` objects. This item should be named with a reserved name (E.g.: "\_\_Qsim\_\_") in order to not match with an existing node name.
2. add an attribute "Qsim" to the `GRiwrmOutputsModel` object with `attr(x, "Qsim") <- data.frame(...)`.
Second solution has my preference because grouping `airGR::OutputsModel` object and a data.frame in the same list forces to handle exception in any process that loop over the list items of `GRiwrmOutputsModel`. Retrieving the data.frame is then done with the simple instruction: `attr(x, "Qsim")` with `x` a `GRiwrmOutputsModel` object.v0.5.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/28RunModel: Uncoupling of hydrological and hydraulic models2021-03-07T18:13:37+01:00Dorchies DavidRunModel: Uncoupling of hydrological and hydraulic modelsFor #19, hydrological model and hydraulic model should be run separately.
The whole picture has the goal to isolated the most as possible the part of the model that should be run time step by time step:
![image](/uploads/364f4ba160cc3b...For #19, hydrological model and hydraulic model should be run separately.
The whole picture has the goal to isolated the most as possible the part of the model that should be run time step by time step:
![image](/uploads/364f4ba160cc3b9c01e0484a9c2d6a58/image.png)v0.5.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/25Set GRiwrm rownames with ID2021-01-07T09:21:56+01:00Dorchies DavidSet GRiwrm rownames with IDwith `rownames(griwrm) <- griwrm$id` and after that we could write `griwrm[id,]` instead of `griwrm[griwrm$id==id,]`
Maybe a benchmark will prove that it is faster.with `rownames(griwrm) <- griwrm$id` and after that we could write `griwrm[id,]` instead of `griwrm[griwrm$id==id,]`
Maybe a benchmark will prove that it is faster.v0.5.0Dorchies DavidDorchies Davidhttps://gitlab.irstea.fr/in-wop/airGRiwrm/-/issues/19Feature request: feedback control2021-03-07T18:13:38+01:00Dorchies DavidFeature request: feedback controlHuman influenced systems are subject to 2 kind of controls: open-loop and closed-loop ones (See https://en.wikipedia.org/wiki/Control_theory#Open-loop_and_closed-loop_(feedback)_control).
Here in our model controls, there will be time s...Human influenced systems are subject to 2 kind of controls: open-loop and closed-loop ones (See https://en.wikipedia.org/wiki/Control_theory#Open-loop_and_closed-loop_(feedback)_control).
Here in our model controls, there will be time series of releases or withdrawals of water in some locations in the system. Let's call these releases or this withdrawals "control variables".
Open-loop issue has been already addressed in #5. Indeed, in this case, control variables can be represented has a predefined time series directly applied as an upstream flow in the lag model. The model can then be run by proceeding each part from upstream to downstream for the entire time series.
For the closed loop so called "feedback control", a control variable at one location in the model depends on data calculated at previous time steps. See the small example below:
![image](/uploads/e4b7d72056086e65e1432e59b0ce6284/image.png)
If these requested data are upstream then they are available and we can continue to pre-processing the control variable and run the simulation from upstream to downstream for the entire time series. If however, the control variable depends on data calculated downstream in previous time steps, we need to run the entire model time
step by time step in order to proceed this feedback.
Running the model time step by time step would lead to a unsustainable computation burden.
One interesting thing is that the hydrological part of the model is not subject to this feedback (There is no feedback on rainfall and evapotranspiration). So we can continue to run the GR models on the entire time series and only the hydraulic part will be subject to the feedback. If we want to refine again the process, we can apply this feedback only on the parts downstream the control variables.
The implementation of such feedback in the model is still to invent. The SIC software (https://sic.g-eau.fr) implements such feedback with paradigms coming from the control theories. If think we should be inspired by these paradigms in order to be able to implement a very generic implementation of feedbacks in the model.v0.5.0Dorchies DavidDorchies David