Closed FabianHofmann closed 3 months ago
You could of course add the resulting capital costs later, but it is definitely more convenient to keep them, which I also advocate.
I would prefer 1, which can also force costs up when too much capacity is built. But at the same time the equality constraint with many variables is more prone to numerical issues.
2 is in fact just a relaxation of 1.
I decided to go with option 2. Two arguments for it:
mu
of the global constraint makes much more sense when having an inequality constraintHope you agree!
@FabianHofmann reopening because @nworbmot raised concerns about mixing line volume constraints and kept line expansion costs. The analogy is carbon price vs carbon cap. Having both distorts the interpretation of dual variables of the constraint (which {lv}
is mainly designed for). But as I expressed earlier, I see the convenience of keeping the capital costs. Maybe one could implement an option for both?
I see the analogy, however note that if the constraint becomes binding the dual price just adds up to the capital price of the lines (this is then the price of installation + scarcity). This is the same as the dual price for the CO2 cap adds up to the operational price of OCGT (we also don't remove operational costs from OCGT and only add a co2 cap). But perhaps we can talk about it in the meeting.
I think the solution we have now, keeping the capital cost of the lines, is good!
The
prepare_networks.py
script removes the capital costs for lines when setting line volume limits. By doing so, we somehow ensure that e.g the option lv1.25 really ends up with a 25% expansion. However I find it a bit misleading. In my point of view we should keep the capital cost and==
Any thoughts?
https://github.com/PyPSA/pypsa-eur/blob/8c5efb5252ec6da029e2ad9178ce019d1ed2dec1/scripts/prepare_network.py#L153