[FEATURE] Power flow calculation. Case of incorrectly specified transformer tap_regulator control_side

[WinApiMan]

Hi! When calculating the power flow, I encountered a situation where I incorrectly indicated the side of the transformer regulator. I Used PGM_tap_changing_strategy_fast_any_tap(4) tap charging power flow strategy. Validator returns a message

"Automatic tap changer has invalid configuration. The transformer is being controlled from non source side towards source side."

And if the model is large and has, for example, 50 transformers, I don’t know in which of the 50 the regulator is set incorrectly. Is it possible to display the ID of the incorrect regulator when displaying an error?

calculate_model.json

[mgovers]

Hi @WinApiMan,

Thank you for your feature request. I think this should be reasonably simple to add. There are 2 possible ways:

1. We can throw with an additional input argument set to the regulated_idx, which contains the mathematical indices, and then catch the error, load the actual ID and then rethrow with the regular ID in the message; or
2. We can add to the TrafoGraphEdge the actual transformer ID. While cleaner from the throw-perspective, it adds a bit more data to fairly low-level logic...

My gut-feeling says that the latter is the cleaner solution. @Jerry-Jinfeng-Guo @figueroa1395 @nitbharambe do you have any opinions?

After we've made a decision, we can probably add the good-first-issue label

[figueroa1395]

Hi @WinApiMan,

Thank you for your feature request. I think this should be reasonably simple to add. There are 2 possible ways:

1. We can throw with an additional input argument set to the regulated_idx, which contains the mathematical indices, and then catch the error, load the actual ID and then rethrow with the regular ID in the message; or
2. We can add to the TrafoGraphEdge the actual transformer ID. While cleaner from the throw-perspective, it adds a bit more data to fairly low-level logic...

My gut-feeling says that the latter is the cleaner solution. @Jerry-Jinfeng-Guo @figueroa1395 @nitbharambe do you have any opinions?

After we've made a decision, we can probably add the good-first-issue label

Mine says option 1 is very easy and straightforward, but perhaps we can leave it open in the issue. But indeed this seems like something relatively easy to pick up.

[WinApiMan]

@mgovers , If i have situation when model has 2 or more regulator with incorrect control side. Validator return 2 ID's or the first one found?

[figueroa1395]

@mgovers , If i have situation when model has 2 or more regulator with incorrect control side. Validator return 2 ID's or the first one found?

@WinApiMan In the way we currently have this implemented, it would crash on the first encounter of a regulator at the incorrect control side. That means it would only report one ID. If there are more wrongly located regulators, they will only be found with subsequent runs at the moment.

[mgovers]

@WinApiMan Can you maybe explain the extend of your use case? (radial vs meshed, complexity of the grids, how many regulated transformers, etc.)

If you are running radial networks, the feature mentioned here may provide useful input to fix the actual data error, but in the case of meshed networks, it may also complicate things.

Here's the reasoning behind that statement: This error type does not necessarily (it may or may not) indicate a data error but rather a limitation of the algorithm we use. It depends on the topology, and a switch action or status change in the regulators used in a calculation may change the effective source side of a regulated transformer in the case of meshed networks. The algorithm was implemented this way to deal with the combinatorial complexity of the problem. In particular, multiple regulators will be competing in regulating the same subsection of the grid. For radial grids, however, it is more likely to be an actual data error

See also https://power-grid-model.readthedocs.io/en/stable/user_manual/calculations.html#control-logic-for-power-flow-with-automatic-tap-changing for details.

[Jerry-Jinfeng-Guo]

The error message is a runtime error. We made the choice of a dedicated slim data structure (IDx2D free) for ranking transformers mainly out of performance considerations. The proposed changes would compromise that. Additionally, this won't help in cases where there are multiple such errors, like @WinApiMan pointed out. Therefore, I'd propose the following:

• Add this in the validator
• In the validation, perform shortest path finding from source and mark them at all regulated transformers
• Report all regulated transformers where the reg side is incorrect

This will not be the most performant solution, but it provides the most complete information without re-introducing the burden we worked hard to avoid in the first place. The run time error could be a hint to run the actual validator. Perhaps a small message for this should be appended.

Above is my feedback. @mgovers @figueroa1395 @nitbharambe

[figueroa1395]

@Jerry-Jinfeng-Guo I think it would be valuable to follow your recommendation about adding the check to the validation. However, I believe @WinApiMan (please correct me if I'm wrong) doesn't use the Python API , so that unfortunately wouldn't be an appropriate solution for him.

[WinApiMan]

@WinApiMan Can you maybe explain the extend of your use case? (radial vs meshed, complexity of the grids, how many regulated transformers, etc.)

If you are running radial networks, the feature mentioned here may provide useful input to fix the actual data error, but in the case of meshed networks, it may also complicate things.

Here's the reasoning behind that statement: This error type does not necessarily (it may or may not) indicate a data error but rather a limitation of the algorithm we use. It depends on the topology, and a switch action or status change in the regulators used in a calculation may change the effective source side of a regulated transformer in the case of meshed networks. The algorithm was implemented this way to deal with the combinatorial complexity of the problem. In particular, multiple regulators will be competing in regulating the same subsection of the grid. For radial grids, however, it is more likely to be an actual data error

See also https://power-grid-model.readthedocs.io/en/stable/user_manual/calculations.html#control-logic-for-power-flow-with-automatic-tap-changing for details.

Hi, @mgovers !At this stage, we are testing radial networks containing up to 160 transformers. When creating a model, a person can accidentally set the wrong control side of the regulator and then not be able to find where it is). I like the solution described by @Jerry-Jinfeng-Guo .

[WinApiMan]

@Jerry-Jinfeng-Guo I think it would be valuable to follow your recommendation about adding the check to the validation. However, I believe @WinApiMan (please correct me if I'm wrong) doesn't use the Python API , so that unfortunately wouldn't be an appropriate solution for him.

@figueroa1395 , Yes, you are right! We compile the library (dll on C)

[WinApiMan]

@figueroa1395, We have our own C-based validator, written on top of the Python validator (duplicated from Python to C). If you can add this check to the Python validator, we can try duplicating this code in our C-based version. In general, we will be satisfied with any of the validation options (one ID or all)

[mgovers]

hi @WinApiMan,

We have been talking about this and we decided the following:

1. In the short term, we can add the tap_regulator ID to the error message (this is the original feature request, cfr. see [FEATURE] Power flow calculation. Case of incorrectly specified transformer tap_regulator control_side #1263 (comment)). This should already unblock you. If you would like to implement this yourself, feel free to do so. A couple possible approaches are listed here, which one to use is up to the developer:
   1. We can throw with an additional input argument set to the regulated_idx, which contains the mathematical indices, and then catch the error, load the actual ID and then rethrow with the regular ID in the message; or
   2. We can add to the TrafoGraphEdge the actual transformer ID. While cleaner from the throw-perspective, it adds a bit more data to fairly low-level logic...
   3. Completely supercede the math idx with the regulator ID.
2. In the mid-longer term, we can add a feature in which we first accumulate all transformers that are closer to the source, and then output all of them at once in a similar error message.
3. In the long term, we can add it to the data validator, but that will still require some more design discussions
   As a completely unrelated topic, we've seen you being quite active recently and you've clearly built a nice application. Would you like to present it in our upcoming community meeting (or just join it out of interest; see also this announcement). You can subscribe to the meeting invite via: https://zoom-lfx.platform.linuxfoundation.org/meeting/91445523235?password=e565df23-7c6d-4d67-94e6-f5774cfd4745

[Jerry-Jinfeng-Guo]

Whether approach 1 or 2 is used is up to the developer

Correction. The discussion internally results in a different solution direction from 1 or 2 listed here.