New component for a heat pipeline

[joroeder]

Hey there,

I would like to suggest a heat pipeline component. It should help modeling district heating systems. Background is, that at the moment the regular transformer has no option of applying a constant energy loss which does not dependent on the actual power. As a first approximation, this is the case in district heating systems. The heat loss in district heating pipelines is determined by the temperature of the medium, the outside temperature, the diameter, the length and the heat transmission coefficient. This all should be put together in one factor which calculates the heat loss dependent on the nominal capacity of the heat pipeline. By providing an investment mode, a kind of infrastructure optimization could be possible.

@oemof/oemof-solph @oemof/oemof-heat
What do you think? Is anybody interested in that component?

In case that this component should become part of oemof, where should it be placed? In #603 there was the discussion of putting heat components in the repository oemof_heat.

[p-snft]

To be honest, I would just use an additional sink… Is there some reason against this solution?

[simnh]

We are currently working on the first version of oemof.tabular which should provide a energy specific components that are based on solph and provide a simple interface for creating models from tabular data. You can check out the docs for a better understanding what oemof tabular provides:

https://oemof-tabular.readthedocs.io/en/latest/tutorials/facade-usage.html

Such component as the HeatPipepline could also go there. All oemof.tabular components can easily coupled with all solph components.

[joroeder]

hey, thanks for your feedback!

To be honest, I would just use an additional sink… Is there some reason against this solution?

Yes, this could be a good option for given heating grids. But when I think of the investment mode, it is necessary to define a transformer, a sink and an equate_variables constraint for coupling the transformer and the sink, hm... seem a little inconvenient to me ;) Is there another option? - but you are right, could be done somehow.

Such component as the HeatPipepline could also go there. All oemof.tabular components can easily coupled with all solph components.

Sounds like a good option! Now, I am wondering, if some new custom components related with heat go to a new repo oemof_heat (according to #603), and some to tabular, maybe this gets confusing in the end?

[jnnr]

Thanks for the initiative! We are working on district heating systems currently, so I am eager to discuss your approach. Constant heat losses can be a good first approximation in the case of operational optimisation. Question is how to handle situations in which the flow is zero. Either one makes sure that this never happens, or an integer variable encodes if the network is operating or not.

Sounds like a good option! Now, I am wondering, if some new custom components related with heat go to a new repo oemof_heat (according to #603), and some to tabular, maybe this gets confusing in the end?

To avoid confusion, I would suggest the following: Let all pre- or postcalculations find a home in the oemof_heat repo. Defining a convenient interface will be done with the help of oemof_tabular. See also in the issue 603.

[uvchik]

@simnh We also discussed the 'facades' idea for solph and I think it is better to add them directly to solph in an additional module to make them available for all solph users not only tabular users. I think if they are part of solph they can also be used in tabular.

@joroeder @jnnr We had a web conference about heat components (facades/alias) for solph. You should talk to @FranziPl and @jakob-wo and have a look at #603 and #594.

[jnnr]

@uvchik: I read #603 and talked to @jakob-wo. What he told me and what is written in the issue after the webcon was something different: That the heat-specific facades should be in the oemof_heat repo. However, I support the idea of keeping facades close to solph rather than putting them to oemof_heat, as I wrote in #603.

[uvchik]

In the result of the web-meeting we distinguished between different kinds of 'facades'.

1. If we do need extra calculations, additional packages etc. the facades should be somewhere else.
2. If it is just a combination of solph components or minimal calculations the facades could be directly in solph.

If components from (1.) would be in solph we would get a lot of new requirements in solph.

I like the idea of (MI)LP-formulations in solph and specific calculations in extra packages like oemof_heat, feedinlib, windpowerlib...

In my opinion we could add a windturbine class or a pv class for solph in the feedinlib but there could also be a special adapter for urbs or any other model. This should not be discussed here, it is just an example for the structure.

[jnnr]

Thanks for making this clearer!

2. If it is just a combination of solph components or minimal calculations the facades could be directly in solph.

I agree. It should be possible to boil down all aliases (at least the ones I can think of) to a minimum of extra calculations.

I like the idea of (MI)LP-formulations in solph and specific calculations in extra packages like oemof_heat, feedinlib, windpowerlib...

I agree!

[simnh]

Well I think putting it to solph is possible and putting it to tabular as well. The main thing about the facades is, that they allow to easy instantiation via two dimensional data. Therefore they are in oemof tabular. Solph can have facades also but I would not move everything to solph again, in particular as release cycles of solph are very slow, while custom components might pop up just much more frequently.

In addition tabular is (though its located in another directory) as subpackage of oemof. Therefore you can do:

from oemof import tabular 

Even if you have installed oemof and oemof.tabular, so making oemof tabular an optional dependency to provide (tabular) facades would be an option also.

I am not attached to the solution, however, for now (due to project reasons) we will release oemof.tabular v0.1.0 this week which will come with the facades. Also this is more a general discussion and not too close to the heat component itself I think...