build branches from trafo3w about pandapower HOT 11 CLOSED

Yes this is a good idea, please go ahead. Please also add one of these special cases to the test suite so this behaviour is tested for the future.

Maybe while we are looking into 3W transformers we can also adress switches at 3W transformers as discussed in #30

from pandapower.

There are some more issues within this issue that I mentioned when building branches from a 3winding trafo, which I noticed due to difference from branches parameters obtained using the current pandapower realease and the branches I got:

• when calculating magnetising admittance, sn_hv_kva is used, and I think min(sn_hv_kva, sn_mv_kva) should be used !? (if I am not terribly wrong?)
  

• in the current implementation, first vsc_percent and vscr_percent are transformed delta-to-wye and then r and x are calculated from them for each of 3 branches. The right order should be to first calculate x12, x23, x13 and than make wye-delta transformation. In other words, result is not the same if one first transforms z12, z23, z13 to z1, z2, z3 and then calculates x1, x2, x3...than if one first calculates x12, x23, x13 and then transforms them to x1, x2, x3

There are some less important things to be mentioned:

• documentation for the trafo3w should be updated in any case (there is no any mention of min(sn_hv_kva, sn_mv_kva))

• using shift_mv_degree and shift_mv_degree is not really clear to me? phase shift should be related to tap, so if there is one tap on a trafo3w, there should be only one phase_shift, then internally this tap should be calculated for each side? if I am not terribly wrong?

• by direct generation of branches from 3winding transformers, there is no need to define voltage level of the additional bus. All the values are calculated on the side of the additional bus, where we can assume base(nominal) voltage is equal to rated.

• why this: b_img[b_img < 0] = 0 here ?

from pandapower.

Hi Jakov,

thanks for taking the time for this implementation, I think it is very good to get a vectorized implementation of the 3 winding transformers. Apart from the incompatibility with certain values there is also the time factor, we recently had a network with several hundred 3w transformers where the 3w conversion took up about 2/3 of the power flow time. This should speed up things nicely.

when calculating magnetising admittance, sn_hv_kva is used, and I think min(sn_hv_kva, sn_mv_kva)should be used !? (if I am not terribly wrong?)

Where are these equations from? As far as I understand, all loss factors (like i0_percent for example) are in relation to the rated power of the whole transformer, which is sn_hv_kva. Using min(sn_hv_kva, sn_mv_kva) would mean always using sn_mv_kva, since sn_hv_kva>sn_mv_kva. Why should sn_mv_kva be the reference for the loss parameters?

in the current implementation, first vsc_percent and vscr_percent are transformed delta-to-wye and then r and x are calculated from them for each of 3 branches. The right order should be to first calculate x12, x23, x13 and than make wye-delta transformation. In other words, result is not the same if one first transforms z12, z23, z13 to z1, z2, z3 and then calculates x1, x2, x3...than if one first calculates x12, x23, x13 and then transforms them to x1, x2, x3

Why do you think this would be the right order, do you have a source for that?

using shift_mv_degree and shift_mv_degree is not really clear to me? phase shift should be related to tap, so if there is one tap on a trafo3w, there should be only one phase_shift, then internally this tap should be calculated for each side? if I am not terribly wrong?

The phase shift is not necessarily related to the tap changer, it is primarily related to the transformer vector group. The transformer can have a vector group so that the phase shifts of mv and lv side are different.

documentation for the trafo3w should be updated in any case (there is no any mention of min(sn_hv_kva, sn_mv_kva))

Yes should definetly updated, lets do it after the refactoring is done

by direct generation of branches from 3winding transformers, there is no need to define voltage level of the additional bus. All the values are calculated on the side of the additional bus, where we can assume base(nominal) voltage is equal to rated.

I don't quite understand what you mean... Don't you need to define a voltage level for the power flow to work? Or do you mean we don't need it because the values are always in per unit and therefore we just assume 1.0 pu as initial voltage?

why this: b_img[b_img < 0] = 0 here ?

The magnitude of the magnetizing impedance is defined by i0_percent, the real part of the magnetizing impedance is defined by pfe_kw. If you chose an i0_percent that is small, and an pfe_kw that is large, the imaginary part of the magnetizing impedance would become negative and the transformer would have and capacitive behaviour. In that case the imaginary part is set to zero rather than to model capacitive behaviour in a transformer. This might however be the correct behaviour in 3W transformers where the transformers are only equivalent transformers and might have parameters which are not physically logical.

In general, I think we should base our validation on commercial software, which is the only way to know if the model is correct. That is what I tried to do with the test here. The results in there are extracted from powerfactory, and the voltages match the results from pandapower with a tolerance of 1e-6. That should be the benchmark from my point of view, but we should also add new corner cases (e.g. the one that you experienced where an error occurs).

from pandapower.

Hi Leon,
here are some comments to your answers (your quotation is in italic):

when calculating magnetising admittance, sn_hv_kva is used, and I think min(sn_hv_kva, sn_mv_kva)should be used !? (if I am not terribly wrong?)

I've found that in some ABB's technical documentation, even in some university slides, but I cannot find proof for that it in some really relevant source. I would say even scheme from PowerFactory's technical reference (TechRef_3-W-Transformer.pdf) for a 3winding transformers shows that min(sn_hv_kva, sn_mv_kva) eventually makes sense:

but actually afterwards they explicitly say:
reference power in PowerFactory is equal to HV-side rated power
So we can believe to PowerFactory and use sn_hv_kva

result is not the same if one first transforms z12, z23, z13 to z1, z2, z3 and then calculates x1, x2, x3...than if one first calculates x12, x23, x13 and then transforms them to x1, x2, x3
Why do you think this would be the right order, do you have a source for that?

This can be shown mathematically (I will show example on x1):
so if you calculate first x12, x23 and x13 and then do wye-delta conversion to get x1 from x12, x23 and x13:

alternatively, if you first do wye-delta transformation on z and r, i.e. transform z12, z13 and z23 to z1, z2 and z3 and then calculate x1:

now if you compare first and second equation, and develop them you can see that:

the question remains: which method is correct?
I believe (I will try to find some relevant reference) the first because impedance should be considered in wye-delta conversion as a vector, not only amplitude (as considered in the second case)...so in the first case this equation holds:

The phase shift is not necessarily related to the tap changer, it is primarily related to the transformer vector group. The transformer can have a vector group so that the phase shifts of mv and lv side are different.

Oh, it is only now clear to me that by shift_degree you thought on transformer vector group and clock hour number, and not on a phase-shifting transformer. This is quite a different thing, so only now I also understand why calculate_voltage_angles defaults to False for transmission...
So for proper consideration of a phase-shifting transformer additional parameter (such as du in powerFactory) should be added?
hereafter is PowerFactory technical reference for 2w transformer to see what I mean about tap of a phase shifting transformer:
TechRef_2-W-Transformer_3Phase.pdf

there is no need to define voltage level of the additional bus.
Or do you mean we don't need it because the values are always in per unit and therefore we just assume 1.0 pu as initial voltage?

Exactly, that's what I meant...no reason which voltage level is assigned to auxiliary bus, since it is used only internally and its p.u. value will always be 1 p.u. :)

In general, I think we should base our validation on commercial software

I completely agree...I'll try to make the model to pass all the validation tests in regard to PowerFactory results...

from pandapower.

Hi Jakov,

looks like we agree in most aspects 👍 The question of wye-delta transformation is still open, but if you can investigate both approaches it would be interesting to compare the results.

So for proper consideration of a phase-shifting transformer additional parameter (such as du in powerFactory) should be added?

In the two winding transformer model there is a parameter "trafo.tp_st_degree" to model phase shifting transformer, but it has not been implemented for 3W transformers yet.

from pandapower.

I removed the code that is currently unused. For now I am closing this issue since nobody currently seems to be working on this and there also wasn't any test data supplied for a case where this problem occurrs. @jkrstulo if you want to continue working on this, feel free to reopen the issue and recover the code from this commit!

from pandapower.

I am not sure yet, but I might have to reopen this. Still doing some testing, but I get deviations for a testcase with a transformer under high load. What was the state of that code, was it usable so that I can test it?

from pandapower.

I think @jkrstulo is right, the right order should be to first calculate x12, x23, x13 and than make wye-delta transformation.

I change the calculation in https://github.com/lthurner/pandapower/blob/d4e0f0bdd3a927e8d48260ff468f6b880b880081/pandapower/build_branch.py#L446-L447

to first calculate the x12, x23, and x13, then do the wye-delta transform and in the end recalculate vsc_2w:

    vsci_2w_delta=np.sqrt( vsc_2w_delta ** 2 - vscr_2w_delta ** 2)
    vscr_2w = wye_delta(vscr_2w_delta, sn)
    vsci_2w = wye_delta(vsci_2w_delta, sn)
    vsc_2w = np.sign(vsci_2w) * np.sqrt(vsci_2w ** 2 + vscr_2w ** 2)

This reduces deviations in reactive power losses between pandapower and Integral drastically, while still passing all tests.

from pandapower.

Wow if it is that easy to change that would be very nice! I thought this would only possible by refactoring the function to directly calculate the branches as @jkrstulo planned to do (which would still be good for performance reasons).

from pandapower.

I was impressed as well, thought it would be much more complicated. I am still doing some testing though. I will post an update and create a pull request if I am convinced that it works for all our testcases.

Initially, I had hoped that this implementation would allow the PowerFactory testcase to pass with trafo3w_losses='star', but that is not the case. Just to be sure, do you know if that testcases was calculated with the default setting for the shunt element as discussed in #98?

from pandapower.

Yes I checked again, those are the values with the losses at the star point. Maybe we should increase the i0_percent and pfe_kw parameters in the test case to more clearly see the difference. But I suspect the differences to PowerFactory are more from the 3-pole vs. equivalent branch modeling than the open loop losses. So these differences we probably can't get rid of without also switching to a 3-pole implementation, but if the difference to other equivalent branch optimization is significantly smaller, that would already be great.

from pandapower.