Future year 12.7 PJ export inconsistent with assumption of 0 PJ export in etengine?

[ChaelKruip]

EDITED: Whit the Merit Order on, there is 12.7 PJ of export of electricity in the model.

When initializing the Merit module, we assume that export is not happening when Merit is on. Does this lead to a shortage of electricity produced by Merit (sorry for not having the time at his moment to investigate this myself)?

I just wanted to put this concern / question out there. Including @AlexanderWirtz @dennisschoenmakers @jorisberkhout

[antw]

@ChaelKruip How would you go about determining what the total demand for electricity is? Does this look about right?

SUM(
  # Sum of electricity input to converters in the final demand group:
  V(GRAPH(), final_demand_for_electricity),

  # Use of electricity within the energy sector:
  V(GRAPH(), energy_sector_final_demand_for_electricity),

  # Losses and export:
  V(energy_power_hv_network_loss, demand),
  V(energy_export_electricity, demand)
)

[antw]

Didn't mean to submit that comment so quickly. :anguished:

You're right that exports are not included in electricity demand given to the merit order, but I've got no idea why this is the case. My guess is it's because export is calculated dynamically? (the export converter is connected to the hv_network_electricity converter with an inverse_flexible link, so it will take away the unused electricity from the HV network)

Assuming the above query is correct, then the result does differ from the graph's total_demand_for_electricity used to configure the merit order. I think this is okay so long as the export demand isn't a static, pre-defined value in ETSource.

[ChaelKruip]

I will give a more thorough answer later but to shortly answer some questions / take away some confusion:

Does this look about right?

Almost. The energy_sector_final_demand_for_electricity should by part of the final_demand_group IMO and there should be no need to include it separately!

You're right that exports are not included in electricity demand given to the merit order, but I've got no idea why this is the case.

That was by design. I think we were using 2010 data at the moment and (I am guessing here), we wanted the Merit module to exactly meet local demand (including own use of the energy sector and network losses). @AlexanderWirtz do you remember any particulars here?

the export converter is connected to the hv_network_electricity converter with an inverse_flexible link, so it will take away the unused electricity from the HV network

Ok, but this means that Merit produces too much (and export is used as an overflow)! Merit should only be able to produce more then is needed if there are hours that must-run and volatile (always on) production is higher then demand. In such cases we export the excess electricity. I don't think this should happen at any point with the modes installed capacities of those producers... :worried:

[AlexanderWirtz]

I am not sure what is going on, but hard coding export doesn't make sense. Let's look at this later. Merit is initialized with the net import/export balance, which in 2012 favors imports by ~17 PJ. I do not understand why either imports or exports should be initialized to anything as the net balance results from the energy balance. In other words:

• final demand for electricity is set by the energy balance
• grid losses are set by the energy balance
• energy sector own use and other own use (not sure of the latter) of electricity is set by the energy balance
• gross production of electricity is set by the energy balance

Since: supply of electricity = demand for electricity then: (all pertain to the carrier electricity)

final demand + grid losses + own use = gross production + imports - exports

exports are inverse flexible here, so we should write:

final demand + grid losses + own use = gross production + (net import/export balance)

[ChaelKruip]

After some investigating, I am convinced that is was indeed the double counting of the own use of the energy sector. This pull request should fix it.