Output of loss on the HV network does not match delta between input and output of electricity

[mabijkerk]

Introduction
In the II3050 European governance scenario on PRO, this is the HV network node:

As you can see the output does not equal the input. This is a known issue caused by flexible electricity demand. It is described extensively on Basecamp.

Description of the issue from Basecamp

Flexible demand like P2H, P2G and batteries are calculated in Merit. For each hour in the year, Merit determines the demand of these technologies. Subsequently, Merit communicates the total (annual) demand of these nodes to the energy graph, setting the demands of nodes like industry_chemicals_refineries_flexibility_p2h_network_gas_electricity and energy_hydrogen_flexibility_p2g_electricity. These nodes are not connected to the regular ETM power grid nodes but instead are all connected to energy_production_excess_electricity.

This results in a mismatch of inputs and outputs of the energy_power_hv_network_electricity node. Most electricity production technologies are connected to the HV network (exceptions are local sources like roof solar, industry CHP etc.). These are the inputs of the HV node. Most baseload demand ultimately also ends up on the HV network (insofar it isn't served by local production). This is the output of the HV node. Since flexible demand nodes are not connected to the power grid but do consume electricity, flex demand does not end up as an output of the HV node. The result is that input > output on the HV network.

Problem
Below I have run a number of queries for the scenario (see this Excel):

The nodes that have electricity demand > 0 and are connected to the HV network node (marked in yellow) are summed to give 855 PJ (marked in blue). The output of loss of the HV network node is 238 PJ (marked in blue). Together this sums to 1093 PJ (marked in green) which is the total electricity input.

There are a number of inconsistencies however:

• The output of loss of 238.3 PJ is not equal to the loss of 51.8 PJ going to the energy_power_hv_network_loss node
• The output of loss of 238.3 PJ is not equal to the electricity of 217.2 PJ going to the energy_production_excess_electricity node
  • Then what does the output of loss actually query?
• The sum of electricity by nodes connected to the energy_power_hv_network_electricity of 854.8 PJ is not equal to the output of electricity of 1030.7 from the energy_power_hv_network_electricity node
  • Then what does the output of electricity actually query?
• The sum of electricity by nodes connected to the energy_power_hv_network_electricity of 854.8 PJ and loss of 51.8 PJ is equal to the output value shown in the screenshot of 906.6 PJ, but this value is not used anywhere else to arrive at a consistent result

Solution
Further research is required to determine how these values are intertwined. Notifying @ChaelKruip and @noracato

Some root causes that might play a role here:

• The known issue addressed on Basecamp
• Some of the flexibility nodes have been decoupled from the excess electricity node and moved to the graph. They are however still calculated in the same way as the flexible demand nodes which are still connected to the excess electricity node. This applies to the P2H boiler and heatpump and the hybrid heaters.
• The known issue addressed here which causes electricity yearly output to be different from the sum of the hourly output curve for p2p technologies
• The fact that storage technologies such as the OPAC neither get their electricity from the HV network nor supply to it, which might causes a delta on both sides
• The fact that storage technologies such as the large-scale batteries are connected to the MV network, but the excess electricity node seems to get all its electricity form the HV network node

[github-actions]

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.