feat(clearing): support directional transfer capacities in complex clearing - #812
feat(clearing): support directional transfer capacities in complex clearing#812isaac-gumbrell wants to merge 6 commits into
Conversation
…ex clearing - Implemented aggregate_line_capacities function to compute forward and reverse capacities for lines based on directional columns or aggregated by node pairs. - Updated complex_clearing.py to utilize precomputed directional capacities in market clearing constraints. - Enhanced market clearing optimization to accept directional capacities as an argument. - Added example scenario to showcase and test directional constraint functionality.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #812 +/- ##
==========================================
- Coverage 80.51% 80.18% -0.33%
==========================================
Files 56 56
Lines 9056 9118 +62
==========================================
+ Hits 7291 7311 +20
- Misses 1765 1807 +42
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
55a7565 to
fd836b9
Compare
gugrimm
left a comment
gugrimm
left a comment
There was a problem hiding this comment.
Thank you for this useful initiative! I don't have any fundamental objection. The development also does not block the time dependent s_max_pu (dynamic line rating) that we would potentially like to introduce in future. But I have three comments:
- I think
s_max_pushould also apply to the directional limits - the aggregation function (sum) is only correct in a transport model, not in a PF. So I would like to be sure users do not mis-use or mis-interpret the function as a way of clustering /simplyfying networks. Which is what I could think it is, if I hear "aggregation".
- tests are missing
| return incidence_matrix | ||
|
|
||
|
|
||
| def aggregate_line_capacities( |
There was a problem hiding this comment.
I have a small problem with the name of this function. It sums the capacities. This addition is only valid if we consider a transport model, not if we consider a powerflow. The function is intended to be used within the complex clearing, which uses a transport model and which is therefore ok. But I would appreciate a way to rename this function in a way that makes clear that it is not intended to be used for aggregation of lines for an PF. What about "sum_line_capacities"?
| directional_capacities is not None | ||
| and line in directional_capacities.index | ||
| ): | ||
| cap_forward = directional_capacities.at[line, "cap_forward"] |
There was a problem hiding this comment.
for consistency I would multiply by s_max_pu here too. s_max_pu defaults to 1. But if people explicitly use it (e.g. setting to 0.7 to approximate n-1 security or setting to high values to mimic unconstrained networks without needing to adjust s_nom), it should not only apply to non-directional capacities but also to directional ones.
| and line in directional_capacities.index | ||
| ): | ||
| cap_forward = directional_capacities.at[line, "cap_forward"] | ||
| cap_reverse = directional_capacities.at[line, "cap_reverse"] |
There was a problem hiding this comment.
same here: multiply by s_max_pu
|
|
||
| -NTC_{l} \leq F_{l, t} \leq NTC_{l} \quad \forall \: l \in \mathcal{L}, t \in \mathcal{T} | ||
|
|
||
| If ``lines.csv`` additionally provides ``s_nom_forward`` and/or ``s_nom_reverse``, the complex clearing uses these directional limits instead. This allows transport constraints to differ by flow direction, which is useful for zonal representations with asymmetric commercial transfer capacities. |
There was a problem hiding this comment.
add sth like: s_max_pu is still applied.
|
|
||
| **New Features:** | ||
| - **Generic Forecasting Interface**: This interface enables to specify different forecast algorithms for preprocess, initialization and update during runtime. They can be specified in the config.yaml or unit csv files. For more information about currently implemented algorithms and how to specify them please read the documentation on Unit forecasts. | ||
| - **Directional transfer capacities in complex clearing**: ``complex_clearing`` can now use asymmetric line limits from ``s_nom_forward`` and ``s_nom_reverse`` instead of assuming the same transfer capacity in both directions. |
There was a problem hiding this comment.
add sth like: s_max_pu is still applied.
|
I added some tests with support by LLM. Could you have a look? |
3 participants
Description
This PR adds directional transfer-capacity support to
complex_clearing.Previously, transfer limits were treated symmetrically. This change allows users to specify different forward and reverse capacities and applies those asymmetric limits during complex market clearing. This is useful for zonal studies where commercial transfer limits differ by direction.
If directional capacity columns are not provided, the existing symmetric-capacity behaviour is retained.
Changes in this PR:
complex_clearingChecklist
docfolder updates etc.)Additional Notes (optional)