New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unbalanced calculations / zero sequence models #96

Open
lthurner opened this Issue Apr 10, 2018 · 78 comments

Comments

4 participants
@lthurner
Collaborator

lthurner commented Apr 10, 2018

@xiaolu1990 has been working on integrating single phase short-circuit (ground fault) calculation into the pandapower short-circuit module. They require a zero sequence model for calculation according to IEC 60909. This is done by building a seperate ppc, which includes the zero sequence model with the new _pd2ppc_zero function. The ppc0 can then be used to evalute the zero sequence nodal point admittance matrix Ybus0. This matrix is then used to calculate the short-circuit impedances. The zero sequence model now supports external grids, lines and transformers of all common vector groups except Z-connected transformers. The results are validated against PowerFactory and also with the example from IEC60909.

The definition of the zero sequence values requires additional parameters for lines and transformers. The additional values are:

For ext_grids:

  • s_sc_mva
  • rx
  • r0x0
  • x0x1

For lines:

  • r0_ohm_per_km
  • x0_ohm_per_km
  • c0_nf_per_km

For transformers:

  • vsc0_percent
  • vscr0_percent
  • mag0_percent
  • mag0_rx
  • si0_hv_partial
  • vector_group

There is also a function that adds these parameters from the standard type library, assuming the values are defined in the standard type data. An example of how a grid can be defined with all relevant parameters can be found in the test.

The definition of unbalanced parameters and a zero sequence grid model opens up the possibility to not only calculate single phase short-circuits, but also unbalanced power flow calculations. This is what we want to implement next. For that, we will need to:

  • provide the data structure to define 3-phase loads and static generators
  • develop and validate the zero sequence models that exist for the short-circuit case for the power flow case
  • implement a three-phase power flow algorithm
  • define three-phase result tables and write a function that reads the three-phase results

For the three-phase power flow algorithm, @shankhoghosh has been working on identifying an appropriate algorithm and starting to make a test implementation outside of pandapower to see if we can get it to work. The algorithm we are looking to implement is the "Improved Three-Phase Power-Flow Methods Using Sequence Components" presented by Abdel-Akher et. al. A draft of the current plan for the three-phase power flow can be seen here (this is just a draft and can still change) See updated version below.
Everything in green already exists, yellow exists in a preliminary version or is being worked on and red is still ToDo. The idea is to first get the algorithm working outside of pandapower, and then to start the integration into the pandapower data structure.

Help is appreciated! If anyone is interested in contributing, please let me know here or directly at leon.thurner@uni-kassel.de.

@lthurner

This comment has been minimized.

Collaborator

lthurner commented Apr 23, 2018

There is now a first implementation of the unbalanced power flow that converges and gives correct results for a 2-bus system. There are some issues still to be figured out with regard to the base values, but the basic algorithm seems to work. I have updated the flow chart modeling how the implementation now looks like.

@shankhoghosh: next step is to clean the code up a little bit and push a first version to a seperate develop branch

lthurner pushed a commit that referenced this issue Apr 23, 2018

Comparison between pandapower and powerFactory. Also changed c facto…
…r as 1.1 in powerFactory and to 3.3 in pandapower #96

lthurner pushed a commit that referenced this issue Apr 24, 2018

build_bus use newly added mode pf_3ph to convert line-line rated bus…
… voltage to line-ground voltage which will be used for positive sequence power flow. build_gen.py was also impacted by new mode addition #96
@lthurner

This comment has been minimized.

Collaborator

lthurner commented Apr 24, 2018

ToDos:

Input parameters:

  • define load3ph and sgen3ph as part of the pandapower datastructure and implement create functions
  • write a function that extracts Sabc from load3ph, sgen3ph and the symmetric load from ppc1
  • should we use the maximum parameters from the short-circuit calculation (e.g. s_sc_max_mva) or introduce new parameters (e.g. s_sc_mva)?

Unbalanced modeling:

  • check ext_grid modeling - why do we need the "mystery factor" 3 for the ext_grid impedance?
  • test grids with transformers (different vector groups)
  • test grids with shunts

3phase Algorithm:

  • generalize it so it works for n-bus systems
  • use add_option functions to add ppc/power flow options
  • keep Ybus matrices as sparse matrices, and instead of inverting them use spsolve for the current iteration
  • get pq_bus/sl_bus from pandapower.pf.bustypes function
  • implement max_iteration counter
  • implement new runpp3ph function

Reading results:

  • write a function that writes voltages back to pandapower
  • Why do we need to remove negative/zero sequence admittances for the power calculation? Is this correct?
  • write a function that calculates branch currents and line / trafo loading and writes them back to pandapower
  • check against other software than PowerFactory
@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented Apr 24, 2018

  • Also, this 3 phase algorithm used positive values for Generation and Negative Values for Loads, whereas pandapower convention is opposite to that. Need to verify with pandapower convention as well
@lthurner

This comment has been minimized.

Collaborator

lthurner commented Apr 24, 2018

This is because pypower uses generation base signing system (because it was developed for transmission systems) and pandapower uses load based signing system (because it was developed for distribution systems). So it should stay that way pandapower counts loads as positive, and internally the signage is reversed.

lthurner pushed a commit that referenced this issue Apr 25, 2018

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented Apr 27, 2018

  • 47 Pandapower tests are failing due to non-parameterised values in different toolbox, file io and network functions. The addition of elements 'sgen_3ph' and 'load_3ph' is the cause. Looked for these and added where it was missing. Still getting some errors.
    Its a work in progress.
@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented May 2, 2018

The Power Factory Load Type was not selected for one of the loads which was the reason for difference.
Now, the Power Flow is working for 4 bus system as well.

@lthurner

This comment has been minimized.

Collaborator

lthurner commented May 2, 2018

Very good! Please avoid duplicate code such as in 4_bus_Unbalanced_values and pandapower/runpf_3ph.py and seperate the algorithm from the test cases. The test cases should be in pandapower/test/loadflow (or make a new folder for loadflow3ph).

@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented May 3, 2018

Following Leon's suggestion via email, I would like to contribute on the calculation of detailed results for 3ph currents, powers and loads of lines and transformers. Is there anything I need to consider with regard to the other ongoing developments?

Alex

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented May 3, 2018

Hi all,

I have been working on output of three phase power flow.
After looking at the existing construct, I think we can add a results_3ph.py file which will have similar functions like get_branch_results_3ph, get_bus_results_3ph, etc.
The catch is, whether we would like to get output in phase components or sequence components or both.

Doesn't make sense to take both. Since we have functions to transform from phase to sequence components . I suggest taking output in phase components only.

First we need to edit create.py for additional "empty_res_*" elements. Then corresponding elements need to be added in results.py under "reset_results()" function.

Then, results_3ph needs to be called from runpp_3ph.

Alex , I think it would be better if you can look at this from now on. I will look into the modelling of elements like transformers etc. Let us know if something needs clarification.

@lthurner

This comment has been minimized.

Collaborator

lthurner commented May 3, 2018

There are two problems involved when writing results to pandapower. The first is mapping the results between the internal and the external datastructure. There are actually three datastructures:

  1. pandapower tables (element based model)
  2. "external" ppc matrix (bus-branch model)
  3. "internal" ppc matrix (bus-branch model)

The external ppc contains all elements including out of service elements, the internal ppc contains only power flow relevant elements. We have previously tried to get rid of this intermediate step, but for several reasons it is not practical. For example the connectivity check searches for disconnected areas based on the external ppc, then sets all elements that are disconnected out of services and they are removed when the model is translated to the internal ppc. If there was no intermediate step, the connectivity check would have to be carried out on the pandapower table structure, which is not as performant. There are also some more reasons why it is difficult to get rid of this extra step.

So all results are calculated in 3., but they have to be mapped back to 1. Alex: I suggest starting with mapping voltage results, which are a already available as a direct result of the power flow, back to the pandapower tables. This should work in the same way is works for the symmetric powerflow, so you can check the implementation in the existing result functions to get an idea how it works, as Shankho suggested.

The second problem is to calculate other "advanced" results like branch currents and element loadings. These functions do net yet exist in three-phase / sequence components, so they have to be implemented. The results then also have to be mapped correctly back to the pandas data structure.

#edit: there is also a short tutorial explaining the internal / external datastructures a little bit.

lthurner pushed a commit that referenced this issue May 4, 2018

@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented May 4, 2018

Alright, I will start with Leon's last suggestion of mapping the voltages. Thanks for the tutorial!
@lthurner May I kindly ask for write access to the repository?

TheUninvitedGuest added a commit that referenced this issue May 7, 2018

shankhoghosh added a commit that referenced this issue May 9, 2018

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented May 9, 2018

For load mapping there was a bug where the bus id were getting summed up too with sum_by_group method. This made summation not possible for phase b and c. So seperated the bus ids in sum_by_group to facilitate summing up of load/sgen values for all 3 phases.

While testing for in service flag, found out something.
There needs to be a limit for the kind of load that we can add.
eg. In power factory when I add a P=70MW Q=70 MVA to the 2 bus network, its giving an error.
I think its reaching a limit, which may not be no. of iterations since it varied before giving error. Need to figure it out.

In our algorithm I am getting wierd result. which made me look into it.
Changes I made yesterday :
Auxiliary funtions were moved to runpp_3ph,
Removed OPF parameters from create.py and included in_service and scaling factor in load_mapping() in runpp_3ph.py

shankhoghosh added a commit that referenced this issue May 15, 2018

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented May 15, 2018

The user will have the ability to change options while calling runpp_3ph

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented May 18, 2018

Hi Alex,

Just wondering about the result functions. it would require base values in matrix/array form as well with bus mapping, as buses would have different base voltages for a network with transformers.
This needs to be multiplied with V012 found from the runpp_3ph algorithm, which are in pu, before it can be displayed as result.
Please keep this in mind when you implement the result functions

Thanks,
Shankho

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented May 24, 2018

Hi All,

The vector groups (YNd , Dyn, etc.) are not implemented in positive and negative sequence transformer model, which needs to be developed for three phase load flow. It has been developed for zero sequence model.
But for zero sequence model, phase shift angle needs to be taken care of.

Please correct me if I missed something.

Thanks,
Shankho

Edit : Vector groups not required in positive sequence networks, hence not implemented. but in the paper there are two cases, YNd and Yd where Ybus is formed with Yft and Ytf with an angle 30 deg.

@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented May 24, 2018

Hi @shankhoghosh, thanks for the pointers! I'll turn to the result functions in the coming workdays.

@lthurner

This comment has been minimized.

Collaborator

lthurner commented May 25, 2018

@shankhoghosh The only part of the vector group that is relevant in positive sequence is the phase shift. That is why there was no vector group parameter in pandapower before, but only the parameter net.trafo.shift_degree. So a transformer of vector group Yd5 would be modeled by simply setting shift_degree=5*3=150, because the Yd part doesn't matter for positive sequence. It does matter though for zero sequence, which is why the vector group was introduced as a transformer parameter for earth faults. The vector group parameter in pandapower does not contain the phase shift however, because that is already defined in shift_degree. So the pd2ppc_zero just needs to take the shift_degree parameter into account, as the pd2ppc function already does. Note that angle shifts over transformers might be ignored by default in the symmetric power flow depending on the voltage level, they are only considered with calculate_voltage_angles=True,

Did you already check an example without phase shift, for example using a vector group such as Yy0? I would suggest starting with these vector groups, and only if they work (validation against PowerFactory) move on to phase shifting transformers.

#edit: another parameter which is probably not yet properly modeled in zero sequence is the tap changer, because the tap changer setting is not considered in short-circuit calculations according to IEC 60909

@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented May 28, 2018

@lthurner @shankhoghosh I have a questions with regard to the implementation of the 3-phase elements. A colleague and I where discussion why is there a differentiation between 1ph and 3ph elements in the first place, maybe you can kindly help us with the reasoning behind it?
Maintaining element pairs that share most functionality seems a bit tedious and error prone. If the elements had flags indicating whether they are 1ph or 3ph instead, wouldn't that simplify the problem? Or did we miss something?

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented May 28, 2018

@TheUninvitedGuest
Hi Alex

The elements you mention are I think just load_3ph and sgen_3ph. These are three phase loads or sgens where power values can be entered for all the three phases.

Right now, the existing elements load and sgen are not single phase, they are balanced loads,
For e.g if a balanced load is entered as 60 MVA. It is actually 20 MVA each, in phases A,B and C.
But, the load flow is performed only for positive sequence network with entire 60MVA as power demand. This is because no power flows through negative or zero sequence networks in balance load flow.

So, with existing ppc model and MATPOWER structure, we cannot accomodate three phase elements.
The function load mapping() maps loads with buses and forms Sabc matrix. With flat start as intial condition for Vabc , Iabc = Sabc/Vabc. This Iabc is converted to sequence components.

For three phase load flow, we are using newton raphson method for positive sequence and current injection method for zero and negative sequence.
This is iterated untill I1 (Sabc/Vabc) becomes nearly equal to Y1V1.

In result, we just get sequence component V012 and Ybus. We can use these to find I012 , Iabc and then Sabc.

FYI : There is a lookup created between pandapower datastructure and ppc .
pd2ppc lookups.

So , say you have two buses with indices 1 and 5 in pandapower data structure.
But,the ppc will have continuous numbering , so the buses will be numbered 0 and 1.
pd [ 1, 5]
ppc [0,1]
pd2ppc lookup would look something like:
[ -1 0 -1 -1 -1 1 ]
so the pd2ppc[1] would be 0 and pd2ppc[5] would be 1
I hope this helps.

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented May 28, 2018

@TheUninvitedGuest You may use ppc to store zero, positive and negative sequence voltage and current values. You can calculate powers in phase frame (Sabc) and do some kind of reverse mapping to put these values in result elements in pandapower data structure. I think this reverse mapping would be somewhere in results.py or powerflow.py.

@lthurner

This comment has been minimized.

Collaborator

lthurner commented May 29, 2018

@TheUninvitedGuest As Shankho already said correctly, the only additional elements we introduced are load3ph and sgen3ph, so I am not sure what you mean with "Maintaining element pairs that share most functionality"? Lines, transformers and external grids are not duplicated, the same elements are used as for the balanced power flow and the unbalanced power flow. Only more parameters are needed in the unbalanced case which have to be added when an unbalanced power flow is carried out (e.g. vector_group for transformers, r0_ohm_per_km for lines etc.). These additional parameters are then used to model the zero and negative sequence models for the elements, which are needed for the unbalanced power flow.

In case of loads/sgen, if we wanted to avoid creating specific three-phase elements, we would have to introduce something like a new column "phase" which is "None" for balanced or "a"/"b"/"c" for single-phase loads. We briefly discussed something like this, but there are several reasons we didn't feel this is a good idea:

  1. In pandapower, the convention is that we explicitely seperate the different kinds of bus-elements, such load, sgen or storage and don't have one "pq-element" that can be used to model loads, static generators or storage unit, even if in the end it all comes down to a PQ-value. The reason is that explicit is better than implicit: if you want to model a static generator, you should create a static generator, and not a load with negative power (even though mathematically it is the same thing). The same applies to loads: if you want to create an unbalanced load you should create an unbalanced load element, and not a regular load with a special flag that signals that it is an unbalanced load.
  2. If you want to model a load with different power values in each phase (e.g. a household with different phase powers), you would have to create three seperate load elements, one for each phase. It is not explicitely clear that these three loads belong together. So if you for example want to set this household out of service, or analyse the degree of unbalance in the household, you would first have to do a groupby over the buses to check which elements belong together. As it is now, one household can be modeled as one element with different power values in the load3ph table, which is much clearer and more explicit.
  3. Even in symmetric power flow, you would have to do a pandas check for the phase column, while right now you can just assume the whole column are balanced loads. This could be a performance issue and more importantly a potential source of error in the balanced power flow.
  4. Having an additional table for load3ph isn't really error prone, because there is no model behind loads except summing them up and writing the values in the correct place.

I am not sure if thats really what you are talking about (in fact I think it probably wasn't), but we already had this discussion and never wrote it down anywhere, so I thought this would be a good occasion to document this design choice for future reference...

@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented May 29, 2018

Good morning @shankhoghosh @lthurner , thanks a lot for your quick and extensive replies! You are right @lthurner , I was talking about something slightly different but used sloppy wording. By 1ph meant the balanced, single line implementation as it exists right now. In any case, my questions were fully answered!

@shankhoghosh I did the tutorial on the conversion between pd and ppc tables, but your comment is a good reminder. Regarding the solvers, why are there different solvers used for positive and negative/zero sequence calculations?

As for now, I see that the required result element elements in create.py have been added, so I'll turn to the function for writing back the voltage results.

@lthurner

This comment has been minimized.

Collaborator

lthurner commented Jul 26, 2018

My bad, this is exactly what I'm doing, but only after starting to work on the transformers.

I see, then feel free to revert my changes.

However, with asymmetric loads the line and transformer currents don't exactly match (in a single line setup with 3 buses, line connected to the lv side). The deviations are small, but I believe not of numeric (solver) origin. Try to find out what's going on before pushing.

It could be this code here:

ref, pv, pq = bustypes(ppci0["bus"], ppci0["gen"])
ppci0["bus"][ref, GS] = 0
ppci0["bus"][ref, BS] = 0
# Y0_pu = Y0_pu.todense()
Y0_pu, Y0_f, Y0_t = makeYbus(ppci0["baseMVA"], ppci0["bus"], ppci0["branch"])

For some reason, the zero sequence slack impedance is ignored when calculating the power flows. But instead of removing the slack impedance specifically, GS and BS are set to zero completely. So any shunt impedance at the slack from a transformer or line would also be removed. Maybe the results match more closely if only the slack impedance is removed (for example by calling pd2ppc again without adding the slack impedance?)?

@lthurner

This comment has been minimized.

Collaborator

lthurner commented Jul 27, 2018

Small correction:

So any shunt impedance at the slack from a transformer or line would also be removed.

Line impedances are defined seperately in the branch and not affected by this. But transformer shunt impedances are defined directly in the bus matrix, for example here:

if vector_group == "Dyn":
buses_all = np.hstack([buses_all, lv_buses_ppc])
gs_all = np.hstack([gs_all, y0_k.real * in_service * int(ppc["baseMVA"])])
bs_all = np.hstack([bs_all, y0_k.imag * in_service * int(ppc["baseMVA"])])

If a transformer is directly connected at the slack, it could have a shunt impedance at this bus depending on the vector group

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented Jul 27, 2018

Hi @TheUninvitedGuest

the external grid results are kept in two result data frames.
The active powers in res_ext_grid_3ph and reactive powers in res_ext_grid.
Was there some problem?

@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented Jul 27, 2018

@shankhoghosh Nope, just a mistake. I'll push the fix any minute when the tests are finished!

TheUninvitedGuest added a commit that referenced this issue Jul 27, 2018

@lthurner

This comment has been minimized.

Collaborator

lthurner commented Jul 27, 2018

We also have to adress the naming of variables and parameters. The variables in load_3ph are called p_kw_A, p_kw_B, etc. and bus voltages in res_bus_3ph are called vmA_pu, vmB_pu etc. So we need a uniform nomenclature how the sequence is noted. p_kw_A contradicts the rule that all parameters should end with their unit, so pA_kw would be better imho. But even though we never had a specific rule about that, I don't think we have any other parameter that includes capitalized letters. So the most consistent naming would probably be pa_kw or p_a_kw?

Also with the result table there is the following problem:

  • line --> res_line_3ph
  • load --> res_load_3ph
  • load_3ph --> res_load_3ph_3ph??
@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented Jul 27, 2018

We also have to adress the naming of variables and parameters.

I agree that refactoring should be done once we have the basic functionality covered (hopefully today?). Also, there are many occurrences when bare numbers are used for indexing instead of the corresponding constants defined in idx_*.py.

Also with the result table there is the following problem: [...]

I don't see that in my result tables at all, there are separate tables for balanced and 3ph components. Can you give me pointer?

@lthurner

This comment has been minimized.

Collaborator

lthurner commented Jul 27, 2018

I don't see that in my result tables at all, there are separate tables for balanced and 3ph components. Can you give me pointer?

What I mean is: the naming convention for balanced results is res_'element', i.e. line --> res_line. The naming convention for unbalanced results is res_'element'_3ph, i.e. line --> res_line_3ph (we haven't explicitely discussed this convention, but that is the way it is right now).

But there is also a load_3ph element, so if we apply this naming convention consistently it would have to be res_load_3ph_3ph, right?

@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented Jul 27, 2018

Ah right, missed the fact that it's still about refactoring. :) Yes, indeed you've got a point there! Not pretty. I was in fact discussing something related with a colleague the other day and we wondered, whether unifying balanced/3ph components wouldn't be the way to go in the long run. It would solve this issue at hand, and from the user API perspective nothing would necessarily have to change for the balanced case.

@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented Jul 27, 2018

If a transformer is directly connected at the slack, it could have a shunt impedance at this bus depending on the vector group

Added another line between the slack and the transformer to rule out this situation, but the problem persists.

Maybe the results match more closely if only the slack impedance is removed (for example by calling pd2ppc again without adding the slack impedance?)?

Tried out some possibilities following this suggestion without success. Shall I push my current working state but omit the corresponding test for now?

@lthurner

This comment has been minimized.

Collaborator

lthurner commented Jul 27, 2018

I was in fact discussing something related with a colleague the other day and we wondered, whether unifying balanced/3ph components wouldn't be the way to go in the long run. It would solve this issue at hand, and from the user API perspective nothing would necessarily have to change for the balanced case.

You mean not having load_3ph/sgens_3ph and instead integrating that functionality in load/sgen? I already outlined why I don't think thats the best choice here. I would prefer renaming load_3ph into unbalanced_load or phase_load or something similar, and reserve the _3ph as an identifier for the result tables.

Tried out some possibilities following this suggestion without success. Shall I push my current working state but omit the corresponding test for now?

Yes better to have the working state before developments diverge too much, even if it is not perfect yet.

TheUninvitedGuest added a commit that referenced this issue Jul 27, 2018

Implemented 3ph trafo result tables. #96
Actual results not entirely correct yet, cause lies probably
in the zero impedance of the external grid.
@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented Jul 27, 2018

I already outlined why I don't think thats the best choice here.

After becoming much more familiar with the code in the meanwhile, I see your points now! Let's go with one of your naming suggestions (I personally prefer phase_). That also makes it easier to interpret the results when, e.g., running a balanced load flow on a network with phase elements (phase powers could simply be summed up in this case).

Yes better to have the working state before developments diverge too much, even if it is not perfect yet.

Pushed my latest changes.

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented Jul 30, 2018

I am working on doing a connectivity check for zero sequence network as well. In this way it will calculate Y bus like there is no branch . This will require zero sequence voltage vector to be same dimension as Ybus. This would be different from positive sequence for some vector groups.

Eg. number of buses = 2 for positive sequence and number of buses=1 for zero sequence
I am leaving V0 = 0 as default and changing V0 [ : nb0 , :] in each iteration.

Will let you know how it turns up

@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented Jul 30, 2018

  1. For vector groups like Yy , Yd, Dy, Dd , where there is no branch impedances, The removal of Ext grid impedance leads to all zero values in zero sequence networks, so there will be no elements in Y0 : which is the error I am getting.

I am making GS and BS equal to trafo gs and bs , if there is transformer.

  1. The values are still not matching for other vector groups, except YNyn vector group for a simple two bus network with just a transformer.
@shankhoghosh

This comment has been minimized.

Collaborator

shankhoghosh commented Jul 31, 2018

The problem can be identified as "zero sequence blocking" when a bus gets isolated for zero sequence models of some transformer vector groups .

So , when there are no values of impedance in Y bus :
eg.
1 0
0 0
The matrix becomes singular matrix, and it can not be inverted.
This is the reason makeYbus removes the zero values by default. and makes a non-square matrix for zero sequence, because we are skipping the connectivity check for ppc 0

In balanced load flow , connectivity check is done to remove an isolated in-service bus and the matrix formed is a square matrix.

In our algorithm, we are using ABC to 012 conversions and the number of buses become different for positive and zero sequences, because of "zero sequence blocking".

I am assuming two things here:
1: Zero sequence voltage is zero by default and only the connected buses values change, in each iteration.
2: I am neglecting vector groups with no branch impedance(Yy , Dd, Yd, Dy), as they form Ybus matrix with all zero values.

Perhaps , we can ask the author about these specific questions as well.

  1. He has mentioned converting phase model of the transformer to sequence model of the transformer. But this part is not very clear, if we only have sequence frame values of the transformer.
@lthurner

This comment has been minimized.

Collaborator

lthurner commented Jul 31, 2018

This all sounds very logical and this:

1: Zero sequence voltage is zero by default and only the connected buses values change, in each iteration.

seems like a good idea.

What I don't understand is: how can we have test networks that work for all vector groups with single phase short-circuit? We invert the Ybus matrix in the negative sequence to calculate the short-circuit current. Following your explanation (which sounds logical), this should not be possible for zero-sequence blocking transformers. But it does work and give correct results, at least for the tested grids?

P.S.:

  1. I am neglecting vector groups with no branch impedance(Yy , Dd, Yd, Dy), as they form Ybus matrix with all zero values.

Shouldn't there still be the ext_grid impedance?

@xiaolu1990

This comment has been minimized.

Contributor

xiaolu1990 commented Jul 31, 2018

What I don't understand is: how can we have test networks that work for all vector groups with single phase short-circuit?

I think this is because the elements connected to the LV side of transformers in the test network also contributes to the zero-sequence admittance at the LV bus, because the connection of the sequence network is determined by the fault location. This makes the Ybus matrix to be square again. While in a 2-bus-network the admittance at the LV bus is assumed to be 0.

@lthurner

This comment has been minimized.

Collaborator

lthurner commented Jul 31, 2018

OK that makes sense, thanks for the explanation.

I did check a power flow with zero-sequence-blocking in PowerFactory though, and the zero-sequence voltage values are not zero at the LV side of the transformer. So the theory that buses that are disconnected from the ext_grid in zero sequence just stay at 0 does not seem to be valid.

@TheUninvitedGuest

This comment has been minimized.

Collaborator

TheUninvitedGuest commented Aug 9, 2018

Any progress on the transformer issue?

shankhoghosh added a commit that referenced this issue Sep 6, 2018

TheUninvitedGuest added a commit that referenced this issue Oct 19, 2018

TheUninvitedGuest added a commit that referenced this issue Oct 19, 2018

shankhoghosh added a commit that referenced this issue Nov 13, 2018

shankhoghosh added a commit that referenced this issue Nov 15, 2018

shankhoghosh added a commit that referenced this issue Nov 26, 2018

shankhoghosh added a commit that referenced this issue Dec 10, 2018

shankhoghosh added a commit that referenced this issue Dec 13, 2018

shankhoghosh added a commit that referenced this issue Dec 13, 2018

shankhoghosh added a commit that referenced this issue Dec 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment