Skip to content

Conversation

lindnemi
Copy link
Collaborator

@lindnemi lindnemi commented Jul 22, 2025

Next Steps and Open To Dos:

  • Code Review:

    • This PR contains three separate things: the regret_workflow, a changed industry demand (see Improve exogenous industry demand #98), and a new global constraint for the maximum heat pump capacity. The first part is the biggest part and concerns only the regrets, the second and third points are smaller and also concern the LowDemand and AriadneDemand scenarios themselves
  • Start drafting graphics for the Papier:

    • Comparison of (electricity) Capacities in DE/EU for both long-term scenarios LowDemand / AriadneDemand
    • Comparison of (electricity) demand for both long-term scenarios
    • Comparison of prices (CO2, Electricity), Trade Revenues/Expenditure and System Cost in the regret runs
      • If the CO2 price in the short-term run is fixed to the price of the long-term run, the model may emit more co2 (because of changed demand). In this case compute by how much the co2 budget is exceeded
    • For prices: think about how to compute the EEG Umlage on the electricity price
    • CAPEX also for ST runs (just for checking)
  • Get the Trade part of the system costs right. Open questions:
    - What should you get for selling energy from bus0 to bus1. Price at bus1? Price at bus0? The difference (i.e. the congestion rent)? Or bus0 + half the congestion rent?
    - What to do about the losses (for DC): consider the energy input or the output of a trading link?
    - Is my intuition true, that the electricity at bus0 "is already paid for (via CAPEX and OPEX)", and how does that impact the trade revenue?

    • prepare a PR against pypsa-de that improves the trade part of the total system cost calculation

    • At the moment get_link_opex in get_economy in the exporter does not return the same results when it is called with all carriers separately and then added, or with all carriers at the same time. This is probably due to a weird interaction between negative export prices caused by the import limit constraints (see further discussion below) and an (unnecessary) abs() call in get_link_opex

    • Again regarding trade: When the import limits are active, they offer an incentive for EXPORTING when prices at the exporting bus are HIGHER than at the importing bus, in order to be able to import more when the system most needs the energy. The shadow_value of the import constraint determines how much of a loss is acceptable for exporting energy.

      • For the investment runs these constraints probably make sense nevertheless (because they encode autarky requirements), however, less so for the operational runs! Should they be deactivated or at least relaxed during investment runs? Or more generally, should we use them even for standard investment runs after the post-discretization (i.e., when line expansion is disabled)?
      • What happens in the short term and regret models when the operational constraints are relaxed / disabled? Do we see huge amounts of imports?
      • Considering system costs: Does the same logic for trade revenues and congestion rents apply when the price difference is negative (due to the import constraints)? After all, in this case DE should be LOSING money because of the export. Assuming that congestion rents are distributed 50/50, would it be fair to assume that in this case of negative revenues the importer would bear half the loss?
      • Should the multiplier of the import constraints be included in the Energy System Cost Calculation (as a premium for a bit of Autarky), and if so, how?
  • compare the results of the scope_to_fix:DE setup and the scope_to_fix:EU (with fixed CO2 price) setup

  • Finish a 3H run on the cluster

  • Medium Term: Think about a scenario with reduced flexibility

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants