greco-project / pvcompare

pvcompare is a model for comparing the benefits of different PV technologies in local energy systems in different energy supply scenarios.
GNU Affero General Public License v3.0
13 stars 4 forks source link

self-consumption, etc. KPIs not correct when using heat pump due to weighting #218

Closed SabineHaas closed 3 years ago

SabineHaas commented 3 years ago

As I have already mentioned in a meeting, KPIs that include weighting of energy carriers are faulty when using a heat pump to cover the heat demand.

Reason: weighting factor of electricity equivalent of heat is ~1. As the average COP of a heat pump is >> 1, the weighting factor should be << 1 ( for supplying a unit of heat demand you need less than a unit of electricity).

This results e.g. in a lower degree of NZE, see definition:

105874470-a096a280-600d-11eb-96f6-2b5d524a8a75

Not sure, yet, whether we will solve this in MVS or have to post-process that in pvcompare

SabineHaas commented 3 years ago

I've discussed with MMH about this and we came to the conclusion that it's better to compare the results of the two cases before we make a decision: 1) energy weighting as it is implemented in MVS 2) adapted energy weighting by average COP

@MaGering as you wanted to look into this anyways, could you upload your results here, please? For MMH it's always easiest to look into the automatic report, you can generate it by adding pdf_report=True, to mvs.main() in pvcompare.

Then we can compare the KPIs of 1) and 2) and discuss our expectations.

MaGering commented 3 years ago

I've discussed with MMH about this and we came to the conclusion that it's better to compare the results of the two cases before we make a decision:

1. energy weighting as it is implemented in MVS

2. adapted energy weighting by average COP

@MaGering as you wanted to look into this anyways, could you upload your results here, please? For MMH it's always easiest to look into the automatic report, you can generate it by adding pdf_report=True, to mvs.main() in pvcompare.

Then we can compare the KPIs of 1) and 2) and discuss our expectations.

Sure. I've done three simulations:

  1. Sector-coupling containing heat pump with default weighting factor of 1.0002163
  2. Sector-coupling containing heat pump with adjusted weighting factor of about 0.204 calculated from the average COP over the year (4.9)
  3. Sector-coupling containing gas boiler and no heat pump with default weighting factor as reference for the second simulation

Here is a plot of the degree of autonomy: Degree_of_autonomy

And here are the PDF reports of the three simulations: simulation_report_gas_heating.pdf simulation_report_weighting_factor_default.pdf simulation_report_weighting_factor_adjusted.pdf

Finally I was curious about the influence of the weighting factor on the degree of autonomy and so I did this plot: Degree_of_autonomy_hp_comparison

(In order to obtain the weighting factor from COP you need to calculate 1 / COP)

SabineHaas commented 3 years ago

Thank you @MaGering ! This looks different from what I had expected. Shouldn't the weighting factor for Heat be the COP instead of 1/COP? It is used in the following way: heat demand electricity equivalent = heat demand * factor

If this is true and you do the simulations again, could you checkout MVS branch feature/degree_of_nze please? Then we can also check the NZE degree.

MaGering commented 3 years ago

Thank you @MaGering ! This looks different from what I had expected. Shouldn't the weighting factor for Heat be the COP instead of 1/COP? It is used in the following way: heat demand electricity equivalent = heat demand * factor

This is the equation for the relationship between electrical power, the useful heat flow and the COP of the heat pump: COP_HP

The useful heat flow corresponds to the heat demand. Accordingly, the following applies to the electrical power of a heat pump: Electrical_Power_HP

Here's another plot which contains, in addition to the two different weighting factors (default and adjusted), the electricity sector only (no heat demand): Degree_of_autonomy_sector_comparison

We rather expect, that the degree of autonomy decreases with increasing demand and no further generation. So the connection shown above must be correct, right?

MaGering commented 3 years ago

@smartie2076 @TheOneAndra @Bachibouzouk here's the issue I talked about in our meeting today.

MaGering commented 3 years ago

To summarize the current status: We agreed on not using KPIs for sector-coupled systems in pvcompare, which contain the weighting factor in their calculation, as for example the degree of autonomy with the weighting factor of heat of ≈ 1.

For a sector-coupled system, which contains a heat pump, we can calculate the degree of autonomy, the degree of NZE and the self-sufficiency (OEM) by taking the electricity demand of the heat pump into account on top of the total electricity demand. At this point it is important to say that the total_demand of electricity is only the electricity demand, which descends from the electricity consumption in static_inputs directory and hence it does not contain the electricity demand of the heat pump.

Now we can calculate the KPIs in two ways:

  1. Implementing them separately in our own post-processing or
  2. we could use the mvs implementations for our own purposes modifying the weighting factor of heat in mvs via the COP as conversion factor. This only works, if the heat pump is covering the whole heat demand, which it does. We then need to calculate the mean COP out of the COP time series (it depends on the ambient temperature and technology specific values: temp_high, quality grade and if applicable icing factor). It results from pvcompare's precalculations. Then we insert 1 / mean(COP) here. Doing this we can use the KPIs, that are already implemented plus we can work with constraints. We only need to take care to adjust our own "weighting factor" to the heat pump technology we are simulating.

We have to keep in mind, that we can not compare these KPIs to the ones from a scenario with a gas plant for heat coverage however.

smartie2076 commented 3 years ago

Hi @all,

Puh, this is a difficult topic. So, I agree with @MaGering that conversion factor = 1/COP, as otherwise with your formula @SabineHaas electr equivalent = heat * conversion factor, with a COPof 4, 1 unit of heat would be worth 4 units of electricity.

For a sector-coupled system, which contains a heat pump, we can calculate the degree of autonomy, the degree of NZE and the self-sufficiency (OEM) by taking the electricity demand of the heat pump into account on top of the total electricity demand. At this point it is important to say that the total_demand of electricity is only the electricity demand, which descends from the electricity consumption in static_inputs directory and hence it does not contain the electricity demand of the heat pump.

Now we can calculate the KPIs in two ways:

1. Implementing them separately in our own post-processing or

I do agree with calculating the KPI for your energy systems, which can basically be translated in pure-electricity systems, based on electricity demand + electricity demand for heat pump. That way, you will also take into account for the time-dependent COP. This is a bit more exact.

2. we could use the mvs implementations for our own purposes modifying the [weighting factor of heat in mvs](https://github.com/rl-institut/multi-vector-simulator/blob/fc8dff781ecb0873cdff18f33cc9ccff9288293c/src/multi_vector_simulator/utils/constants.py#L298-L302) via the COP as conversion factor. This only works, if the heat pump is covering the whole heat demand, which it does. We then need to calculate the mean COP out of the COP time series (it depends on the ambient temperature and technology specific values: temp_high, quality grade and if applicable icing factor). It results from pvcompare's precalculations. Then we insert `1 / mean(COP)` [here](https://github.com/rl-institut/multi-vector-simulator/blob/fc8dff781ecb0873cdff18f33cc9ccff9288293c/src/multi_vector_simulator/utils/constants.py#L300). Doing this we can use the KPIs, that are already implemented plus we can work with constraints. We only need to take care to adjust our own "weighting factor" to the heat pump technology we are simulating.

If you want to use the constraints, I think it is valid for your case to manually manipulate the conversion factor to 1/mean(COP) - it is not the most exact you can be, but quite good already and you anyway only have one heat pump, right? If you are worried about the KPI not being exact - you can either run 3 simulations with 1/min(COP), 1/mean(COP), 1/max(COP) or manually recalculate the sector-coupled KPI in 1) for the first as well as final scenarios, so that you know the deviation.

We have to keep in mind, that we can not compare these KPIs to the ones from a scenario with a gas plant for heat coverage however.

I am not sure about that... but that is just a feeling. Is this important enough to discuss?

MaGering commented 3 years ago

If you want to use the constraints, I think it is valid for your case to manually manipulate the conversion factor to 1/mean(COP) - it is not the most exact you can be, but quite good already and you anyway only have one heat pump, right? If you are worried about the KPI not being exact - you can either run 3 simulations with 1/min(COP), 1/mean(COP), 1/max(COP) or manually recalculate the sector-coupled KPI in 1) for the first as well as final scenarios, so that you know the deviation.

Thank you @smartie2076. These are some really good ideas! :) In the meantime we already decided for the first option also due to these inaccuracies we would face, which you described.

We have to keep in mind, that we can not compare these KPIs to the ones from a scenario with a gas plant for heat coverage however.

I am not sure about that... but that is just a feeling. Is this important enough to discuss?

Ah sorry! I meant for our scenarios in pvcompare, since we decided to not work with the weighting factors, we must refrain from comparing KPIs that contain both heat and electricity demands.

SabineHaas commented 3 years ago

@MaGering I think we can close this issue now, right?