Should dumped heat be allocated to final demand?

[mabijkerk]

Background The energy sector contains dumped heat as one of its final demand nodes:

INTERSECTION(G(final_demand_group),SECTOR(energy))

[
  #<Node energy_direct_air_capture_co2_electricity>,
  #<Node energy_heat_dumped_steam_hot_water>,
  #<Node energy_offshore_sequestration_co2_electricity>,
  #<Node energy_power_sector_own_use_electricity>,
  #<Node energy_production_synthetic_methanol_electricity>,
  #<Node energy_production_synthetic_methanol_hydrogen_non_energetic>,
]

In a scenario with significant excess heat production on the district heating network, the final demand of the energy sector will increase as well. See below an example for a blank scenario for Ede where significant overproduction of heat has been implemented:

Discussion The main question is whether it makes sense to allocate wasted heat on the district heating network to final demand. I would argue instead that it should be considered as a loss in the conversion part of the graph, similar to conversion losses in e.g. power plants.

Following a brief discussion with @michieldenhaan the likely argumentation for this choice is that it is not modelled as a loss, but as steam_hot_water, and therefore has to be explicitly allocated to final demand in order for it to be counted towards primary demand and CO2. If it is not allocated to final demand, this wasted heat, and therefore the associated primary demand and CO2, would be 'missing' from our calculations.

Solution I suggest that we find a way to model this wasted heat in such a way that it is incorporated in primary demand and CO2, without having to allocate it to the final demand of the energy sector. We can pick this up within the heat improvements project. @AlexanderWirtz what do you think?

[AlexanderWirtz]

@mabijkerk I completely agree with your suggestion. Very good to know that this is the reason for including it in final demand. It isn't of course.

It does make sense to give some thought to what generates this 'dumped heat'. This is actually not the traditional kind of 'losses', but as far as I know:

1. 'Excess production' by biogas CHPs: 2000 hours of heat production from these units that cannot be turned off (because the local production of biogas cannot be slowed down, even though there is nog local demand.
2. Heat production by CHPs that are running to produce power in hours when there is not heat demand in their sector (typically summer hours).

Now, we could give users the option to add seasonal heat storage options with the CHPs that typically cause these excesses of heat that get dumped. It would stand to reason that structurally wasted heat will eventually be put to good use, so such storage options would not be such a strange idea. This is likely to drastically reduce the amount of dumped heat. Any dumped heat that remains can then more logically be assigned as a loss.

I write all this from a position of relative ignorance on how much time and effort this would cost. But I do think it is worth looking at a few scenarios with considerable amounts of dumped_heat to analyse which CHPs typically produce it. After that we could have a look at my suggested improvement and come up with a cost estimate.

Even if there is no scope within the heat improvements project to take this up, it would be an excellent suggestion for a next step. Meanwhile, if we find a way to allocate the dumped heat to losses instead of final demand, this will still work after we implement my suggested improvement. There would just be fewer losses.

What do you think @mabijkerk ?

[mabijkerk]

In the example above I added the maximum amount of geothermal, solar, and imported heat to an otherwise blank scenario for Ede. I think in most datasets the dumped heat in the starting year is relatively low, or even zero for regional datasets since we match demand and supply there. The example mainly shows that in the future year the losses can be caused by all types of must-run heat producers, not only from CHPs.

As for your suggestion: we do already offer the option to implement seasonal storage, which stores any excess production by must-run heat producers. I'm therefore not sure if I get what you mean, do you suggest adding multiple types of storage?

Finally we should note that agriculture_heat_unused_steam_hot_water and industry_unused_local_production_steam_hot_water are allocated respectively to the agriculture and industry sector final demands. If we change the allocation for the energy sector, we should update these nodes accordingly.

[AlexanderWirtz]

Aha, I got it wrong then and dumped heat really is just losses and whatever is not used up in the seasonal storage on 1 April.

In that case, without a doubt it would be better to assign it as losses (also for the other sectors you mentioned) and find a way to get the primary energy calculation to take it into account (as it does other transformation losses).

Well-spotted @mabijkerk ! 😄

[mabijkerk]

Losses:

• Heat is dumped when inflexible supply exceeds inflexible demand (when storage is turned off)
• Heat is lost due to losses over time in storage
• Heat is dumped when storage is turned on but the heat stored at the end of the year is nonzero
• This heat is allocated to final demand of the energy sector

Criteria:

• We want to allocate this heat as a loss instead, in such a way that it is taken into account by the recursive factors that use the steam hot water from the network, while maintaining the functionalities that we currently have (e.g. we want to query the losses, we want to query certain curves etc.)

@noracato could you generate some ideas as to how we can change the modelling of the heat losses mentioned above, that meet the criteria?

[noracato]

Do I understand that you want the node to not show up when querying the final_demand_group, but other than that to act exactly like being part of this final demand group in the calculations?

Then we could add an extra group like final_unused_demand_group that joins all the final demand calculations in recursive factor.

But I feel that what you want is a little more complicated, so I'll keep thinking 🙂

[mabijkerk]

Do I understand that you want the node to not show up when querying the final_demand_group, but other than that to act exactly like being part of this final demand group in the calculations?

No, I want this node to be completely out of the final demand calculations.

Basically, what I want to achieve is something similar for the energy_heat_network_storage node towards the energy_heat_dumped_steam_hot_water as for the energy_production_aggregator_steam_hot_water to energy_heat_unused_steam_hot_water.

To give the example for the energy_heat_network_storage node when there is dumped heat (so there is excess heat at the end of the year). I want to replace the current structure:

With something like the following structure:

I want to restructure the graph in the way indicated in the second example, in the hope that querying primary demand on the energy_distribution_steam_hot_water node will also take into account all the primary energy required to 'produce' the losses in storage.

There are only two questions:

1. Is my interpretation of the recursive factors correct in the sense that in the second example, remodelling the losses to show as the carrier 'Loss' instead of the carrier 'Steam hot water', will indeed included the energy needed to produce these losses?
2. What output and edge type structure on the energy_heat_network_storage is needed to model this behaviour?

[mabijkerk]

Like energy_flexibility_curtailment_electricity for electricity, energy_heat_unused_steam_hot_water is a form of curtailment. It therefore has the following attributes:

- heat_network.group = curtailment
- heat_network.subtype = curtailment
- heat_network.type = flex

It is a requirement for a participant in heat_network to have steam_hot_water as its carrier. The solution sketched above is therefore not suitable, because the energy_production_aggregator_steam_hot_water-energy_heat_unused_steam_hot_water cannot be set to loss.

Instead, we should consider a solution similar to curtailment for electricity: the curtailment node does not belong to the final demand group, but is queried separately as part of "Export and curtailment" in the primary demand charts. Therefore the goal of this issue is:

• [ ] Remodel unused steam hot water to reflect implementation of curtailed electricity, which means that it is not part of final demand, but queried separately

[mabijkerk]

A question is whether curtailment of heat should be seen the same as curtailment of electricity.

• Curtailment of electricity is actually electricity that is not produced, but for our modelling we have to allocate it to demand. This is why it is not part of final demand but a separate category: "Export and curtailment"
• Curtailment of heat may be heat that is actually produced but wasted to the environment. Can we then still allocate it to the "Export and curtailment" category or should it be categorized differently? If so, how?

This also ties into our broader discussion about curtailment in the energy system: https://github.com/quintel/etsource/issues/2930

[github-actions[bot]]

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.