diff --git a/wiki/docs/assets-installation.md b/wiki/docs/assets-installation.md index bd5358d5a..4f9eabe1f 100644 --- a/wiki/docs/assets-installation.md +++ b/wiki/docs/assets-installation.md @@ -144,7 +144,7 @@ The **HeatPumpStrategy** parameters can be set as follows: * **min_temp_C**: (default=50); minimum temperature of the heat pump storage. If the temperature drops below this point, the heat pump buys energy at any cost; * **max_temp_C**: (default=60); maximum temperature of the heat pump storage. If the temperature rises above this point, the heat pump does not buy any energy; * **initial_temp_C**: (default=50); initial temperature of the heat pump storage at the beginning of the simulation; - * **external_temp_C_profile**: (mandatory user input); external temperature that influences the efficiency of the heat pump. If this parameter is selected, the external temperature is constant for the whole simulation run; + * **source_temp_C_profile**: (mandatory user input); external temperature that influences the efficiency of the heat pump. If this parameter is selected, the external temperature is constant for the whole simulation run; * **tank_volume_l**: (default=50); volume/capacity of the thermal storage tank; * **consumption_kWh**: (mandatory user input); constant amount of energy the heat pump consumes to produce heat, in kWh (can be provided as a constant energy kWh value or as an energy consumption time-series profile, as a dictionary that follows the supported format); * **preferred_buying_rate**: (default=15); rate in cts/kWh that determines the [trading strategy](heat-pump.md#heat-pump-asset-trading-strategy); @@ -159,7 +159,7 @@ Asset(name="Heat Pump", strategy=MultipleTankHeatPumpStrategy()) ``` The MultipleTankHeatPumpStrategy parameters can be set as follows: - * **tank_parameters**: (mandatory user input, list of TankParameters); list of parameters for each water tank connected to the heat pump. The parameters for each water tank are min_temp_C, max_temp_C, initial_temp_C, tank_volume_l with the same default values and behaviour as the corresponding parameters of the HeatPumpStrategy; + * **tank_parameters**: (mandatory user input, list of TankParameters) with configuration options provided below;maximum_power_rating_kW: same as HeatPumpStrategy; * **maximum_power_rating_kW**: same as HeatPumpStrategy; * **external_temp_C_profile**: same as HeatPumpStrategy; * **consumption_kWh**: same as HeatPumpStrategy; @@ -168,8 +168,34 @@ The MultipleTankHeatPumpStrategy parameters can be set as follows: * **order_updater_parameters**: same as HeatPumpStrategy; * **heat_demand_Q_profile**: same as HeatPumpStrategy +##### Tank Parameters Configuration -#### Heat Pump Price Strategy Configuration +Multiple tank types can be configured in the MultipleTankHeatPumpStrategy by adding the type name to the tank_parameters list in the heat pump configuration. Currently two tank types are supported in the tank_parameters list: + +* WaterTankParameters +* PCMTankParameters + +Both types share the following general parameter: +name: (default=””) name or label for the tank in order to be able to distinguish the exported results + + * **minitial_temp_C**: (default=50) initial temperature of the tank + * **min_temp_C**: (default=50) minimum temperature of the tank + * **max_temp_C**: (default=60) maximum temperature of the tank + * **loss_per_day_percent**: (default=0): temperature loss per day in percent. If the temperature of the storage is 50 degrees and the loss_per_day_percent was set to 10%, the storage will lose 5 degrees within a day + +These are the type-specific parameters: +**WaterTankParameters** + +* **tank_volume_l**: (default=50) volume of the tank + +**PCMTankParameters** + + * **pcm_tank_type**: (default=PCMType.OM37) type of material inside the pcm tank + * **volume_flow_rate_l_min**: (default=10) volume flow rate of the heat transfer fluid in l/min + * **number_of_plates**: (default=15) number of heat exchanger plates that are situated in the PCM tank and connected in parallel + + +#### Heat Pump Price Configuration In order to configure the heat pump bid pricing, the **order_updater_parameters** should be set by assigning the **HeatPumpOrderUpdaterParameters** data class and its parameters to it: @@ -213,13 +239,13 @@ The **VirtualHeatPumpStrategy** parameters can be set as follows: * **order_updater_parameters**: of type **HeatPumpOrderUpdaterParameters**. A template configuration can be seen [below](#heat-pump-price-strategy-configuration) The initial GSY virtual heat pump strategy assumes that the heat pump is connected to a single water tank. In order to simulate a virtual heat pump that is connected to multiple water tanks, a dedicated strategy, namely MultipleTankVirtualHeatPumpStrategy is also available: -``` +```python Asset(name="Heat Pump", strategy=MultipleTankVirtualHeatPumpStrategy()) ``` The MultipleTankVirtualHeatPumpStrategy parameters can be set as follows: -* **tank_parameters**: (mandatory user input, list of TankParameters); list of parameters for each water tank connected to the virtual heat pump. The parameters for each water tank are min_temp_C, max_temp_C, initial_temp_C, tank_volume_l with the same default values and behaviour as the corresponding parameters of the VirtualHeatPumpStrategy; +* **tank_parameters**: (mandatory user input, list of WaterTankParameters); list of parameters for each water tank connected to the virtual heat pump. The parameters for each water tank are min_temp_C, max_temp_C, initial_temp_C, tank_volume_l with the same default values and behaviour as the corresponding parameters of the VirtualHeatPumpStrategy; * **maximum_power_rating_kW**: same as VirtualHeatPumpStrategy; * **water_supply_temp_C_profile**: same as VirtualHeatPumpStrategy; * **water_return_temp_C_profile**: same as VirtualHeatPumpStrategy; @@ -227,3 +253,38 @@ The MultipleTankVirtualHeatPumpStrategy parameters can be set as follows: * **calibration_coefficient**: same as VirtualHeatPumpStrategy; * **preferred_buying_rate**: same as VirtualHeatPumpStrategy; * **order_updater_parameters**: same as VirtualHeatPumpStrategy + +#### Configuration of Heat Pumps without Tanks + +To configure a heat pump asset without any attached heat tanks in the Grid Singularity Exchange backend code, the following line is to be added to the children's list of one of the areas in the setup file: + +```python +Asset(name="Heat Pump Without Tanks", strategy=HeatPumpStrategyWithoutTanks()) +``` + +The HeatPumpStrategyWithoutTanks parameters can be set as follows: +* **target_temp_C_profile**: (mandatory user input) Temperature profile of the targeted condenser temperature in °C +* **source_temp_C_profile**: same as HeatPumpStrategy; +* **heat_demand_Q_profile**: same as HeatPumpStrategy; +* **consumption_kWh_profile**: same as HeatPumpStrategy; +* **order_updater_parameters**: same as HeatPumpStrategy; +* **source_type**: same as HeatPumpStrategy; +* **cop_model_type**: same as HeatPumpStrategy; + + +#### Configuration of Heat Pumps with SorTES Tanks +To configure a heat pump asset that has a sorption-based heat tank attached in the Grid Singularity Exchange backend code, the following line is to be added to the children's list of one of the areas in the setup file: + +```python +Asset(name="Heat Pump with SorTES tank", strategy=HeatPumpWithSorTesTankStrategy()) +``` + +The HeatPumpWithSorTesTankStrategy parameters can be set as follows: +* **heat_demand_Q_profile**: same as HeatPumpStrategy; +* **target_temp_C_profile**: same as HeatPumpStrategyWithoutTanks; +* **source_temp_C_profile**: same as HeatPumpStrategyWithoutTanks; +* **ambient_temp_C_profile**: temperature profile of the air temperature at the location of the SorTES tank that is used for selecting the correct performance power of the SorTES tank +* **preferred_buying_rate**: (default=20) energy rate in EUR/kWh that marks the border between affordable and expensive energy +* **average_trade_rate**: (constant or profile) this parameter is used for the trading strategy of the heat-pump with SorTES tank. If the average trading rate is lower than the preferred_buying_rate, the SorTES tank is charging (more information here) +* **source_type**: same as HeatPumpStrategy; +* **order_updater_parameters**: same as HeatPumpStrategy; diff --git a/wiki/docs/heat-pumps-general.md b/wiki/docs/heat-pumps-general.md index a87cddb4b..bc91d8553 100644 --- a/wiki/docs/heat-pumps-general.md +++ b/wiki/docs/heat-pumps-general.md @@ -1,9 +1,9 @@ # Heat Pumps and District Heating -A heat pump is an energy asset used to heat water and premises by extracting heat from one place (air source, water source, and ground source/geothermal) and boosting it to a higher temperature level than the source (some heat pumps also have a cooling function but only heating is considered here). Depending on the external temperature and the heating needs, a heat pump usually has a [coefficient of performance (COP) of around 2-4](https://www.sciencedirect.com/topics/engineering/coefficient-of-performance/){target=_blank}, which means that it is able to produce 2-4 kWh of heat by consuming 1 kWh of electricity. In the Grid Singularity Exchange, the heat pump is modelled as a load, which consumes electricity and generates heat (see heat pump configuration options [here](heat-pump.md#heat-pump-asset-configuration-options)). If the heat pump has a storage option (water tank) then this is accounted for by a dedicated [heat pump asset trading strategy](heat-pump.md#heat-pump-asset-trading-strategy), which facilitates flexibility trading by leveraging the heat storage capabilities of the water tank. +A heat pump is an energy asset used to heat water and premises by extracting heat from one place (air source, water source, and ground source/geothermal) and boosting it to a higher temperature level than the source (some heat pumps also have a cooling function but only heating is considered here). Depending on the external temperature and the heating needs, a heat pump usually has a [coefficient of performance (COP) of around 2-4](https://www.sciencedirect.com/topics/engineering/coefficient-of-performance/){target=_blank}, which means that it is able to produce 2-4 kWh of heat by consuming 1 kWh of electricity. In the Grid Singularity Exchange, the heat pump is modelled as a load, which consumes electricity and generates heat (see heat pump configuration options [here](heat-pump.md#heat-pump-asset-configuration-options)). If the heat pump has a storage option (water tank) then this is accounted for by a dedicated [heat pump asset trading strategy](heat-pump.md#heat-pump-asset-trading-strategy), which facilitates flexibility trading by leveraging the heat storage capabilities of the water tank. In addition to the water tank available in the Singularity Map, the Grid Singularity Exchange backend code supports two further heat storage types: a FractLES tank containing an organic phase change material (PCM) and a SorTES tank containing a thermochemical material (TCM). These are documented separately, together with the heat storage flexibility management function that adapts the trading strategy to their physical constraints. For homes (or other energy community participants) that are connected to district heating we have developed a digital twin of a heat pump that mimics and replaces the heat demand currently satisfied by a district heating network, modelled as a virtual heat pump (VHP) with storage and a related trading strategy. This VHP implementation is [available exclusively in the backend source code](virtual-heat-pump.md), since it will likely be used exclusively by energy researchers to simulate how district heating could be replaced by a heat pump to compare their respective performance. Inversely, the VHP can also be used to calculate the heat demand of homes or other energy community participants, and consequently enable the simulation of a district heating connection that would satisfy this heat demand as opposed to electricity assets. Finally, for simulations that simply want to account for the district heating connection without considering a potential replacement with heat pumps, the digital twin of the district heating supply for the measured heat demand can be modelled as a "heat market maker", i.e. digital trading agent with a specific [trading strategy](trading-agents-and-strategies.md) representing the district heating provider, which will only sell heat energy to the heat demand digital twin of the respective community member. The selling price of this market maker will be the district heating price that the heat consumer currently pays, in cents/kWh. The heat demand digital twin, in turn, is modelled as a load with a “consumption profile” defined by the measured heat demand in kWh. Thus, the “heat market maker” will only be used in order to cover the heat demand of the heat load, accounting for the monetary cost of heating. -The heat pump and the virtual heat pump development has been undertaken in the framework of the [HYPERGRYD Project](https://hypergryd.eu/){target=_blank}, funded by the European Union’s H2020 Programme under Grant Agreement No. 101036656. +The heat pump and the virtual heat pump development has been undertaken in the framework of the [HYPERGRYD Project](https://hypergryd.eu/){target=_blank}, funded by the European Union’s H2020 Programme under Grant Agreement No. 101036656. The FractLES (PCM) and SorTES (TCM) heat storage models, the heat storage flexibility management function and the custom COP model integration have been developed in the framework of the ThumbsUp Project, co-funded by the European Union’s Horizon Europe Programme under Grant Agreement No. 101096921. diff --git a/wiki/docs/heat_storages.md b/wiki/docs/heat_storages.md new file mode 100644 index 000000000..395b6e2fd --- /dev/null +++ b/wiki/docs/heat_storages.md @@ -0,0 +1,103 @@ +## Heat Storages + +While the heat pump digital twin in the Grid Singularity maps is limited to a single water tank for heat storage, the Grid Singularity Exchange backend code allows users to configure and add different types of heat storage tanks: +Water tank + +* Water tank +* FractLES short-duration latent thermal energy system, developed by the University of Birmingham (UoB), leverages Phase Change Materials (PCM) to store and release thermal energy by absorbing or releasing heat during their solid-to-liquid phase transition at a specific melting point +* SorTES long-duration sorption thermal energy system, developed by National Research Council of Italy (Consiglio Nazionale delle Ricerche - CNR), leverages thermochemical sorption technology to efficiently store thermal energy and keep it unaffected for long duration. + +The following section describes the implementation methodologies of the FractLES and SorTES tanks, undertaken in the framework of the ThumbsUp project co-funded by the European Union's Horizon Europe Programme under Grant Agreement No. 101096921. Both storage types are available in the Grid Singularity Exchange backend code only; the Singularity Map interface continues to support a single water tank. + + +### FractLES (PCM) Storage Modelling + +The FractLES tank contains an organic phase change material (PCM) that stores heat primarily as latent heat during the phase change between solid and liquid. The general design, drafted in Figure 2.24, consists of a container filled with PCM. Inside the container are multiple heat exchangers, also called plates, connected in parallel. These heat exchangers link the heat source (the heat pump) to the heat sink (such as the floor heating pipes or domestic hot water pipes). +When the tank is charged, the heat transfer fluid, water heated by the heat pump, runs through the plates and warms the PCM, which changes phase from solid to liquid. When the storage is discharged, a valve is turned to connect the heat sink, whose return temperature is lower than the PCM's melting point, causing the PCM to solidify again. For more detailed physical explanations we refer to the FractLES temperature model developed by the University of Birmingham within the ThumbsUp Project [publication pending]. + +
+ ![alt_text](img/schematic_hp_fractles.png){:style="height:450px;width:600px";text-align:center"} +
Figure 2.24: Schematics of Heat Pump with integrated FractLES Storage +
+
+ +In order to simulate the physical part of the FractLES tank, an external model was used. The FractLES temperature model developed by UoB was implemented in the GSY heat pump digital twin by integrating the estimation of the temperature reached by a FractLES storage that was heated by a heat transfer fluid (HTF) with a specific temperature in the GSY twin’s heat storage model. The UoB FractLES model is essentially a mathematical model that comprises a set of differential, energy balance equations, each of which calculates the heat transfer for one control volume (a subdivision of the heat exchanger plate). Different equations are employed for charging and discharging calculation, requiring a dedicated submodel to simulate each of these operations. The inputs to both charging and discharging models are the mass flow rate and the HTF inlet temperature, and its outputs are the outlet temperatures of the HTF and the PCM, as well as the average state-of-charge (SOC) of all control volumes. + +Since each material has different properties that affect heat charge and discharge potential, such as specific heat, phase change temperature, the GSY heat storage digital twin was parameterized to support multiple material types (OM37, OM42, OM46, OM50, OM55, OM65). This material type property selection feature of the GSY heat storage digital twin was implemented in a way that it would be open for extension, thereby facilitating the addition of more Organic Phase Change materials in the future. + +#### Heat Storage Flexibility Management Function +For the FractLES tank, the default trading strategy is equal to the water tank [trading strategy](#heat-pump-asset-trading-strategy). However, the calculation of the energy that has to be bought by the heat pump is different, because the PCM temperature and the state of charge cannot be easily converted to heat energy (and subsequently electrical energy) due to the complexity of the FractLES model equations. The following simplified formula is used to estimate the heat energy: + + +$$ Q = V * \rho_{reference} * c_p * (T_{PCMmax}-T_{PCMcurrent})$$ + +Although this formula also introduced certain inaccuracies in estimating the available heat energy that can be stored in the heat storage, it was possible to mitigate and sufficiently limit the scope for error by continuously updating the energy estimate every 15 minutes throughout the course of the simulation. + +Following the heat storage model available heat energy estimation, the electrical energy that has to be produced by the heat pump digital twin is calculated with the following formula implemented in the GSY heat pump digital twin (for more, see the [related GSY Wiki Documentation](#heat-pumps-and-district-heating) where the COP calculation generally follows the model proposed by [Ruhnau et al.](https://www.nature.com/articles/s41597-019-0199-y){target=_blank} using the following input parameters (termed here Universal COP model): + +$$E_{tobuy} =min(P_{max}∙ t_{slot}, Q / COP) $$ + +where: + +* $P_{max}$ is the maximum power rating +* $t_{slot}$ is the slot length +* $Q$ is the available heat energy estimated by the heat storage model +* $COP$ is the coefficient of performance of the heat pump; depends on the heat pump type, and $T = T_{curr} - T_{ambient}$ + +Due to the physical properties of the PCM heat storages, they are not capable of optimally switching between charge and discharge states. To mitigate this limitation, the GSY heat pump trading strategy was extended to support a heat storage SOC management algorithm that would leverage the preferred buying rate in conjunction with the estimation of the volume of heat that can be stored, thereby minimising the state changes between charges and discharges. That way, the PCM heat storages operate in accordance to their physical properties, while maximising the monetary benefits from the heat storage operation. + +For the heat storage SOC management algorithm to adhere to the physical properties of the PCM heat storages (multiple hours required to fully charge), a time duration threshold is configured that guarantees the heat storage will not change its state from charging to discharging or discharging to charging for this duration, with two (2) hours as a default value. The algorithm has been programmed to follow the state change diagram illustrated in Figure 2.25 below. + +In addition, the heat storage should not transition to a charging or discharging state without ensuring that there is sufficient SOC for charging / discharging for the duration that the time threshold prevents the state change. For this reason, two configurable minimum and maximum SOC values have been determined that control the minimum and maximum SOC that will allow a transition to the discharging and charging state respectively. The minimum SOC limit is set to a default value of 5%, while the maximum SOC limit is set to 95%, to ensure that the heat storage will not reach the maximum or minimum SOC when entering the charging or the discharging state. Moreover, to ensure that charging the heat storage is economical, the heat storage will only enter the charge state if the energy that the heat storage can procure is less expensive than the average energy rate of the energy provider. Thus, the heat storage SOC management algorithm ensures the maximization of the economic benefits of the heat storage, while safeguarding its operation. + +
+ ![alt_text](img/state_trans_diagram_soc_heat_storage.png){:style="height:450px;width:450px";text-align:center"} +
Figure 2.25: State transition diagram of the Grid Singularity heat storage SOC management algorithm, part of the GSY heat pump trading strategy +
+
+ + +### SorTES (TCM) Storage Modelling + +The operational characteristics of the SorTES tank differ substantially from those of the FractLES. The general functionality of the SorTES thermal storage is outlined only at a high level, while its charging and discharging processes, which determine the trading strategy, are described in detail below. For more detailed information on this model, please see the following source [Gado et al., 2025](https://doi.org/10.1016/j.enconman.2025.119584){target=_blank}. + +##### Charging +Due to inherent physical constraints, the thermochemical material requires elevated temperatures in the range of 60–90 °C to undergo charging, a temperature regime that cannot be supplied by a typical domestic heat pump. To circumvent this limitation, the digital twin implemented within the GSY simulation tool models the charging process via a resistive heater, which converts electrical energy into thermal energy with a COP=1. Following, the generated heat is transferred to the sorbent material, thereby driving the desorption of the adsorbate. In parallel, a dry cooler is operated to condense the released adsorbate in the condenser and to extract it from the sorbent matrix. Notably, the dry cooler exhibits a markedly higher efficiency than the resistive heater; the corresponding performance data have been supplied by CNR - Consiglio Nazionale delle Ricerche, the Italian National Research Council, as part of EU ThumbsUp project collaboration. + +##### Discharging +The discharging process is initiated by re-evaporating the adsorbate, which is subsequently re-adsorbed by the sorbent material. This exothermic adsorption reaction releases thermal energy that is recovered via a heat exchanger and delivered to the building's underfloor heating system. The temperatures extracted in this process typically range between 25 °C and 45 °C; for the purposes of the digital twin in the GSY simulation tool, a representative value of 35 °C was adopted. Evaporation of the adsorbate is achieved by means of a dry heater or resistive heater, again assumed to operate at a COP=1. +Theoretical performance data provided by CNR encompass both the charging and discharging power values across a range of operating temperatures. In addition, the data include the heat consumed by the evaporator and the heat rejected by the condenser, both of which depend on the ambient temperature at the respective site. +These inputs informed the development of the heat pump model coupled with a SorTES tank, as implemented in the GSY simulation tool and illustrated in Figure 2.26. + +
+ ![alt_text](img/schematic_hp_sortes.png){:style="height:400px;width:700px";text-align:center"} +
Figure 2.26: Schematics of Heat Pump with integrated SorTES Storage + +
+
+ +##### Charging +The total electrical energy that the heat pump strategy must procure in a single market slot to charge the SorTES tank, denoted $E_{charge}$ is given by: + +$$E_{charge} = E_{heater} + E_{condenser} +E_{demand}$$ + +where $E_{heater}$ denotes the energy required to operate the heater that charges the TCM, $E_{condenser}$ represents the energy consumed by the dry cooler for condensing the adsorbate, and $E_{demand}$ corresponds to the building's heat demand per market slot, converted into an equivalent electrical demand using the Universal COP model described previously. + + +##### Discharging +Analogously, the electrical energy that the heat pump strategy must purchase in one market slot during the discharging phase, $E_{discharge}$ , is expressed as: + +$$E_{discharge} = E_{demand} - E_{storage} + E_{evaporator}$$ + +where $E_{storage}$ denotes the thermal energy that can be extracted from the TCM over the duration of one market slot, $E_{evaporator}$ is the energy required to operate the electric heater driving the evaporation of the adsorbate, and $E_{demand}$ is again the heat demand per market slot expressed as an electrical equivalent. + +### SorTES Trading Strategy +The decision logic governing whether to charge, discharge, or operate the heat pump solely to meet the instantaneous heat demand of the building is implemented by a slightly modified variant of the [Heat Storage Flexibility Management Function](#heat-storage-flexibility-management-function). This function evaluates a user-configurable threshold for the energy price offered on the current market, together with a configurable number of future market intervals. Specifically, the trading strategy uses the forecasted average trading rate as its primary input: if the predicted average rate over the next n time slots falls below the specified threshold, the charging process is triggered. Conversely, if the average rate over the next n market slots exceeds the threshold and the storage is sufficiently charged, the discharging process is initiated. In the event that the storage is depleted and no affordable energy is available within the next n market slots, the strategy procures only the electrical energy strictly required by the heat pump to satisfy the building's heat demand. +The principal inputs to the SorTES heat pump trading strategy are therefore: + +* The average trading rate as a function of time, spanning the entire simulation period. +* The preferred buying rate, which serves as the threshold determining whether to charge or discharge. + +The trading strategy initiates a discharge event only under the condition that the prevailing thermal demand is greater than or equal to the quantity of thermal energy that can be extracted from the sorption thermal energy storage (SorTES) within a single market interval. Should this criterion fail to be satisfied, the discharging process is suspended for the duration of the corresponding market slot, and the heat pump is instead operated as the sole thermal supply unit, thereby covering the entirety of the heat demand during that interval. + +The SorTES tank digital twin only operates in energy space rather than incorporating electrochemical state variables. diff --git a/wiki/docs/img/schematic_hp_fractles.png b/wiki/docs/img/schematic_hp_fractles.png new file mode 100644 index 000000000..590731d4b Binary files /dev/null and b/wiki/docs/img/schematic_hp_fractles.png differ diff --git a/wiki/docs/img/schematic_hp_sortes.png b/wiki/docs/img/schematic_hp_sortes.png new file mode 100644 index 000000000..393f9bd12 Binary files /dev/null and b/wiki/docs/img/schematic_hp_sortes.png differ diff --git a/wiki/docs/img/state_trans_diagram_soc_heat_storage.png b/wiki/docs/img/state_trans_diagram_soc_heat_storage.png new file mode 100644 index 000000000..b13e99310 Binary files /dev/null and b/wiki/docs/img/state_trans_diagram_soc_heat_storage.png differ diff --git a/wiki/docs/virtual-heat-pump.md b/wiki/docs/virtual-heat-pump.md index fd4e62939..da0a22bf3 100644 --- a/wiki/docs/virtual-heat-pump.md +++ b/wiki/docs/virtual-heat-pump.md @@ -20,7 +20,7 @@ The heat pump operation steps are the following: Unlike the heat pump model described above, district heating networks use water pipes that are directly connected to the building, and usually the supply temperature, return temperature and water flow rates are measured in order to facilitate customer billing. The virtual heat pump model can use these district heating measurements to calculate the heat demand of the building. The heat demand is then provided as an input for the VHP model to calculate the energy that needs to be consumed by the heat pump in order to provide the heat demand, taking into account the flexibility that the water tank storage provides. -A configuration of multiple water tanks is also supported, allowing the monitoring and analysis of the temperature of each individual water tank that is connected to the heat pump. Since multiple water tanks are generally installed to satisfy different sources of heat demand (e.g. space heating and domestic hot water), modelling multiple water tanks provides further insights regarding the heat pump’s operational effectiveness to meet these different types of heat demand. In such a configuration, the heat exchangers between the condenser side of the heat pump and each water tank (#4 in Figure 2.29) are assumed to be identical and the heat generated by the heat pump is attributed proportionally to all water tanks, consequently increasing the temperature of each water tank based on its portion of the generated heat. Conversely, the heat demand is also proportionally split to all water tanks, decreasing the temperature of each water tank commensurately. +A configuration of multiple water tanks is also supported, allowing the monitoring and analysis of the temperature of each individual water tank that is connected to the heat pump. Only water tanks can be configured in this way, FractLES and SorTES tanks are not supported. Since multiple water tanks are generally installed to satisfy different sources of heat demand (e.g. space heating and domestic hot water), modelling multiple water tanks provides further insights regarding the heat pump’s operational effectiveness to meet these different types of heat demand. In such a configuration, the heat exchangers between the condenser side of the heat pump and each water tank (#4 in Figure 2.29) are assumed to be identical and the heat generated by the heat pump is attributed proportionally to all water tanks, consequently increasing the temperature of each water tank based on its portion of the generated heat. Conversely, the heat demand is also proportionally split to all water tanks, decreasing the temperature of each water tank commensurately. diff --git a/wiki/mkdocs.yml b/wiki/mkdocs.yml index 671aa646a..fd57cd5da 100644 --- a/wiki/mkdocs.yml +++ b/wiki/mkdocs.yml @@ -23,6 +23,7 @@ nav: - 'Heat Pump & Virtual Heat Pump Overview': 'heat-pumps-general.md' - 'Heat Pump': 'heat-pump.md' - 'Virtual Heat Pump': 'virtual-heat-pump.md' + - 'Heat Storages': 'heat_storages.md' - 'Community Settings': 'community-settings.md' - 'Grid Market Settings': 'grid-market-settings.md' - 'Events (Adding, Removing Assets, etc.)': 'events.md'