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...

[joroeder]

Hey, thanks for the discussion so far - maybe there is need for opening a separate issue for that discussion?

But back the HeatPipeline component. Uwe came up with the idea of a more general option of adding a constant loss parameter to a flow by adapting the flow block class itself. Hereby constant losses can be considered in all components, e.g. stand-by energy consumption or other stuff. What do you think?

[uvchik]

@simnh Do the tabular facades work directly in solph without the datapackage?

@joroeder You are right. There is already an issue -> #594

[simnh]

yes they do

[joroeder]

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.

Yes, that's right. The temperature loss (of one element with zero flow, or in a far away grid element) which implies a lower heat loss is not considered. So it is a calculation of the ideal design case, which assumes constant temperature in all supply and return lines. For application, this means that the average temperature of the supply and the return line needs to be estimated in order to determine the loss-factor of the lines. However, I think that will be a better representation of heating pipes/lines than just using a power(t) dependent formulation. Maybe a combination of power(t) dependent (=efficiency of transformer) and constant losses could be a solution - even though this is a problem for the parametrization. For a more detailed destriction of all the heat related stuff in optimization models, probably, linear models reach their limits (Q = mcdT). For a more complex heatpipe element we could try to integrate the ideas of #621 in the heatpipe element... puh, this gets probably tricky ;)

[jnnr]

After some discussion we have some new ideas on the heat pipeline which I would like to share and discuss. This is a sketch of the component we have in mind:

The initial post described a new pipeline component with a constant loss, which is a good first approximation of a heat pipeline. It was suggested to use a facade instead of writing a new component, as the functionality would just be a facade as a wrapper around a sink. However, what if pipelines are switched off for some time? The following graph shows two options for the operation range of a heat pipeline:

(1) Shows a heat pipeline that can be turned off. This implies an integer variable. A way to implement this would be using the existing OffsetTransformer. (2) shows the same, but without the option of turning the pipe off. It would be nice to have both options, as (2) is computationally cheaper.

I imagine the new functionalities like this: New functions as part of the module oemof-thermal will help perform the precalculations of Q_max, Q_min and losses_fixed. Therefore, a function get_operation_range would need these inputs:

get_operation_range(diameter, length, temp_inlet, temp_return,  isolation,  roughness, mass_flow_max)

    ...

    return heat_flow_min, heat_flow_max, losses_fixed

A dataset about typical pipe properties should be part of it, providing some good default values.

The component could look like this:

oemof.thermal.heat_pipeline.HeatPipeline(
    label='pipe-1' ,
    inputs={b_heat_0: Flow()},
    outputs={b_heat_1: Flow(
        heat_flow_min=5,
        heat_flow_min=1)},
    losses_fixed=0.1 )

These concepts apply for operational optimisation. For the case of investment, further precalculations would be necessary. I can write more on this in a later comment.

[uvchik]

According to the discussion in #594 the API could also look like this.

oemof.thermal.heat_pipeline.HeatPipeline(
    label='pipe-1',
    inbus=b_heat_0,
    outbus=b_heat_1,
    heat_flow_min=5,
    heat_flow_min=1,
    losses_fixed=0.1)

[joroeder]

(1) Shows a heat pipeline that can be turned off. This implies an integer variable. A way to implement this would be using the existing OffsetTransformer. (2) shows the same, but without the option of turning the pipe off. It would be nice to have both options, as (2) is computationally cheaper.

Actually, I don't understand, why there is a not allowed operations range between 0 and heat_flow_min, as it is the case in the OffsetTransformer. The heat_flow is the results of mass flow and temperature difference. The mass flow can be zero or higher than zero (as well as the temperature difference), so the heat_flow can do the same.

Is your idea in option (1), that you like to "switch off" the constant losses of the heat_pipe in case of no heat_flow is "flowing"? And hereby, the heat_flow_min is kind of a help-construct for doing that?

In that case, it dependents on how long is the district heating grid switched off. Directly after switching the heat_pipe off, the constant losses are still the same as in operation mode, because the temperature difference between the fluid and the sourrounding is still the same. After a while the fluid cools down, and the power loss will decrease.

So, it dependents on how the district heating grid is operated. The district heating grids I got to know so far, supply hot warm water as well, and thereby cannot be switch off e.g. during summer (I haven't seen a DHS which is switched off at any time. Please let me know about projects, which are doing that, I am very interested in.) But sure, in this case, the switching off of the constant losses become important, especially, if the DHS is switched of for more than a couple of hours, so that the DHS really cools down.

Generally, the assumptions of this fix-loss approach for DHS were, assuming constant (kind of average) forward and return temperatures in the whole DHS. Thereby, the constant losses are just dependent on the dimension of the pipe (at a given delta_T between fluid and environment), and can be more easily considered in investment considerations and network optimizations. Physically of course, energy loss without "temperature loss" are not correct. But I don't see another option for linear models.

[joroeder]

get_operation_range(diameter, length, temp_inlet, temp_return,  isolation,  roughness, mass_flow_max)

    ...

I like your suggestions. This precalculations are necessary in any of the implementations . The most difficulat part is probably, how we define heat_flow_max. Maybe, one parameter could (or should) be, the maximum pressure drop per meter, which is allowed. This leads to a maximum velocity for a given delta_T, which gives us the maximum heat_flow.

[jnnr]

I just noticed that a Link with constant loss would be useful in the context of models for the electrical grid as well. At the moment, the custom Link only has relative losses. We should consider that when deciding on an implementation.

[p-snft]

Revisiting this, I wonder if this actually a facade to the OffsetConverter? If so, I'd see it in oemof.thermal. (Also, I'd really like to see it implemented.)