[FEATURE] Decimal/fractional tap position for transformers

[bartgips]

Tap positions are integer numbers clamped between tap_min_ and tap_max_. The tap position is used to calculate the transformer ratio k using the equations here on line 159

These equations would work equally well if the tap position is a non-integer (e.g. a float).

At the moment it seems that the python wrappers do not complain (throw a warning or error) if the structured array input_data['transformers] contains floats for 'tap_pos', but they seem to be cast to integers by the C-code regardless.

So the feature request comes down to this:

Could both the 'tap_pos' field in the ndarray and the tap_pos_ attribute in the C-code be changed to floating point numbers, rather than signed integers?

[petersalemink95]

Hi @bartgips,

Thanks for your request. Out of curiosity: why do you want this feature? What would be the use case? :)

[bartgips]

Hi @petersalemink95,

We are running a project at Alliander where we want to estimate the correct tap positions (assuming that some of them are not registered correctly). We then use some pytorch code, together with PGM, to optimize these tap positions. This optimisation is much easier when tap positions are continuous (rather than discrete) variables.

Right now I work around it by altering the tap/step size, such that any non-integer tap position can still be represented. However, it would be more neat if pgm would directly accept a floating point number for tap position. So @TonyXiang8787 suggested I open this feature request for it :).

[petersalemink95]

Hi @bartgips,

Thanks for the explanation. Are you familiar with our recently released automatic tap changer algorithm? See https://power-grid-model.readthedocs.io/en/stable/examples/Transformer%20Examples.html#power-flow-calculations-with-automatic-tap-changing for an example. This can help you in finding the correct tap positions. Please let me know if this would help you or if this feature is still requested. Thanks!

If you need additional info about this algorithm let me know as well :)

[bartgips]

Thanks for the link @petersalemink95,

I will have a more detailed look. At the moment it seems to me the algorithm tries to find the most likely tap position? I.e. it changes the tap_pos value into a value that minimises the loss (maximises the likelihood)? Is this correct? If so, it is very similar to what we are doing, and we wrote a similar algorithm earlier in the year as part of our project at Alliander.

We are working on a Bayesian inference algorithm that can return a posterior distribution over the tap position parameters, which works better/easier with a continuous representation.

If this feature does not fit in the current plans for PGM, it is also not the end of the world. We can keep using our work-around by altering the step size rather than the tap position.

[petersalemink95]

Thanks for the link @petersalemink95,

I will have a more detailed look. At the moment it seems to me the algorithm tries to find the most likely tap position? I.e. it changes the tap_pos value into a value that minimises the loss (maximises the likelihood)? Is this correct? If so, it is very similar to what we are doing, and we wrote a similar algorithm earlier in the year as part of our project at Alliander.

We are working on a Bayesian inference algorithm that can return a posterior distribution over the tap position parameters, which works better/easier with a continuous representation.

If this feature does not fit in the current plans for PGM, it is also not the end of the world. We can keep using our work-around by altering the step size rather than the tap position.

Thanks for the reply! It does not try to minimize the loss. The algorithm finds the tap settings for which the voltage is within a specified bound (specified by user). This way tap settings are found that would match with regulations.

I will discuss the implications of your issue within the team and come back to you whether it would be possible to implement (technically and considering prioritization).

[TonyXiang8787]

@petersalemink95 this is a separate feature than the power flow with automatic tap changer.

[petersalemink95]

Hi @bartgips,

There is an open issue about a different way of modeling transformers, see #642. In the proposed solution, the transformer ratio k will be a float. We believe this will also be a solution for the feature you requested here.

Therefore, I will close this issue.