Closed sjpfenninger closed 1 month ago
Another option is to have it as a param in the math. E.g.
Pros: one place for constraint names; more likely that you get the constraint name right when defining it? Cons: you have to have this in a separate file and load it as additional math.
constraints:
system_balance:
save_shadow_price: true
Could also work. I would add as another con that this mixes something that's more akin to a config for postprocessing with the math definition?
What can be improved?
We should allow the user to configure a list of constraints for which shadow prices should be saved in YAML, and have these then dropped into the results as data variables with some standard naming like
shadow_price_{constraintname}
.Something like:
config.solve.save_shadow_prices: [system_balance]
resulting inshadow_price_system_balance
as a variable in the results.Version
v0.7.0.dev