Welcome to EMB3RS - Core Functionalities’s documentation!

This manual describes one of the modules of the tool created within the Horizon 2020 EMB3RS project: the Core Functionalities (CF) module. The module is responsible for the characterization of sources (suppliers fo excess heat) and sinks (consumers of heat). Moreover, performs internal heat recovery simulations to the sources - Pinch Analysis and ORC design and assesses the technologies to connect both sinks and sources to a possible District Heating Network (DHN).

The EMB3RS project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 847121. This module is part of a larger assessment toolbox called ‘EMB3RS platform’. More information on the EMB3RS project can be found at https://www.emb3rs.eu/ .

EMB3RS project

EMB3Rs (“User-driven Energy-Matching & Business Prospection Tool for Industrial Excess Heat/Cold Reduction, Recovery and Redistribution) is a European project funded under the H2020 Programme (Grant Agreement No.847121) to develop an open-sourced tool to match potential sources of excess thermal energy with compatible users of heat and cold. More information about the EMB3RS project can be found on the EMB3RS website .

Users, like industries and other sources that produce excess heat, will provide the essential parameters, such as their location and the available excess thermal energy. The EMB3Rs platform will then autonomously and intuitively assess the feasibility of new business scenarios and identify the technical solutions to match these sources with compatible sinks. End users such as building managers, energy communities or individual consumers will be able to determine the costs and benefits of industrial excess heat and cold utilisation routes and define the requirements for implementing the most promising solutions. The EMB3Rs platform will integrate several analysis modules that will allow a full exploration of the feasible technical routes to the recovery and use of the available excess thermal energy. Several other modules are a part of the EMB3RS platform. Each module will be used to conduct a special purpose task or analysing excess heat and cold recovery. The models and their primary functionalities are specified below

Core functionalities (CF) module

The purpose of the CF module is to provide a comprehensive quantification of the energy flows of the EMB3RS platform objects (sinks, sources, and links) and costs associated with different options for excess H/C recovery and use. This information is used by the other analysis modules (GIS, TEO, MM and BM) to perform simulations according to user specifications. The CF module has two main functionalities:

Full characterization of objects – e.g., in terms of processes, equipment, building characteristics

To carry out a preliminary analysis of available supply and demand - described as a simulation feature within the CF.

GIS module

The purpose of the GIS model within EMB3Rs is to analyse possible network solutions for a given set of sources and sinks as well as an assumption of related network heat/cold losses and costs. The GIS thereby finds such a network solution along the existing Open Street Map (OSM) Road Network connecting all sources and sinks. It currently outputs a graph/map that lets the user check the specifications of every single pipe element from the network found and a table that illustrates all source/sink specific losses, costs, network length and installed pipe capacity.

TEO Module

The TEO module identifies least-cost combinations of technologies for using and conveying excess heating or cooling (HC) from defined sources to defined sinks. The user (representing the excess heat producer - i.e., source – or a demand point – i.e., sink) wants to evaluate the least-cost options of utilising excess HC generated to meet the heating/cooling demand for one or more known/assumed sinks. The objective of the optimisation is to find the least-cost mix of technologies (in terms of installed capacities – typically, in power units) and match between sources and sinks (in terms of energy flows) that satisfies the demands under constraints dictated by regulation, availability of heat, load profiles, techno-economic characteristics of technologies, investment plans.

Market Module

The Market Module (MM) will provide the user with economic and fairness indicators like energy transaction, market price, social welfare, fairness among prices. This will be done by short-term and long-term market analyses that simulate various market structures and incorporate business conditions and network models. The MM will consider the existing Pool market as well as new forms of a decentralized market based on peer-to-peer and community systems. The modelling of heat/cold sources and sinks will include flexibility, offering price and business preferences.

Business Module

Business Model Module evaluates various business models for DHC which incorporates excess heat. This is done by calculating matrices like Net Present Value (NPV), Levelized Cost of Heat (LCOH) and Internal Rate of Return (IRR) under different ownership structures and market frameworks.

Introduction to the CF Module

Overview

The purpose of the Core Functionalities (CF) module is to allow full characterization of the EMB3Rs platform objects (sinks and sources) and provide technical information to all the analysis modules, namely the graphical information systems (GIS) module, the techno-economic (TEO) module, the market module (MM), and the business module (BM); to run their simulations.

The CF module divides both sinks and sources submodules into two main sections: characterization and simulation. The characterization focuses on receiving the user inputs and performing the needed computations to characterize the created objects, e.g., when the user creates a sink object, namely a greenhouse, the CF will compute its yearly heating needs according to its location, greenhouse dimensions, and other input parameters. The simulation focuses on performing analysis based on the characterization information, e.g. for a source’s excess heat streams (which were computed in the characterization), the conversion simulation will evaluate the available amount of energy that can be provided to a district heating network (DHN).

Looking into more detail at the main platform objects:

When a user creates a SOURCE, there are two methods to perform its characterization. A simple form if the user desires to characterize directly specific excess heat streams and a more detailed form for users who intend an industry complete characterization. These need to introduce in detail their equipment and processes data. In terms of simulation, whether simplified or detailed characterization, the CF module will convert the source´s excess heat to the DHN, estimating the available conversion heat and the technologies that could be implemented. Only for the users who performed the detailed characterization is performed the internal heat recovery analysis – based on a pinch analysis-, in which the CF suggests possible heat exchanger design combinations.

When a user creates a SINK, it is prompted to the user to characterize its heating/cooling demand. Similar to the source, there is a simplified form for the user to input directly a specific heat/cold stream demand, and a more detailed form for the users who which to characterize buildings – residential, offices, hotels, and greenhouses. According to the user’s buildings specification, the CF will characterize the building by generating the heating/cooling demand. Simulation-wise, the CF will evaluate the technologies that could be implemented on the DHN to meet the heat/cold sink´s needs.

GitHub Repository

The standalone version of the CF module can be found on the GitHub repository here .

Source Submodule

The CF source submodule is divided into: characterization and simulation.

The characterization is responsible for receiving the input data from the user, and, by performing several computations, to assess and estimate the available excess heat streams.

Simple: The user directly introduces the streams, its properties and schedule

Detailed: The user must provide the processes and equipment data so that the CF module can obtain the key streams to be assessed.

The simulation aims to evaluate the recovery of the available excess heat internally, either by integrating it within the source’s processes – pinch analysis - or by implementing an Organic Rankine Cycle (ORC); and externally, by converting it to the DHN.

INTERNAL HEAT RECOVERY: Consists in recovering the heat within the industry by designing a network of heat exchangers – applying the pinch analysis - that promotes the exchange of heat within the processes, thus, minimizing heat/cooling supply by external equipment; by utilizing the excess heat to produce electricity – implementing an Organic Rankine Cycle (ORC).

CONVERT DHN:It aims to design and estimate the costs of converting the available heat of its excess heat streams to the District Heating Network - DHN. For each excess heat stream available the conversion technologies are designed, e.g. a heat exchanger to recover the heat from a hot stream and supply it to the DHN.

Source Characterization

Simple Characterization

src.General.Simple_User.simple_user.simple_user(in_var)[source]

Simple User streams characterization.

A simple user is a user that directly introduces the streams and its properties. This routine receives the user’s streams data from the platform and creates a standard stream data output to be used in other modules.

Parameters

in_var (dict) –

All necessary data to perform the characterization, with the following keys:

platform: dict

Data obtained from the platform

type_of_object: str
’sink’ or ‘source’

streamslist with dict
Streams to be analyzed. Each stream with the following keys:

name: int
stream ID []

supply_temperature: str
stream’s supply/initial temperature [ºC]

target_temperature: str
stream’s target/final temperature [ºC]

fluid: str:
stream’s fluid []

capacity: float
stream’s capacity [kW] - provide capacity or fluid_cp and flowrate

fluid_cp: float
stream’s fluid cp [kJ/kg.K] - provide capacity or fluid_cp and flowrate

flowrate: float
stream’s mass flowrate [kg/h] - provide capacity or fluid_cp and flowrate

daily_periods: float
period of daily periods [h]

shutdown_periods: list
period of days stream is not available [day]

saturday_on: int
if available on saturdays - available (1); not available (0)

sunday_on: int
if available on sundays - available (1); not available (0)

ref_system_fuel_type: str
Fuel type associated

real_hourly_capacity: list, optional
Real hourly data - for each hour of the year

real_daily_capacity: list, optional
Real daily data - for each day of the year

real_monthly_capacity: dict, optional
Real monthly data - for each month of the year

real_yearly_capacity: float, optional
Real yearly data - single value

Returns

output – Streams data

streamslist
List with dicts of all streams with the following keys:
idint
stream ID []

namestr
Stream name []

object_typestr
DEFAULT = “stream” []

object_linked_id
None: DEFAULT=NONE, since no equipment/process is associated

stream_typestr
Stream designation []; inflow, outflow, excess_heat

supply_temperaturefloat
Stream’s supply/initial temperature [ºC]

target_temperaturefloat
Stream’s target/final temperature [ºC]

fluidstr
Stream fluid name

flowratefloat
Stream mass flowrate[kg/h]

schedulelist
Hourly values between 0 and 1, according to the capacity ration on that hour

hourly_generation: list
Stream’s hourly capacity [kWh]

capacityfloat
Stream’s capacity [kW]

monthly_generationlist
Stream’s monthly capacity [kWh]

fuelstr
Associated equipment fuel name []

eff_equipmentfloat
Associated equipment efficiency []

Return type

dict

Detailed Characterization

Process

class src.Source.characterization.Process.process.Process(in_var, kb: KB)[source]

Bases: object

Create Process object and characterize its process components (Inflow/Outflow/Maintenance/Evaporation).

A process is sequencing of actions, in continuous or batch, which includes heating/cooling of streams. Regarding the types of streams: Inflow - going in stream -, Outflow - going out stream - , Maintenance/ Evaporation - energy demand for a specific temperature. The process can be continuous or in batch.

id

Process ID

Type: int

object_type

DEFAULT = “process”

Type: str

streams

Data of the streams associated to this equipment

Type: list

equipment_id

Equipment ID associated

Type: int

operation_temperature

Operation temperature [ºC]

Type: float

schedule_type

Process schedule type; batch (1) or continuous (0)

Type: int

example_of_daily_period

Hours in a daily period [h]

Type: list

eff_equipment

Efficiency of the equipment associated []

Type: float

fuel

Fuel of the equipment associated

Type: str

cycle_time_percentage

Process cycle time percentage []

Type: float

Parameters

in_var (dict) –
Process characterization data, with the following keys:
- id: int
  Process ID []
- equipment_id: int
  Associated equipment ID []
- operation_temperature: float
  process temperature [ºC]
- saturday_on: int
  If it is available on Saturday []; 1 (yes) or 0 (no)
- sunday_on: int
  If it is available on Sunday []; 1 (yes) or 0 (no)
- shutdown_periods: list
  List with lists of periods of days it is not available [day]; e.g. [[130,140],[289,299]]
- daily_periods: list
  List with lists of hourly periods it is available [h]; e.g. [[8,12],[15,19]]
- schedule_type: int
  Process schedule type; batch (1) or continuous (0)
- cycle_time_percentage: float
  Percentage of time needed of a cycle for the Startup/Inflow/Outflow during batch process. Example: For a cycle_time 1h and cycle_time_percentage=0.1; initial 10%/6min for heating the startup fluid and inflow, and last 10%/6min for the outflow discharge.
- inflow_data: list
  Inflow streams dicts, with the following keys:
  
  name: str
  Inflow name
  
  mass: float, optional
  Inflow mass [kg]; Provide flowrate or mass
  
  flowrate: float, optional
  Inflow flowrate [kg/h]; Provide flowrate or mass
  
  fluid_cp: float
  Inflow cp [kJ/kg.K]
  
  supply_temperature: float
  Inflow supply/initial temperature [ºC]
- outflow_datalist
  Outflow data dicts, with the following keys:
  
  fluid_cp: float
  Outflow cp [kJ/kg.K]
  
  target_temperature: float
  Outflow target/final temperature [ºC]
  
  flowrate: float, optional
  Outflow mass flowrate [kg/h]
  
  mass: float, optional
  Outflow mass [kg]
  
  initial_temperature: float, optional
  Outflow initIal temperature [ºC]
- maintenance_datalist
  Maintenance/Eavporation data dicts, with the following keys:
  
  name: str
  Name
  
  maintenance_capacity: float
  Maintenance or evaporation capacity [kW]
kb (dict) – Knowledge Base data

generate_inflow(data)[source]

generate_maintenance_and_evaporation(data)[source]

generate_outflow(outflow_data)[source]

schedule(stream_type)[source]

Generate Equipment

Boiler

class src.Source.characterization.Generate_Equipment.generate_boiler.Boiler(in_var, kb: KB)[source]

Bases: object

Create Boiler Object and characterize its streams

From main characteristics of a boiler, adding to its characterization, it are estimated the inflow/supply/excess heat streams.

id

Equipment ID

Type: int

object_type

DEFAULT = “equipment”

Type: str

streams

Data of the streams associated to this equipment

Type: list

fuel_type

Fuel type

Type: str

supply_capacity

Equipment supply capacity [kW]

Type: float

global_conversion_efficiency

Equipment efficiency []

Type: float

equipment_sub_type

Equipment designation

Type: str

Parameters

in_var (dict) –
Equipment characterization data, with the following keys:

idint
Equipment ID

object_typestr
Equipment type: “process”, “boiler”,”chp”, “burner”, “cooling_equipment”, “stream”

fuel_typestr
Fuel type

boiler_equipment_sub_type: str
Options: “steam_boiler” or “hot_water_boiler”

supply_capacityfloat
Equipment supply capacity [kW]

global_conversion_efficiencyfloat
Conversion efficiency []

processeslist
List of processes objects associated to the equipment

equipment_supply_temperaturefloat
Equipment circuit supply temperature [ºC]

open_closed_loopint
Whether is a opens or closed loop boiler; 1 (yes) or 0 (no)

saturday_onint
If it is available on Saturday []; 1 (yes) or 0 (no)

sunday_onint
If it is available on Sunday []; 1 (yes) or 0 (no)

shutdown_periodslist
List with lists of periods of days it is not available [day]; e.g. [[130,140],[289,299]]

daily_periodslist
List with lists of hourly periods it is available [h]; e.g. [[8,12],[15,19]]

equipment_return_temperaturefloat, optional
Equipment working fluid return temperature [ºC]

boiler_supply_flowratefloat, optional
Equipment working fluid mass flowrate. Only for steam boilers.
kb (dict) – Knowledge Base data

Burner

class src.Source.characterization.Generate_Equipment.generate_burner.Burner(in_var, kb: KB)[source]

Bases: object

Create Burner Object

From main characteristics of a burner, adding to its characterization, it are estimated the inflow/supply/excess heat streams.

id

Equipment ID

Type: int

object_type

DEFAULT = “equipment”

Type: str

streams

Data of the streams associated to this equipment

Type: list

fuel_type

Fuel type

Type: str

supply_capacity

Equipment supply capacity [kW]

Type: float

global_conversion_efficiency

Equipment efficiency []

Type: float

equipment_sub_type

Equipment designation

Type: str

Parameters

in_var (dict) –
Equipment characterization data, with the following keys:

idint
Equipment ID

fuel_typestr
Fuel type

object_typestr
Equipment type: “process”, “boiler”,”chp”, “burner”, “cooling_equipment”, “stream”

global_conversion_efficiencyfloat
Conversion efficiency []

supply_capacityfloat
Equipment supply capacity [kW]

processeslist
List of processes objects associated to the equipment

saturday_onint
If it is available on Saturday []; 1 (yes) or 0 (no)

sunday_onint
If it is available on Sunday []; 1 (yes) or 0 (no)

shutdown_periodslist
List with lists of periods of days it is not available [day]; e.g. [[130,140],[289,299]]

daily_periodslist
List with lists of hourly periods it is available [h]; e.g. [[8,12],[15,19]]

burner_equipment_sub_typestr
Options: “indirect_burner” or “direct_burner”

burner_excess_heat_supply_temperaturefloat
Burner recoverable excess heat temperature [ºC]

burner_excess_heat_flowratefloat
Burner recoverable excess heat mass flowrate [kg/h]
kb (dict) – Knowledge Base data

CHP

class src.Source.characterization.Generate_Equipment.generate_chp.Chp(in_var, kb: KB)[source]

Bases: object

Create CHP Object

From main characteristics of a Combined Heat and Power unit, adding to its characterization, it are estimated the inflow/supply/excess heat streams.

id

Equipment ID

Type: int

object_type

DEFAULT = “equipment”

Type: str

streams

Data of the streams associated to this equipment

Type: list

fuel_type

Fuel type

Type: str

supply_capacity

Equipment supply capacity [kW]

Type: float

global_conversion_efficiency

Equipment efficiency []

Type: float

equipment_sub_type

Equipment designation

Type: str

thermal_conversion_efficiency

Thermal conversion efficiency []

Type: float

electrical_conversion_efficiency

Electrical conversion efficiency []

Type: float

Parameters

in_var (dict) –
Equipment characterization data, with the following keys:
- idint
  Equipment ID
- fuel_typestr
  Fuel type
object_typestr
Equipment type: “process”, “boiler”,”chp”, “burner”, “cooling_equipment”, “stream”
- equipment_sub_type: str
  Options: “steam_boiler” or “hot_water_boiler”
- supply_capacityfloat, optional
  Equipment supply capacity [kW]; Provide thermal or electrical supply capacity
- electrical_generationfloat, optional
  CHP electrical generation capacity [kWe]; Provide thermal or electrical supply capacity
- thermal_conversion_efficiencyfloat, optional
  CHP thermal efficiency []; Provide thermal or electrical conversion efficiency
- electrical_conversion_efficiencyfloat, optional
  CHP electrical efficiency []; Provide thermal or electrical conversion efficiency
- global_conversion_efficiencyfloat
  Conversion efficiency []
- processeslist, optional
  List of processes objects associated to the equipment;
- equipment_supply_temperaturefloat
  Equipment circuit supply temperature [ºC]
- open_closed_loopint
  Whether is a opens or closed loop boiler; 1 (yes) or 0 (no)
- saturday_onint
  If it is available on Saturday []; 1 (yes) or 0 (no)
- sunday_onint
  If it is available on Sunday []; 1 (yes) or 0 (no)
- shutdown_periodslist
  List with lists of periods of days it is not available [day]; e.g. [[130,140],[289,299]]
- daily_periodslist
  List with lists of hourly periods it is available [h]; e.g. [[8,12],[15,19]]
- equipment_return_temperaturefloat, optional
  Equipment working fluid return temperature [ºC]
kb (dict) – Knowledge Base data

Cooling Equipment

class src.Source.characterization.Generate_Equipment.generate_cooling_equipment.Cooling_Equipment(in_var, kb: KB)[source]

Bases: object

Create Cooling Equipment Object and characterize its streams

From main characteristics of the cooling equipment, adding to its characterization, it is estimated the excess heat stream.

id

Equipment ID

Type: int

object_type

DEFAULT = “equipment”

Type: str

streams

Data of the streams associated to this equipment

Type: list

fuel_type

Fuel type

Type: str

supply_capacity

Equipment supply capacity [kW]

Type: float

global_conversion_efficiency

Equipment efficiency []

Type: float

equipment_sub_type

Equipment designation

Type: str

Parameters

in_var (dict) –
Equipment characterization data, with the following keys:

idint
Equipment ID

fuel_typestr
Fuel type

object_typestr
Equipment type: “process”, “boiler”,”chp”, “burner”, “cooling_equipment”, “stream”

global_conversion_efficiencyfloat
Chiller COP []

supply_capacityfloat
Equipment supply capacity [kW]

cooling_equipment_sub_typestr
Type of cooling equipment; ‘co2_chiller’, ‘cooling_tower’, ‘compression_chiller’

processeslist
List of processes objects associated to the equipment

saturday_onint
If it is available on Saturday []; 1 (yes) or 0 (no)

sunday_onint
If it is available on Sunday []; 1 (yes) or 0 (no)

shutdown_periodslist
List with lists of periods of days it is not available [day]; e.g. [[130,140],[289,299]]

daily_periodslist
List with lists of hourly periods it is available [h]; e.g. [[8,12],[15,19]]
kb (dict) – Knowledge Base data

Source Simulation

Convert Sources

src.Source.simulation.Convert.convert_sources.convert_sources(in_var, kb)[source]

Design of technologies to connect sources to the DHN.

For each source are designed the conversion technologies needed. When performing the conversion, three design options may occur:

If the stream supply temperature > DHN supply temperature -> HX designed

If the stream supply temperature > ORC evaporator -> ORC cascaded designed

If the stream supply temperature < DHN supply temperature -> HX and heating technologies are designed to fulfill DHN temperature

Parameters

in_var (dict) –
platform and CF module data, with the following keys:
- platform: dict
  Platform data, with the following keys:
  
  existing_grid_data: list with dict [OPTIONAL]
  Existent grid connection point data, with the following keys:
  
  id: int
  Existent source or grid connection point ID
  
  location: list
  Location [º]; [latitude,longitude]
  
  levelized_co2_emissions: float
  Grid levelized CO2 emissions [CO2/kWh]
  
  levelized_om_var: float
  Grid levelized OM var [€/kWh]
  
  levelized_om_fix: float
  Grid levelized OM fix [€/kWh]
  
  group_of_sources: list with dict
  Sources to be analyzed. Each source with the following keys:
  
  id: int:
  Source ID
  
  location: list
  Location [º]; [latitude,longitude]
  
  fuels_data: dict, optional
  Fuels price and CO2 emission, with the following keys:
  
  natural_gas: dict
  with the following keys:
  
  co2_emissions: float:
  Fuel CO2 emission [kg CO2/kWh]
  
  price: float:
  Fuel price [€/kWh]
  
  fuel_oildict
  Similar to “natural_gas”
  
  electricitydict
  Similar to “natural_gas”
  
  biomassdict
  Similar to “natural_gas”
  
  streams: list with dict
  Source’s streams to be analyzed. Each stream with the following keys:
  
  stream_id: int
  Stream ID []
  
  object_type: str
  DEFAULT=stream []
  
  stream_type: str
  Stream designation []; inflow, outflow, excess_heat
  
  fluid: str
  Stream’s fluid []
  
  capacity: float
  Stream’s capacity [kW]
  
  supply_temperature: float
  Stream’s supply/initial temperature [ºC]
  
  target_temperature: float
  Stream’s target/final temperature [ºC]
  
  hourly_generation: list
  Stream’s hourly capacity [kWh]
  
  cf_module: dict
  CF module data, with the following keys:
  
  sink_group_grid_supply_temperature: float
  Grid supply temperature (user input or defined by the “convert_sinks”) [ºC]
  
  sink_group_grid_return_temperature: float
  Grid return temperature (user input or defined by the “convert_sinks”) [ºC]
kb (dict) – Knowledge Base data

Returns

all_info –

Sources conversion data, with the following keys:

all_sources_info: list
Sources dicts to be analyzed. Each source with the following keys:

source_id: int:
Source ID

location: list:
Location [º]; [latitude,longitude]

source_grid_supply_temperature: float
Source-grid supply temperature [ºC]

source_grid_return_temperature: float
Source-grid return temperature [ºC]

streams_convertedlist
Streams conversion data dicts, with the following keys:

stream_id: int
Stream ID

teo_stream_id: str
TEO specific data; stream ID with source ID []

input_fuel: str
TEO specific data; TEO input fuel name []

output_fuel: str
TEO specific data; TEO output fuel name []

output: int
TEO specific data; DEFAULT=1 []

gis_capacity: float
GIS specific data; stream converted/provided capacity to the grid

hourly_stream_capacity: list
Hourly stream capacity [kWh]

teo_capacity_factor: list
TEO specific data

max_stream_capacity: float
Max stream capacity [kW]

conversion_technologies: list
Conversion solution data dicts (technologies implemented), with the following keys:

teo_equipment_name: str
TEO specific data; TEO equipment name []

output: int
TEO specific data; DEFAULT=1 []

input_fuel: str
TEO specific data; TEO input fuel name []

output_fuel: str
TEO specific data; TEO output fuel name []

equipment: list
Conversion solution equipment names []

max_capacity: float
Stream capacity maximum capacity convertible [kW]

turnkey_a: float
Conversion solution turnkey a (ax+b) [€/kW]

turnkey_b: float
Conversion solution turnkey b (ax+b) [€]

conversion_efficiency: float
Conversion solution efficiency stream-to-grid []

om_fix: float
Conversion solution OM fix [€/year.kW]

om_var: float
Conversion solution OM var [€/kWh]

emissions: float
Conversion solution CO2 emissions [kg.CO2/kWh]

technologies: list
Each technologies info in detail dicts (check each technology routine for more details)

ex_grid: dict, list
TEO specific data; existent grid data

teo_equipment_name: str
DEFAULT=”ex_grid”

output: int
DEFAULT=1

input_fuel: None
DEFAULT=None

output_fuel: str
DEFAULT=”dhnwatersupply”

equipment: list
DEFAULT=[]

max_capacity: float
DEFAULT=10**8

turnkey_a: float
DEFAULT=0

turnkey_b: float
DEFAULT=0

conversion_efficiency: float
DEFAULT=1

om_fix: int
Levelized OM Var [€/year]

om_var: int
Levelized OM Var [€/kWh]

emissions: float
Levelized CO2 emissions [kgCO2/kWh]

technologies: list
DEFAULT=[]

teo_string: str
TEO specific data. DEFAULT=”dhn”

input_fuel: str
TEO specific data. DEFAULT=”dhnwatersupply”

output_fuel: str
TEO specific data. DEFAULT=”dhnwaterdem”

output: int
TEO specific data. DEFAULT=1

input: int
TEO specific data. DEFAULT=1

n_supply_list: list
GIS specific data. Sources location and capacity provided to the grid

teo_capacity_factor_group: int
TEO specific data

teo_dhn: dict
TEO specific data. Parameters TEO

Return type

dict

Internal Heat Recovery

Organic Rankine Cycle (ORC)

src.Source.simulation.Heat_Recovery.ORC.convert_orc.convert_orc(in_var, kb: KB)[source]

Main routine for designing ORCs for the streams given

Organic Rankine Cycles are designed for the excess heat streams given, so that the heat to power production can be analysed.

Parameters

in_var (dict) –
All necessary data to perform the ORD design, with the following key:
- platform: dict
  platform data, with the following keys:
  
  location: list:
  Location [º]; [latitude,longitude]
  
  fuels_data: dict, optional
  Fuels price and CO2 emission, with the following keys:
  
  natural_gas: dict
  with the following keys:
  
  co2_emissions: float:
  Fuel CO2 emission [kg CO2/kWh]
  
  price: float:
  Fuel price [€/kWh]
  
  fuel_oildict
  Similar to “natural_gas”
  
  electricitydict
  Similar to “natural_gas”
  
  biomassdict
  Similar to “natural_gas”
  
  streams: list
  each stream data, with the following keys:
  
  id: int
  stream ID []
  
  name: str
  stream name []
  
  object_type: str
  DEFAULT=stream []
  
  stream_type: str
  stream designation []; e.g. inflow, outflow, excess_heat
  
  supply_temperature: float
  stream’s supply/initial temperature [ºC]
  
  target_temperature: float
  stream’s target/final temperature [ºC]
  
  fluid: str
  stream’s fluid []
  
  flowrate: float
  stream’s mass flowrate [kg/h]
  
  schedule: list
  stream’s hourly schedule
  
  hourly_generation: list
  stream’s hourly capacity
  
  capacity: float
  stream’s capacity [kW]
  
  get_best_number: int, optional
  number of best conversion cases; DEFAULT=3
  
  orc_years_working: int, optional
  ORC working years [years]; DEFAULT=25
  
  orc_T_evap: float, optional
  ORC evaporator temperature [ºC]; DEFAULT=110
  
  orc_T_cond: float, optional
  ORC evaporator temperature [ºC]; DEFAULT=35
kb (dict) – Knowledge Base data

Returns

output –

Output data, with the following keys:

best_optionslist
each designed solution data, with the following keys:

ID: int
ORC design ID []

streams_id: list
streams ID considered for the solution []

electrical_generation_nominal: float
ORC nominal electrical generation [kW]

electrical_generation_yearly: float
ORC yearly electrical generation [kWh]

excess_heat_supply_capacity: float
streams thermal capacity available [kW]

conversion_efficiency: float
ORC heat to electricity conversion efficiency []

turnkey: float
ORC investment cost [€]

om_fix: float
ORC yearly OM fix costs [€/year]

om_var: float
ORC yearly OM var costs [€/kWh]

electrical_generation_yearly_turnkey: float
ORC yearly electrical generation over turnkey [kWh/€]

co2_savings: float
ORC yearly CO2 savings (all electricity is considered to be consumed) [kg CO2/kWh]

money_savings: float
ORC yearly monetary savings (all electricity is considered to be consumed [€/kWh]

discount_rate: float
discount rate []

lifetime: float
ORC working years [years]

reportstr
HTML report

Return type

dict

Pinch Analysis

src.Source.simulation.Heat_Recovery.Pinch.convert_pinch.convert_pinch(in_var, kb: KB)[source]

Main function of Pinch Analysis

Includes data pretreatment, pinch analysis, and economic/CO2 analysis of the options designed. Return the best three solutions for: minimum CO2 emissions ,maximize energy recovery, and energy recovery specific cost.

Parameters

in_var –

Data for pinch analysis, with the following key:

platformdict
Platform Data

streams_to_analyselist
List with streams ID to analyse

pinch_delta_T_min: float
Minimum delta temperature for pinch analysis [ºC]

all_input_objectslist

List with:

equipments (check Source/characterization/Generate_Equipment)

processes (check Source/characterization/Process/process)

isolated streams (check General/Simple_User/isolated_stream)

kbdict: Knowledge Base

Returns

pinch_output –

Pinch analysis, with the following keys:

best_optionsdict
Three categories, with the respective following keys:

co2_optimizationlist
List with dicts, with best design options that minimize CO2 emissions. Each solution with the following keys:

IDint
Designed solution ID

streamslist
Streams ID in pinch design

streams_infolist
array with dicts

capexfloat
Solution capex [€]

om_fixfloat
Yearly OM fix costs [€/year]

hot_utilityfloat
Power of the hot utility needed, so that the cold streams reach their target_temperature [kW]

cold_utilityfloat
Power of the cold utility needed, so that the hot streams reach their target_temperature [kW]

lifetimefloat
Considered lifetime [year]

co2_savingsfloat
Annualized co2 savings by implementing the pinch design [kg CO2/kWh]

money_savingsfloat
Annualized energy savings by implementing the pinch design [€/kWh]

energy_dispatchfloat
Yearly energy recovered by implementing the pinch design [kWh/year]

discount_ratefloat
Financial parameter for the BM []

pinch_temperaturefloat
Design pinch temperature [ºC]

theo_minimum_hot_utilityfloat
Theoretical power of the hot utility needed, so that the cold streams reach their target temperature [kW]

theo_minimum_cold_utilityfloat
Theoretical power of the cold utility needed, so that the hot streams reach their target temperature [kW]

pinch_hx_datalist
Each heat exchanger technical/economical data,with the following keys:

HX_Powerfloat
Heat exchanger power [kW]

HX_Hot_Streamint
Hot stream ID

HX_Cold_Streamint
Cold stream ID

HX_Original_Hot_Streamint
Hot stream ID (there might be a split, meaning that HX_Original_Hot_Stream != HX_Hot_Stream)

HX_Original_Cold_Streamint
Cold stream ID (there might be a split, meaning that HX_Original_Cold_Stream != HX_Cold_Stream)

HX_Typestr
Heat exchanger type

HX_Turnkey_Costfloat
Heat exchanger capex [€]

HX_OM_Fix_Costfloat
Heat exchanger OM Fix [€/year]

HX_Hot_Stream_T_Hotfloat
Hot stream hot temperature[ºC]

HX_Hot_Stream_T_Coldfloat
Hot stream cold temperature[ºC]

HX_Cold_Stream_T_Hotfloat
Cold stream hot temperature[ºC]

HX_Cold_Stream_T_Coldfloat
Cold stream cold temperature[ºC]

Storagefloat
Storage volume [m3]

Storage_Satisfiesfloat
Percentage of capacity in mismatch hours that storaeg satisfies [%]

Storage_Turnkey_Costfloat
Storage capex [€]

Total_Turnkey_Costfloat
Heat exchanger + storage copex [€]

Recovered_Energyfloat
Amount of energy recovered [kWh]

Return type

dict

energy_recovered_optimizationlist
List with best design options of the respective category -> similar to “co2_optimization”

energy_investment_optimizationlist
List with best design options of the respective category -> similar to “co2_optimization”

reportstr: HTML Report

Pinch Analysis - Isolated Streams (QUICK INPUTS)

src.Source.simulation.Heat_Recovery.convert_pinch_isolated_streams.convert_pinch_isolated_streams(in_var, kb: KB)[source]

Perform Pinch Analysis to isolated streams (QUICK INPUTS).

This routine was developed to easily perform the pinch analysis to isolated streams - streams which are not from the detailed characterization - associated with equipment or processes. The user just needs to provide the properties and schedule of the streams to run this routine. This routine use the main routine of the Pinch Analysis. Return best solutions in minimum CO2 emissions, maximize energy recovery, and energy recovery specific cost, as well as a HTML report.

Parameters

in_var (dict) –
Data to perform pinch analysis
platformdict
Platform data

streamsdict
Streams data

pinch_delta_T_minfloat
Pinch delta_T

fuels_data: dict
Fuels price and CO2 emission, with the following keys:

natural_gas: dict
Natural gas data

co2_emissions: float:
Fuel CO2 emission [kg CO2/kWh]

price: float:
Fuel price [€/kWh]

fuel_oil
Same keys as “natural_gas”

electricity
Same keys as “natural_gas”

biomass
Same keys as “natural_gas”

streams_to_analyselist
Stream ID to analyse
kb (dict) – Knowledge Base

Returns

pinch_output –

Pinch analysis, with the following keys:

best_optionsdict
with solutions data for:

co2_optimizationlist
List with best design options of the respective category

energy_recovered_optimizationlist
List with best design options of the respective category

energy_investment_optimizationlist
List with best design options of the respective category

reportstr
HTML Report

Return type

dict

Sink Submodule

The CF sink submodule is divided into: characterization and simulation.

The characterization is responsible for receiving the input data from the user and estimate the sink heating and cooling needs. The characterization is divided into simple and detailed. For the simple characterization the industry user needs to characterize the hot water, steam and/or cold water streams. A user that performs the detailed characterization can analyze a building heat and cooling needs by introducing the building characteristics.

Simple: The user directly introduces the streams, its properties and schedule

Building/Greenhouse: The building and greenhouse routines are for users that intend to simulate a climate dependent heating/cooling demand. The functions will generate a quick estimate on the hourly heating/cooling (if existent) demand profile for a full year based on climate data and buildings’ temperature requirements

The simulation aims to evaluate and design the technologies needed to convert the DHN heat into the sinks needs

CONVERT DHN: It aims to design and estimate the costs of converting the District Heating Network heat to the demand of the sink’s streams.

Sink Characterization

Building

src.Sink.characterization.building.building(in_var, kb: KB)[source]

Building characterization

Simulates heat (space heating and hot water) and cooling (space cooling) consumptions over the year, according to building specifications and climate weather data. Characterizes heating/cooling streams of a building.

Parameters

in_var (dict) –
All necessary data to perform the building characterization data, with the following key:
platform: dict
Data obtained from the platform, with the following keys:
locationlist
location [º]; [latitude,longitude]

number_floor: int
number of floors

width_floor: float
floor width [m]

length_floor: float
floor length [m]

height_floor: float
floor height [m]

ratio_wall_N: float
ratio of the North wall area in total north facade area (wall + window) []

ratio_wall_S: float
ratio of the South wall area in total north facade area (wall + window) []

ratio_wall_E: float
ratio of the East wall area in total north facade area (wall + window) []

ratio_wall_W: float
ratio of the West wall area in total north facade area (wall + window) []

daily_periods: float
period of daily periods [h]

shutdown_periods: list
period of days stream is not available [day]

saturday_on: int
if available on saturdays - available (1); not available (0)

sunday_on: int
if available on sundays - available (1); not available (0)

building_orientation: str
building’s main facade orientation; “N”,”S”,”E” or “W”

space_heating_type: int

Space heating type;
1 = Conventional; heaters working fluid supply temperature of 75ºC, heaters working fluid return temperature of 45ºC) 2 = Low temperature; heaters working fluid supply temperature of 50ºC, heaters working fluid return temperature of 30ºC) 3 = Specify Temperatures - Advanced Properties; of supply_temperature_heat and target_temperature_heat

T_cool_on: float
Cooling setpoint temperature [ºC]

T_heat_on: float
Heating setpoint temperature [ºC]

T_off_min: float
Heating setback setpoint temperature [ºC]

T_off_max: float
Cooling setback setpoint temperature [ºC]

ref_system_fuel_type_heating: str
Fuel type associated; e.g. “natural_gas”,”electricity”,”biomass”,”fuel_oil”,”none”

ref_system_eff_equipment_heating: float, optional
Efficiency of the heating equipment

ref_system_fuel_type_cooling: str
Fuel type associated

ref_system_eff_equipment_cooling: float, optional
COP of the cooling equipment

real_heating_monthly_capacity: dict, optional
Real monthly data - for each month of the year

real_heating_yearly_capacity: float, optional
Real yearly data - single value

real_cooling_monthly_capacity: dict, optional
Real monthly data - for each month of the year

real_cooling_yearly_capacity: float, optional
Real yearly data - single value

number_person_per_floor: int, optional
Persons per floor

supply_temperature_heat: float, optional
Heating System ReturnTemperature [ºC]

target_temperature_heat: float, optional
Heating System Supply Temperature [ºC]

supply_temperature_cool: float, optional
Cooling System Return Temperature [ºC]

target_temperature_cool: float, optional
Cooling System Supply Temperature [ºC]

tau_glass: float, optional
glass windows transmissivity []

u_wall: float, optional
walls’ U value [W/m2.K]

u_roof: float, optional
roof U value [W/m2.K]

u_glass: float, optional
glass windows U value [W/m2.K]

u_floor: float, optional
floor U value [W/m2.K]

alpha_wall: float, optional
walls’ radiation absorption coefficient []

alpha_floor: float, optional
floor’s radiation absorption coefficient []

alpha_glass: float, optional
windows’ radiation absorption coefficient []

cp_floor: float, optional
floor specific heat capacitance [J/kg.K]

cp_roof: float, optional
roof specific heat capacitance [J/kg.K]

cp_wall: float, optional
wall specific heat capacitance [J/kg.K]

air_change_hour: float, optional
air changes per hour due to infiltrations [1/h]

renewal_air_per_person: float, optional
fresh air changer per person [m3/s per person]

vol_dhw_set: float, optional
Volume of daily water consumption [m3]

Q_gain_per_floor: float, optional
Internal Gains [W/m2]

emissivity_wall: float, optional
Walls’s emissivity

emissivity_glass: float, optional
Glass Window’s emissivity
kb (dict) – Knowledge Base data

Returns

output –

Streams data

streamslist
List with dicts of all streams with the following keys:

idint
stream ID []

namestr
Stream name []

object_typestr
DEFAULT = “stream” []

object_linked_id
None: DEFAULT=NONE, since no equipment/process is associated

stream_typestr
Stream designation []; inflow, outflow, excess_heat

supply_temperaturefloat
Stream’s supply/initial temperature [ºC]

target_temperaturefloat
Stream’s target/final temperature [ºC]

fluidstr
Stream fluid name

flowratefloat
Stream mass flowrate [kg/h]

schedulelist
Hourly values between 0 and 1, according to the capacity ration on that hour

hourly_generation: list
Stream’s hourly capacity [kWh]

capacityfloat
Stream’s capacity [kW]

monthly_generationlist
Stream’s monthly capacity [kWh]

fuelstr
Associated equipment fuel name []

eff_equipmentfloat
Associated equipment efficiency []

Return type

dict

Greenhouse

src.Sink.characterization.greenhouse.greenhouse(in_var)[source]

Greenhouse characterization

Simulates the heat (space heating) needs over the year according to the greenhouse specifications and climate weather data of the location

Parameters

in_var (dict) –
All necessary data to perform the building characterization data, with the following key:
platform: dict
Data obtained from the platform, with the following keys:
locationlist
Location [º]; [latitude,longitude]

width: float:
Width [m]

length: float:
Length [m]

height: float:
Height [m]

greenhouse_orientation: str:
Greenhouse’s main facade orientation; “N”,”S”,”E” or “W”

daily_periods: float:
Period of daily periods [h]

shutdown_periods: list:
Period of days stream is not available [day]

greenhouse_efficiency:

Greenhouse air infiltration tightness:
1 = tight cover with low infiltrations 2 = medium sealing 3 = leaky cover

T_heat_on: float:
Heating setpoint temperature [ºC]

thermal_blanket:
If greenhouse has a thermal blanket/curtain being used at night; 1=yes,0=no

artificial_lights_system:
lighting hours in greenhouse; 1=yes,0=no

ref_system_fuel_type: str
Fuel type associated; e.g. “natural_gas”,”electricity”,”biomass”,”fuel_oil”,”none”

ref_system_eff_equipment: float, optional
COP of the cooling equipment;

real_monthly_capacity: dict, optional
Real monthly data - for each month of the year

real_yearly_capacity: float, optional
Real yearly data - single value

hours_lights_needed:
hours of light the plant needs (accounting with daily solar hours) [h]

supply_temperature_heat: float, optional
Heating System ReturnTemperature [ºC]; DEFAULT=30

target_temperature_heat: float, optional
Heating System Supply Temperature [ºC]; DEFAULT=50

leaf_area_index, optional
Ratio of leaf area over ground area []; DEFAULT=1

rh_air, optional
Relative humidity [%]; DEFAULT=80

u_cover, optional
Cover thermal conductivity [W/m2.K]; DEFAULT=6

indoor_air_speed, optional
Indoor air velocity [m/s]; DEFAULT=0.1

leaf_length, optional
Characteristic length of a plant leaf [m]; DEFAULT=0.027

tau_cover_long_wave_radiation, optional
Cover transmissivity coefficient to long-wave radiation; DEFAULT=0.3

emissivity_cover_long_wave_radiation, optional
Cover emissivity coefficient to long-wave radiation; DEFAULT=0.2

tau_cover_solar_radiation, optional
Cover’s transmissivity coefficient to solar radiation []; DEFAULT=0.9

power_lights, optional
Light power per square meter [W/m2]; DEFAULT=20
kb (dict) – Knowledge base data

Returns

output (dict)
Streams data
- streams (list) –

List with dicts of all streams with the following keys:
- idint
  stream ID []
- namestr
  Stream name []
- object_typestr
  DEFAULT = “stream” []
- object_linked_id
  None: DEFAULT=NONE, since no equipment/process is associated
- stream_typestr
  Stream designation []; inflow, outflow, excess_heat
- supply_temperaturefloat
  Stream’s supply/initial temperature [ºC]
- target_temperaturefloat
  Stream’s target/final temperature [ºC]
- fluidstr
  Stream fluid name
- flowratefloat
  Stream mass flowrate[kg/h]
- schedulelist
  Hourly values between 0 and 1, according to the capacity ration on that hour
- hourly_generation: list
  Stream’s hourly capacity [kWh]
- capacityfloat
  Stream’s capacity [kW]
- monthly_generationlist
  Stream’s monthly capacity [kWh]
- fuelstr
  Associated equipment fuel name []
- eff_equipmentfloat
  Associated equipment efficiency []

Sink Simulation

Convert Sinks

src.Sink.simulation.convert_sinks.convert_sinks(in_var, kb)[source]

Design of technologies to connect DHN to the sinks.

For each sink are designed the conversion technologies needed. When performing the conversion, three design options may occur: Sink that requires HEATING:

The grid temperature meets the sink target temperature requirements, thus only a grid-sink HX and correspondent circulation pumping is needed

The grid temperature does not meet the sink target temperature requirements, thus adding to the grid-sink HX and correspondent circulation pumping, it is also necessary to add a technology to raise the temperature (chp,solar thermal, heat pump, boiler)

Sink that requires COOLING:

It is always necessary to add a cooling technology (thermal_chiller), since we are only designing DHNs

Possible conversions: HX, HX + heating/cooling technology + HX.

Moreover, for the group of sinks capacity, heating grid specific technologies (also known as backup) are designed.

Parameters

in_var (All necessary data to perform the grid to sinks conversion with the following key:) –
platform: dict
Data obtained from the platform
grid_supply_temperaturefloat, optional
Grid supply temperature provided by the user [ºC]

grid_return_temperaturefloat, optional
Grid return temperature provided by the user [ºC]

group_of_sinkslist with dict
List with all sinks to be analyzed; each with the following keys:

idint
Sink ID []

locationlist
[latitude, longitude] [º]

fuels_data: dict, optional
Fuels price and CO2 emission, with the following keys:

natural_gas: dict
Natural gas data

co2_emissions: float:
Fuel CO2 emission [kg CO2/kWh

price: float:
Fuel price [€/kWh

fuel_oil
Same keys as “natural_gas”

electricity
Same keys as “natural_gas”

biomass
Same keys as “natural_gas”

streamslist with dict
Streams to be analyzed. Each stream with the following keys:

idint
Stream ID []

namestr
Stream name []

object_typestr
DEFAULT = “stream” []

object_linked_id
None: DEFAULT=NONE, since no equipment/process is associated

stream_typestr
Stream designation []; inflow, outflow, excess_heat

supply_temperaturefloat
Stream’s supply/initial temperature [ºC]

target_temperaturefloat
Stream’s target/final temperature [ºC]

fluidstr
Stream fluid name

flowratefloat
Stream mass flowrate[kg/h]

schedulelist
Hourly values between 0 and 1, according to the capacity ration on that hour

hourly_generation: list
Stream’s hourly capacity [kWh]

capacityfloat
Stream’s capacity [kW]

fuelstr
Associated equipment fuel name []

eff_equipmentfloat
Associated equipment efficiency []
kb (dict) – Knowledge Base data

Returns

all_info –

All conversion data

all_sinks_infolist
Each sink conversion data

-sink_group_grid_supply_temperaturefloat
Grid supply temperature [ºC]

sink_group_grid_return_temperaturefloat
Grid return temperature [ºC]

grid_specificlist
List with Grid Specific technologies, each technology with the following keys:

teo_equipment_namestr
Specific nomenclature for the TEO

outputstr
Specific nomenclature for the TEO

input_fuelstr
Specific nomenclature for the TEO

output_fuelstr
Specific nomenclature for the TEO

equipmentlist
All conversion equipments; list with technologies names; e.g. [‘hx_plate’, ‘heat_pump’,’hx_plate’]

max_capacityfloat
Stream power (sources- excess heat; sinks - grid heat) [kW]

turnkey_afloat
Aggregated turnkey a [€/kW]

turnkey_bfloat
Aggregated turnkey b [€]

conversion_efficiency :
Aggregated conversion_efficiency []

electrical_conversion_efficiencyfloat
ONLY FOR ORC - electrical conversion efficiency []

om_fixfloat
Aggregated om_fix [€/year.kW]

om_varfloat
Aggregated om_var [€/kWh]

emissionsfloat
Aggregated emissions [kg.CO2/kWh]

technologieslist with dicts
Each equipment info in detail (check General/Convert_Equipments/Convert_Options)

sinkslist with dict
List with each sink data, with the following keys:

sink_idstr
Sink ID

locationlist
[latitude, longitude] [º]

streamslist with dict
Each stream of the sink, with the following keys:

stream_idstr
Stream ID

demand_fuelstr
TEO specific data

gis_capacityfloat
Sink nominal capacity [kWh]

hourly_stream_capacitylist
Stream hourly capacity [kWh]

teo_demand_factorlist
Stream’s hourly capacity divided by yearly capacity [kWh]

teo_yearly_demandfloat
Stream yearly demand [kWh]

conversion_technologieslist
List with multiple dictionaries with the solution of technologies possible to implement; same keys as the “grid_specific” technologies

n_demand_listlist with dicts
Sinks data for GIS, with the following keys:

idstr
Object ID

coordslist
[latitude, longitude] [º]

capfloat
Object nominal capacity [kW]

n_grid_specificlist with dicts
Grid specific data for GIS, with the following keys:

idint
Object ID

coordslist
Same keys as “n_demand_list”

capfloat
Same keys as “n_demand_list”

n_thermal_storagelist with dicts
Thermal storage data for GIS; Same keys as “n_grid_specific”

teo_demand_factor_grouplist
Every hour of the year with dicts in each hour with TEO Sink ID and corresponding hourly_capacity/yearly_capacity; e.g. [{“sink1”:0.5,”sink2”:0,…},{{“sink1”:0.6,”sink2”:0,…},…]

Return type

dict

User Guide - STANDALONE

The CF can also be used as STANDALONE. It were developed scripts with the main features of the CF that read data from excel files and provide routines the results to the user. You can check below to understand how it works.

from main_cf_standalone import CFModule

#############################################################################################
#############################################################################################
# USER INTERACTION -> Create a folder inside "test" folder with your input data

# Initialize
cf = CFModule()

# Get files path
dhn_file_path = 'test_files/dhn_data.xlsx'
design_orc_file_path = 'test_files/orc_data.xlsx'
pinch_analysis_file_path = 'test_files/pinch_data.xlsx'

# Run
convert_sinks_results, convert_sources_results = cf.dhn_simulation(dhn_file_path,
                                                                   grid_supply_temperature=80,
                                                                   grid_return_temperature=40)
orc_data, orc_report = cf.design_orc(design_orc_file_path)
pinch_data, pinch_report = cf.pinch_analysis(pinch_analysis_file_path)

For each one of the simulations you can find an example for the INPUTS data and RESULTS in the “standalone” folder. Check here, for a more detailed code snippet.

Below, you can find a step-by-step for each simulation.

District Heating Network

INPUTS -> user provides excel file

Sources characterization - Simple Characterization
Sinks characterization - Simple Characterization, Building and Greenhouse
Fuels data

RUN CODE

Sinks Simulation - Convert Sinks
Sources Simulation - Convert Sources

OUTPUT -> user can fetch the data

User can get the outputs of the simulations (Convert Sources and Convert Sinks)

Pinch Analysis - Isolated Streams (QUICK INPUTS)

INPUTS -> user provides excel file

Source and streams characterization
Pinch analysis data
Fuels data

RUN CODE

Source simulation - Pinch Analysis - QUICK INPUTS -> get best pinch designs

OUTPUT -> user can fetch the data

User can get the outputs of the simulation and the HTML report

Design ORC

INPUTS -> user provides excel file

Source and streams characterization
ORC design data
Fuels data

RUN CODE

Source simulation - Organic Rankine Cycle (ORC) -> get best ORC designs

OUTPUT -> user can fetch the data

User can get the outputs of the simulation and the HTML report