From cdb9b613d4adb1b7903b414623d0bbbe8d756ce1 Mon Sep 17 00:00:00 2001 From: Victor Garcia Reolid Date: Wed, 20 Sep 2023 16:16:29 +0200 Subject: [PATCH] add imgs Signed-off-by: Victor Garcia Reolid --- documentation/tut/toy-example-expanded.rst | 23 ++++++++++++++++++++++ documentation/tut/toy-example-reporter.rst | 6 ++++-- 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/documentation/tut/toy-example-expanded.rst b/documentation/tut/toy-example-expanded.rst index 8469dcc54..695c9308c 100644 --- a/documentation/tut/toy-example-expanded.rst +++ b/documentation/tut/toy-example-expanded.rst @@ -103,6 +103,29 @@ First, during the sunny hours of the day, when solar power is being send to the Second, charging of the battery is also changed a bit (around 10am), as less can be discharged later. +Moreover, we can use reporters to compute the capacity headroom (see :ref:`tut_toy_schedule_process` for more details). The image below shows that the scheduler is respecting the capacity limits. + +.. image:: https://github.com/FlexMeasures/screenshots/raw/main/tut/toy-schedule/sensor-data-headroom-pv.png + :align: center +| + +In the case of the scheduler that we run in the previous tutorial, the PV is not taken into consideration and the discharge power exceeds the headroom: + +.. image:: https://github.com/FlexMeasures/screenshots/raw/main/tut/toy-schedule/sensor-data-headroom-pv.png + :align: center +| + We hope this part of the tutorial shows how to incorporate a limited grid connection rather easily with FlexMeasures. There are more ways to model such settings, but this is a straightforward one. This tutorial showed a quick way to add an inflexible load (like solar power) and a grid connection. In :ref:`tut_toy_schedule_process`, we'll turn to something different: the optimal timing of processes with fixed energy work and duration. + + + + + + + + +.. image:: https://github.com/FlexMeasures/screenshots/raw/main/tut/toy-schedule/sensor-data-headroom-nopv.png + :align: center +| \ No newline at end of file diff --git a/documentation/tut/toy-example-reporter.rst b/documentation/tut/toy-example-reporter.rst index 0c069c025..2e6f704b4 100644 --- a/documentation/tut/toy-example-reporter.rst +++ b/documentation/tut/toy-example-reporter.rst @@ -148,8 +148,9 @@ we are going to create share the same `config`. The `config` defines the price s that it will return costs as positive values and revenue as negative values. Still, we need to define the parameters. The three reports share the same structure for the parameters with the following fields: -* `input`: sensor that stores the power/energy flow. The number of sensors is limited to 1. -* `output`: sensor to store the report. We can provide sensors with different resolutions to store the same results at different time scales. + + - `input`: sensor that stores the power/energy flow. The number of sensors is limited to 1. + - `output`: sensor to store the report. We can provide sensors with different resolutions to store the same results at different time scales. .. note:: It's possible to define the `config` and `parameters` in JSON or YAML formats. @@ -242,5 +243,6 @@ Check the results `here `_. The image should b :align: center | + Now, we can compare the results of the reports to the ones we computed manually in :ref:`this table `). Keep in mind that the report is showing the profit of each 15min period and adding them all shows that it matches with our previous results.