Tap module not reported correctly

[miek770]

Hi Santiago,

I created a new test (see here) to demonstrate a bug I noticed about the tap modules. In this test, transformer X_C3's module is set to 0.975, as shown in the test_xfo_static_tap_3.py file and the generated test_xfo_static_tap_3_grid.xlsx.

In the test results, however, the tap module is reported as being 1.0, as shown in the generated test_xfo_static_tap_3_results.xlsx.

I did several other tests on my side to try and solve this, and noticed that you only update the computed numerical circuit's tap modules for those which are tied to a voltage regulator (in PowerFlowDriver, there other are np.ones()'ed). I tried to correct it in this branch, but it doesn't work yet and I'm not sure that's how you'd want it to be done.

So do you think it's a good idea to copy static tap modules to the PowerFlowResults, so that they can be reported accurately?

If not, I would rather leave those tap_modules empty in the report (in single_power_flow) if they are static, instead of setting them to 1, to avoid any confusion. For a complete report, the user needs to consult both outputs of grid.save_excel() and grid.export_pf() anyways.

Whatever the solution, we need to be able to know the final tap (and/or module) of the transformers with a voltage regulator after a simulation, so the PowerFlowResults must at least include this information.

Thank you,

Michel

[SanPen]

Hi Michel,

Indeed, the tap module was missing from the power flow initialization. Hopefully that is corrected.

I copied your test test_xfo_static_tap_3.py and with the corrections I see the following:

if the taps control is active: The test fail because the tap is corrected from 0.975 to 1.0. If the taps control is deactivated the test pass.

Let me know if there's anything wrong.

[miek770]

Hi Santiago,

As mentioned in #40, it shouldn't reset the non-regulated taps to 1.0 just because options.control_taps is True. I believe the proposed PR fixes it all.

Thanks.

P.S.: Thank you for mentioning me in the copyright, it means a lot.

[SanPen]

Indeed there was a problem. When the branch is initialized, the tap changer position is inferred from the tap module (should be the other way around but the data available is usually the tap module...)

This happens in the branch constructor:

# Tap module
if tap != 0:
    self.tap_module = tap
    self.tap_changer.set_tap(self.tap_module)
else:
    self.tap_module = self.tap_changer.get_tap()

There was a bug in the set_tap function that is hopefully corrected. There was another bug in the calculation of which branches had to be controlled, that is solved too.

But, your test will not pass because the tap is set to 0.975 and the default tap changer is like so:

So 0.975 is approximated to the closest tap which is 0.98 in position -1. The solution is to configure the branch tap changer to have more steps.

I modified the test in my branch to include a more precise tap changer in that branch and pass the test.

[miek770]

Indeed I apparently forgot to edit the tap changer in the test, it should've been +/- 5% with 5 steps (standard offload tap changer in North America). But the modifications you pushed don't address the fact that the results.xlsx still show a 1.0 tap module. I would recommend having another look at #40 to resolve this. The new test generates a grid.xlsx and a results.xlsx so that we can compare both and confirm that the taps are reported accurately.

Edit: I ran some tests and the program doesn't prevent you from setting an impossible tap module. If you set it to 0.975, it will still simulate and report (in PR #40) it at 0.975, even if it's not a possible position as defined in tap_changer. I'd say that's kind of ok; if we're dealing with static (offload) taps it doesn't really matter if the tap positions are not well defined as long as the module is. It only really matters for onload taps linked to a voltage regulator (unless you change offload taps in special studies).

[SanPen]

The tap design is one of those things I'd do differently if I'd start again today. As I said, If I split the branch in the actual device models (line, cable., Transformer, etc...) there would be no tap module as input parameter but rather the tap position. It is there because of the massive PSS/e influence on open source tools like matpower and others.

I merged the pull request, and I am not sure if I need to do anything else since the test passes. If so please tell me.

[miek770]

Thank you, I will run further tests when I get a chance. I agree with you for the branch model, it would be a nice item on the long term roadmap.

Gridcal absolutely rocks though, I'm using it to find optimal grid configurations (taps and voltage setpoints) to minimize real power losses with genetic algorithm and it works great. That's why I was especially interested in the taps and voltage regulation improvements. It finds pretty good solutions after a few hundred thousand simulations :)

[miek770]

Simply confirming that it all looks good, closing the issue. Thanks.