oemof / oemof-solph

A model generator for energy system modelling and optimisation (LP/MILP).
https://oemof.org
MIT License
294 stars 125 forks source link

aggregation of domestic decentral solar thermal systems #647

Open FranziPl opened 4 years ago

FranziPl commented 4 years ago

In the oemof_heat team, we discuss, how to model solar heating systems. If you want to model a district with domestic solar systems, it is difficult to aggregate them because of the different sizes of the components and thus different points in time, when the backup heating has to start. The picture shows a scheme of such a system: picture_for_Issue Do you have the same problem? How do you handle it?

We thought about the following idea: Instead of aggregate all storages and all collectors of the systems, which would be really unaccurate, we want to classify two different types of domestic solar systems:

The system shown in the picture can be characterized by two ratios: grafik or, also possible: grafik

Usually these ratios are constant within the two types. So it is possible to aggregate the houses within one type and define the ratios. This would be more accurate than an aggregation of all installed systems. If there are special system modifications, there can be defined more than two groups.

It would be convenient, to design a facade, to combine the components storage and collector for all systems of the same type and characterize them by the ratios.

joroeder commented 4 years ago

Interesting topic! We don't have the problem yet, but we might face it within our project, when we want to consider solarthermal options at the single houses ... ;)

I think there a few challenges involved, which we might discuss separately:

1) aggregation problem as you said, if you combine everythin together, the solarthermal (ST) of one house can supply another house, which is not correct. I think classification and some precalculation (cover ratio, and so on) like you are suggesting is a good solution, if you don't want to model every single house. I wonder in that case, what are your decision variables you leave oemof.solph to optimize? Do you want to decide which system configuration is best for a single object, or do you have a fix set of given decentral solar thermal systems and want to know the contribution to the heat demand coverage of a district? Is it like a solar-thermal feed-in lib you are thinking of?

2) modeling solarthermal collectors (and heat components generally) in linear models How do you calculate the feed-in of a ST collector generally? Already this depends on the rest of the hydraulic / heating system of each house ... The return temperatures to the solarthermal collector need to be guessed or assumend. In the end you need to know the "SoC" of the thermal storage to calculate the feed-in of the collector ...

c-moeller commented 4 years ago

Shall we add this as a session at the developer meeting? There is still space on Wednesday afternoon ;-)

p-snft commented 4 years ago

The topic is also interesting to us. At the moment, we do not aggregate but only allow SC at one location (or at another one in a second scenario).

For "guessing" the the return temperatures, we decided to provide time series for different temperature levels and connect those sources using XOR (#623). This way, the optimizer can decide on the temperature level (see sketch of the network in doi:10.20944/preprints201912.0324.v2).