Conversion

• File name: conversion.py

• Last edited: 2020-06-14

• Created by: Stefan Bruche (TU Berlin)

A conversion component takes commodities at the inlet and provides other commodities at the outlet after an internal conversion.

class aristopy.conversion.Conversion(ensys, name, inlet, outlet, basic_variable, has_existence_binary_var=False, has_operation_binary_var=False, time_series_data=None, scalar_params=None, additional_vars=None, user_expressions=None, capacity=None, capacity_min=None, capacity_max=None, capacity_per_module=None, maximal_module_number=None, capex_per_capacity=0, capex_if_exist=0, opex_per_capacity=0, opex_if_exist=0, opex_operation=0, start_up_cost=0, min_load_rel=None, instances_in_group=1, group_has_existence_order=True, group_has_operation_order=True, use_inter_period_formulation=True)

Initialize an instance of the Conversion class.

Note

See the documentation of the Component class for a description of all keyword arguments and inherited methods.

Parameters

• start_up_cost (float or int (>=0)) – Costs incurred when the state of the binary operation variable (BI_OP) changes from 0 (OFF) to 1 (ON) from one time step to the next one [€/Start]; (requires keyword argument ‘has_operation_binary_var’ set to True).
  Default: 0

• min_load_rel (float or int (0<=value<=1), or None) – Value for the relative minimal part-load of a conversion unit (e.g., 0.5 represents 50% minimal load). Minimal part-loads require the availability of a binary operation variable (‘has_operation_binary_var’=True) and currently, fixed capacities need to be specified (‘capacity_min’=’capacity_max’).
  Default: None

• instances_in_group (int (>=0)) – States the number of similar component instances that are simultaneously created and arranged in a group. That means, the user has the possibility to instantiate multiple component instances (only for Conversion!) with identical specifications. These components work independently, but may have an order for their binary existence and/or operation variables (see: ‘group_has_existence_order’, ‘group_has_operation_order’). If a number larger than 1 is provided, the names of the components are extended with integers starting from 1 (e.g., ‘conversion_1’, …).
  Default: 1

• group_has_existence_order (bool) – If multiple similar instances are created and arranged in a group (‘instances_in_group’>1), the user might want to introduce an order of their binary existence variable values to break the symmetry of the optimization problem. If the flag is set to True a constraint is created for each component of the group that requires the previous component in the group to exist (BI_EX=1) before the own existence variable can take the value 1.
  Default: True

• group_has_operation_order (bool) – If multiple similar instances are created and arranged in a group (‘instances_in_group’>1), the user might want to introduce an order of their binary operation variable values to break the symmetry of the optimization problem. If the flag is set to True a constraint is created for each component of the group and every time step of the optimization problem that requires the previous component in the group to be operated (BI_OP=1) before the own operation variable can take the value 1.
  Default: True

• use_inter_period_formulation (bool) – A second binary start-up variable is created (BI_SU_INTER), if the inter-period model formulation is requested (flag=True) and start-up cost are introduced (argument ‘start_up_cost’>0). This variable is used in case the model is optimized with aggregated time-series data (multiple periods). The variable links the binary operation variable values of otherwise independent periods, to enforce start-up cost if the operation status (BI_OP) changes from one period to the next (OFF to ON). Note: This formulation introduces additional variables and constraints, and increases both model accuracy and model complexity.
  Default: True

declare_component_constraints(ensys, model)

Method to declare all component constraints.

The following constraint methods are inherited from the Component class and are not documented in this sub-class:

• con_couple_bi_ex_and_cap

• con_cap_min

• con_cap_modular

• con_modular_sym_break

• con_couple_existence_and_modular

• con_bi_var_ex_and_op_relation

• con_couple_op_binary_and_basic_var

Method is not intended for public access!

Parameters

• ensys – Instance of the EnergySystem class

• model – Pyomo ConcreteModel of the EnergySystem instance

con_existence_sym_break(ensys)

Constraint to state, that the next component in a group can only be built if the previous one already exists (symmetry break constraint for groups consisting of multiple components ‘instances_in_group’ > 1), if keyword argument ‘group_has_existence_order’ is set to True. E.g.:
BI_EX (of conversion_2) <= BI_EX (of conversion_1)

Method is not intended for public access!

con_operation_sym_break(ensys, model)

Constraint to state, that the next component in a group can only be operated if the previous one is already ‘ON’ (symmetry break constraint for groups consisting of multiple components ‘instances_in_group’ > 1), if keyword argument ‘group_has_operation_order’ is set to True. E.g.:
BI_OP[p, t] (of conversion_2) <= BI_OP[p, t] (of conversion_1)

Method is not intended for public access!

con_operation_limit(model)

The basic variable of a component is limited by its nominal capacity. This usually means, the operation (main commodity) of a conversion (MWh) is limited by its nominal power (MW) multiplied with the number of hours per time step. E.g.:
Q[p, t] <= CAP * dt

Method is not intended for public access!

con_min_load_rel(model)

Constraint to set a value for the relative minimal part-load of a conversion unit (e.g., a component can either be switched off (BI_OP=0) or can work between 50% and 100% of its nominal capacity if a value of 0.5 for ‘min_load_rel’ is specified. The constraint requires the availability of a binary operation variable (‘has_operation_binary_var’ is True) and currently, fixed capacities need to be specified (‘capacity_min’=’capacity_max’=’capacity’). E.g.:
Q[p, t] >= capacity * BI_OP[p, t] * min_load_rel * dt

Method is not intended for public access!

con_start_up_cost(model)

Constraint to determine the status of the binary start-up variable. If the operational status of a component changes from OFF (BI_OP=0) to ON (BI_OP=1) from one time step to the next, the binary start-up variable must take a value of 1. For shut-down and remaining ON / OFF, the status variable can take both values, but the obj. function forces it to be 0. E.g.:
0 <= BI_OP[t-1] - BI_OP[t] + BI_SU[t]

Method is not intended for public access!

con_start_up_cost_inter(ensys, model)

Constraint to link the binary operation variables of consecutive periods, to enforce start-up cost if the operation status (BI_OP) changes from one period to the next (OFF to ON). With this, the binary operation status of the last time step in the previous typical period and the operation status of the first time step in the current typical period are compared. Binary variable ‘BI_SU_INTER’ indicates a potential status change from OFF to ON. E.g.:
0 <= BI_OP[p_typ-1, t_last] - BI_OP[p_typ, 0] + BI_SU_INTER[p]

Method is not intended for public access!

get_objective_function_contribution(ensys, model)

Calculate the objective function contributions of the component and add the values to the component dictionary “comp_obj_dict”.

Method is not intended for public access!

Parameters

• ensys – Instance of the EnergySystem class

• model – Pyomo ConcreteModel of the EnergySystem instance

serialize()

This method collects all relevant input data and optimization results from the Component instance, and returns them in an ordered dictionary.

Returns

OrderedDict