From e6fb23023480f77e3a4f0785b8c7c023a7e749ea Mon Sep 17 00:00:00 2001 From: Sam van der Zwan Date: Tue, 15 Oct 2024 10:44:27 +0200 Subject: [PATCH 1/5] Rewrote part of the controller documentation --- doc/controller/controller.rst | 29 ++++++++++++++---------- doc/controller/main_controller_class.rst | 11 ++++++--- 2 files changed, 25 insertions(+), 15 deletions(-) diff --git a/doc/controller/controller.rst b/doc/controller/controller.rst index 60cfdee7..3886821f 100644 --- a/doc/controller/controller.rst +++ b/doc/controller/controller.rst @@ -1,20 +1,25 @@ Controller ===================================== The controller is responsible for providing set points for the assets in the simulator. -The controller parses the ESDL and creates objects of the assets it is providing set points for. -When a time step is calculated the controller passes back a dict of the set points -for the controllable assets in the network. The key of this dict is the id of the asset. -The value is another dict. The key of this dict is the property which needs to be set -(e.g. supply temperature, heat demand). The value is the set point for this property. -The controller works based on the priority of the source. The controller will first allocate -capacity of the source with the priority of 1. If more capacity is required, the sources with -priority 2 will be used etc. If the demand is lower then the available capacity of the observed -sources, the remaining demand will be equally distributed over the source at the observed priority. -In the case the demand is higher then the available source capacity, a message is passed to the user -and the demand is downscaled to match the available capacity. +The ESDL is parsed in the mapper functions to controller objects. This will result in a controller +class object which can be called each time step. The controller will then calculate the set points +for this time step. It will then pass back the set points to the simulator. +This is done via a dict, where the key is the id of the asset and the value is another dict. +This dict contains the set points for the asset. The key of this dict is the property which needs +to be set (e.g. supply temperature, heat demand). The value is the set point for this property. + +The current controller implementation works based on the priority of the source. +The controller will first allocate capacity of the source with the priority of 1. +If more capacity is required, the sources with priority 2 will be used etc. If the demand is +lower then the available capacity of the observed sources, the remaining demand will be equally +distributed over the source at the observed priority. In the case the demand is higher then the +available source capacity, a message is passed to the user and the demand is downscaled to match +the available capacity. + The controller consists of the following classes: -#. :ref:`main_controller_class`: Main controller class +#. :ref:`main_controller_class`: Main controller class, used to store the assets and calculate the +control value for a time step. #. :ref:`consumer_controller_class`: Class to control consumers in the network #. :ref:`producer_controller_class`: Class to control producers in the network diff --git a/doc/controller/main_controller_class.rst b/doc/controller/main_controller_class.rst index ab5109dc..d7050fe0 100644 --- a/doc/controller/main_controller_class.rst +++ b/doc/controller/main_controller_class.rst @@ -2,10 +2,15 @@ Network controller class ===================================== -The network controller class is hte basic controller class. It stores lists of the controllable +The network controller class is the basic controller class. It stores lists of the controllable assets. The method run_time_step is used to get the controller settings for the given time step. -For developers if you want to implement a new controller a class can be created with its own logic -as long as there is a method run_time_step that returns the controller settings. + +You can create your own controller class by implementing a new controller class with its own logic. +This class should inherit from the NetworkControllerAbstract class. + +.. autoclass:: omotes_simulator_core.entities.network_controller_abstract.NetworkControllerAbstract + :members: + :no-index: .. autoclass:: omotes_simulator_core.entities.network_controller.NetworkController :members: From 7cb62b6ca68f1bd371db74b27d92cb0f093e5eb1 Mon Sep 17 00:00:00 2001 From: Sam van der Zwan Date: Tue, 15 Oct 2024 11:12:16 +0200 Subject: [PATCH 2/5] Added trying to build local package to enviroment --- doc/requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/requirements.txt b/doc/requirements.txt index b47a5d72..0ea2248e 100644 --- a/doc/requirements.txt +++ b/doc/requirements.txt @@ -3,4 +3,4 @@ sphinx-rtd-theme>=1.0.0 sphinxcontrib-bibtex>=2.4.2 python_docs_theme furo -omotes-simulator-core \ No newline at end of file +. \ No newline at end of file From c77e281e4ecbe388f20db054eb619b91ef3a59da Mon Sep 17 00:00:00 2001 From: Sam van der Zwan Date: Tue, 15 Oct 2024 12:36:38 +0200 Subject: [PATCH 3/5] Added files which need to be included in the packages for local install --- pyproject.toml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/pyproject.toml b/pyproject.toml index 1dc36558..2df18cbc 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -75,9 +75,14 @@ count_commits_from_version_file = true dev_template = "{tag}.dev{ccount}" dirty_template = "{tag}.dev{ccount}" +[tool.setuptools] +include-package-data = true -# [tool.setuptools] -# packages = ["src/omotes_simulator_core"] +[tool.setuptools.package-data] +"omotes_simulator_core" = ["solver/utils/temp_props.csv", "VERSION"] + +#[tool.setuptools] +#packages = ["src/omotes_simulator_core"] [tool.pytest.ini_options] addopts = "--cov=omotes_simulator_core --cov-report html --cov-report term-missing --cov-fail-under 80" From 0fc4f1d536518515a09f69d801cf5c5c1628bc8f Mon Sep 17 00:00:00 2001 From: Sam van der Zwan Date: Tue, 15 Oct 2024 12:55:41 +0200 Subject: [PATCH 4/5] Added ates controller documentation. Update the other parts with description how ates works --- doc/controller/assets/ates.rst | 10 ++++++++++ doc/controller/controller.rst | 11 +++++++++-- doc/controller/main_controller_class.rst | 2 +- 3 files changed, 20 insertions(+), 3 deletions(-) create mode 100644 doc/controller/assets/ates.rst diff --git a/doc/controller/assets/ates.rst b/doc/controller/assets/ates.rst new file mode 100644 index 00000000..0917abeb --- /dev/null +++ b/doc/controller/assets/ates.rst @@ -0,0 +1,10 @@ +.. _ates_controller_class: + +Ates controller class +===================================== +The Ates controller class is used to control the an ATES cluster. ATES stands for Aquifier thermal energy storage. + + +.. autoclass:: omotes_simulator_core.entities.assets.controller.controller_storage.ControllerStorage + :members: + :no-index: \ No newline at end of file diff --git a/doc/controller/controller.rst b/doc/controller/controller.rst index 3886821f..037a064a 100644 --- a/doc/controller/controller.rst +++ b/doc/controller/controller.rst @@ -16,12 +16,18 @@ distributed over the source at the observed priority. In the case the demand is available source capacity, a message is passed to the user and the demand is downscaled to match the available capacity. +When an storage is present in the network, the controller will first allocate the capacity of the +sources to meet the demand of the consumers. The remaining capacity will be used to charge the storage. +When the capacity of the sources is not sufficient to meet the demand of the consumers, +the controller will use the storage to meet the remaining demand. This is a very simple +implementation of a control strategy. In future more complex strategies might be added. + The controller consists of the following classes: -#. :ref:`main_controller_class`: Main controller class, used to store the assets and calculate the -control value for a time step. +#. :ref:`main_controller_class`: Main controller class, used to store the assets and calculate the control value for a time step. #. :ref:`consumer_controller_class`: Class to control consumers in the network #. :ref:`producer_controller_class`: Class to control producers in the network +#. :ref:`ates_controller_class`: Class to control Ates cluster in the network **Contents** @@ -32,4 +38,5 @@ control value for a time step. main_controller_class assets/consumer assets/producer + assets/ates diff --git a/doc/controller/main_controller_class.rst b/doc/controller/main_controller_class.rst index d7050fe0..d58752cf 100644 --- a/doc/controller/main_controller_class.rst +++ b/doc/controller/main_controller_class.rst @@ -3,7 +3,7 @@ Network controller class ===================================== The network controller class is the basic controller class. It stores lists of the controllable -assets. The method run_time_step is used to get the controller settings for the given time step. +assets. The method update_setpoints is used to get the controller settings for the given time step. You can create your own controller class by implementing a new controller class with its own logic. This class should inherit from the NetworkControllerAbstract class. From 58ed287caf531cad0a476ec0d8c68167d1335144 Mon Sep 17 00:00:00 2001 From: Sam van der Zwan Date: Thu, 17 Oct 2024 12:59:55 +0200 Subject: [PATCH 5/5] Adjustements to documenation based on review --- doc/controller/controller.rst | 39 +++++++++++------------- doc/controller/main_controller_class.rst | 8 ++--- 2 files changed, 22 insertions(+), 25 deletions(-) diff --git a/doc/controller/controller.rst b/doc/controller/controller.rst index 037a064a..8e42c15e 100644 --- a/doc/controller/controller.rst +++ b/doc/controller/controller.rst @@ -1,26 +1,23 @@ Controller ===================================== -The controller is responsible for providing set points for the assets in the simulator. -The ESDL is parsed in the mapper functions to controller objects. This will result in a controller -class object which can be called each time step. The controller will then calculate the set points -for this time step. It will then pass back the set points to the simulator. -This is done via a dict, where the key is the id of the asset and the value is another dict. -This dict contains the set points for the asset. The key of this dict is the property which needs -to be set (e.g. supply temperature, heat demand). The value is the set point for this property. - -The current controller implementation works based on the priority of the source. -The controller will first allocate capacity of the source with the priority of 1. -If more capacity is required, the sources with priority 2 will be used etc. If the demand is -lower then the available capacity of the observed sources, the remaining demand will be equally -distributed over the source at the observed priority. In the case the demand is higher then the -available source capacity, a message is passed to the user and the demand is downscaled to match -the available capacity. - -When an storage is present in the network, the controller will first allocate the capacity of the -sources to meet the demand of the consumers. The remaining capacity will be used to charge the storage. -When the capacity of the sources is not sufficient to meet the demand of the consumers, -the controller will use the storage to meet the remaining demand. This is a very simple -implementation of a control strategy. In future more complex strategies might be added. +The controller manages set points for assets in the simulator. ESDL data is parsed by mapper +functions into controller objects. These controller objects are stored in an overarching +controller class, which is invoked at each time step to calculate and +return the set points for that step. These set points are passed back to the simulator in a +dictionary format, where the key is the asset ID, and the value is another dictionary. +This inner dictionary holds the set points, with the keys being properties (e.g., supply +temperature, heat demand) and the values being their corresponding set points. + +The overarching controller class prioritizes source allocation based on a priority system. +It first assigns capacity from priority 1 sources. If more capacity is needed, +it moves to priority 2, and so on. If demand is lower than the available capacity at a +given priority, the excess is equally distributed across the sources. If demand exceeds capacity, +a message is sent to the user, and demand is downscaled to match available resources. + +When storage is present, the controller first allocates source capacity to meet consumer demand. +Any remaining capacity is used to charge the storage. If source capacity is insufficient, the +controller taps into the storage to meet the remaining demand. This basic control strategy may +be extended with more complex strategies in the future. The controller consists of the following classes: diff --git a/doc/controller/main_controller_class.rst b/doc/controller/main_controller_class.rst index d58752cf..843ec73c 100644 --- a/doc/controller/main_controller_class.rst +++ b/doc/controller/main_controller_class.rst @@ -2,11 +2,11 @@ Network controller class ===================================== -The network controller class is the basic controller class. It stores lists of the controllable -assets. The method update_setpoints is used to get the controller settings for the given time step. +The NetworkController class serves as the base controller, managing lists of controllable assets. +The update_setpoints method retrieves controller settings for a specific time step. -You can create your own controller class by implementing a new controller class with its own logic. -This class should inherit from the NetworkControllerAbstract class. +To create a custom controller, implement a new class with your desired logic and inherit from +the NetworkControllerAbstract class. .. autoclass:: omotes_simulator_core.entities.network_controller_abstract.NetworkControllerAbstract :members: