Facades/Aliases to solph components

In issue #591 the idea came up to introduce facade or alias components in solph.

@p-snft presented a concrete proposal

class solph.custom.airsource_heatpump(solph.Transformer):
    def __init__(**kwargs):
        cop = heat.airsource_heatpump.cop(**kwargs)
        parent().__init__(conversion_factors={b_el: cop}),
                          **kwargs)

@jnnr mentioned that there is a similar feature in oemof tabular:

This is already in a way implemented in oemof_tabular’s facades.

[jnnr]

We (@franziPL and @jnnr) tried to sort the different suggestions and we found 3 main distinctions that are more of less orthogonal:

1. pre-calculations inside the component vs. outside in a separate function.

a) Inside: maybe it is more convenient and it is a little bit less work, if you use just one component (per type)

solph.HeatPump(
    ..., 
    temp_h,
    temp_l
)

b) Outside: Separates two steps and thus gives more control. A bit less convenient.

    cop = cop.airsource_heatpump(temp_h, temp_l, )
    solph.HeatPump(..., cop)

Conclusion: We vote for b) outside of the component option.

2. linear structure of arguments as in oemof.tabular vs. “normal” nested structure of arguments as in oemof.solph

a) linear structure: easier to read, however, possibilities are taken because only the previously defined properties of the objects (such as flows) can be used. Main advantage comes into play if all components have the same flat data structure, which is the concept of oemof.tabular, but not of oemof.solph.

b) nested structure: somewhat more complicated. However, more degrees of freedom are obtained. Besides, it is necessary to know this structure anyway if you want to use other components for which no facade exists.

Conclusion: The normal solph structure a) should be kept, because not all components get facades and thus the only advantage of the linear structure is omitted.

3. Renaming of the attributes of components for convenience

Renaming inputs, outputs and attributes like conversion_factors

solph.HeatPump(
    label='air_source_heat_pump',
    electricity_input={b_el: Flow(nominal_value=60)},
    heat_input={b_el: Flow(nominal_value=60)},
    heat_input={b_th: Flow()},
    cop=airsource_cop
)

can be helpful to distinguish the different types of inputs and outputs and to specify the number of them. Also, if there several distinct conversion factors, this might help.

However, to rename attributes like nominal_value to something like electrical_power would only work with a linear data structure (2a) where the flows are created in the background.

Conclusion: Renaming might be helpful in some contexts to tell apart the different inputs and outputs using specific names. A good reference is the existing GenericCHP, as @p-snft mentioned.

[joroeder]

Conclusion dev meeting (parallel session)

• Definition facade: -> no additional constraints (-> this would be a new custum component) -> the facade must have some further (pre-) calculations for relating/calculation the input parameter (otherwise it would just be a renaming of attributes) OR consists of more components (=subnetwork, cf. #577 )
• thermal/heat facades and subnetworks will be placed in oemof.thermal
• additional facade module ‘facades.py’ in oemof/oemof, if more facades/subnetworks want to be added to oemof that do not fit in oemof.thermal (there can be subnetworks defined as well #577 )
• next dev meeting - check and review the approach and maybe restructure some stuff