Penalty handling methods

[nelliputkonen]

This need arises from South Africa, where planned load shedding is an everyday situation. Currently FlexTool can only process loss-of-load/penalty based on penalty up/down values. This always directs the loss-of-load to a node where the penalty costs are lowest or if they are equal, wherever the loss-of-load is most expensive to avoid. This does not represent the case in South Africa, where loss-of-load is shared equally between consumers. I would imagine there situation would be described by a penalty method based on equal load shedding: each node experiences same percentage of loss-of-load.

Although this is the case in South Africa there might be a case to make a weighted or fixed loss-of-load distribution. Ideally, the penalty method would allow also for these settings. While the need arises from one case study, I imagine similar needs can be quite common in developing regions.

[jkiviluo]

This should be implemented in the post-processing side as an additional result variable. Creating a constraint for this would just create additional variables without creating meaningfully different results.

Probably only nodes with an equal penalty value should participate in the equal sharing. Sum all penalties from those nodes, divide by the number of nodes, report a separate variable.

[nelliputkonen]

I think that might not be sufficient. Consider e.g. the following system: Firstly, if you would simply sum all penalties and divide by number of nodes, you would result in e.g. 10% loss-of-load -> 750 MW of loss of load for both nodes. Probably should be in proportion of the demand (500 & 1000 MW) or selected by the user which one. But secondly - to my actual point - the unit commitment changes based on where the loss-of-load happens. If all happens in the node with larger demand, the unit needs to generate less electricity, because of the location of the unit and the transmission losses. If we let the model decide, it will direct all the loss-of-load there, right? And if we then in post-processing divide this between nodes, we end up with different results that we would if we had considered the splitting of loss-of-load before calculation.

[jkiviluo]

Ok, let's allow a group setting to fix the ratio of loss-of-load between the nodes in the group. Is it enough to have an option to fix the loss-of-load based on the inflow ratio (each node will have a loss-of-load share corresponding to their demand)? Other options could be: equal amount of loss-of-load and user-defined portion per node. The latter would need also a new parameter (I'm mildly against that since we should try to keep FlexTool simple).

[jkiviluo]

In terms of implementation:

• new variable vq_state_up_group (I suppose it's enough to do this for upward slack)
• calculate the share of loss_of_load for each timestep for each node in the group (new parameter p_state_slack_share[n, d, t]), The shares should sum to 1 for each timestep (for each group).
• new constraint for each node in the group of nodes: constraint says vq_state_up = p_state_slack_share * vq_state_up_group. Remember to consider node_capacity_for_scaling.

I'm bit afraid of equality constraints (can cause infeasibilities or make the model slower when it tries to get the decimals right, but let's see). On the other hand, this could possibly improve the speed, since there will be only one variable enforcing behavior - the other's are fixed based on that vq_state_up_group.

We could just replace the existing vq_state_up variables with this vq_state_up_group (using a conditional), but that would mess up many things in the model (output side), so better not to.