Demand power

[sstroemer]

Complicating variable

Similar to #480, demand "power" is a "investment" decision, even if it does not come with an associated cost in that model. That leads to constraints like

c_u_carrier_consumption_max_constraint(_region1__demand_power__power___2005_01_01_00_00_)_ : -energy_cap(_region1__demand_power_) - carrier_con(_region1__demand_power__power___2005_01_01_00_00_) ≤ 0

Furthermore, this prevents us from "solving" infeasibilities in demand coverage just by relying on "unmet demand", since the following combination fails

c_e_balance_demand_constraint(_region1__demand_power___2005_01_01_00_00_)_ : carrier_con(_region1__demand_power__power___2005_01_01_00_00_) = -25284.48
c_u_carrier_consumption_max_constraint(_region1__demand_power__power___2005_01_01_00_00_)_ : -energy_cap(_region1__demand_power_) - carrier_con(_region1__demand_power__power___2005_01_01_00_00_) ≤ 0

if energy_cap(_region1__demand_power_) is not at least the amount of peak demand power. This could be an additional constraint that could actually help with solver performance (or would allow easier decomposition).

Variable bounds

carrier_con(_region1__demand_power__power___2005_01_01_00_00_)

comes with bounds (-inf to 0), while it would be more beneficial to make sure that this is a free variable. It comes "fixed" anyways, by

c_e_balance_demand_constraint(_region1__demand_power___2005_01_01_00_00_)_:
+1 carrier_con(_region1__demand_power__power___2005_01_01_00_00_)
= -25284.48

or do we already know that all solvers properly pick that up as "direct replacement" during presolve? (I know that wasn't always the case for non-free variables)

[brynpickering]

Complicating variable: This is an implementation detail similar to what you raised in #479. We do relatively little to differentiate between technologies of different base classes, so that some get variables/constraints that might be redundant. We do this to make internal implementation easier. I think it will be somewhat solved in v0.7.
Demand energy_cap should just take the value of the highest energy consumption in the timeseries (as other technologies will also end up with, but related to their energy production). It would come into use when you don't fix the amount of energy that a demand technology requires, but let it be free and set a cost on energy_cap / amount of energy consumed (to represent e.g., building a waste processing facility to handle nuclear waste).

What is the additional constraint that could actually help solver performance?

Variable bounds: carrier_con is bound initially to be a negative real value, then is later constrained by enegy balance constraints. For most demand constraints this fixes the value. I suspect that solvers like gurobi would pick this up easily, but I don't know what the overhead is. Another option would be to define demands as parameters (and include them in the system-wide balance as distinct entities) and then only create decision variables for demand technologies with non-fixed per-timestep demands. This could be quite neat, actually.