Wednesday, August 10, 2016

Loop analysis

The last three releases of the circuit simulator were primarily dealing with errors in the loop manipulation technique used by the circuit solver. A brief background is that loop analysis is the backbone of the circuit simulator. Nodal analysis is also used but that is used to determine conducting paths in a non-linear circuit and to determine the currents through stiff branches. But the bulk of the simulator is the loop analysis.

The loops can be divided into stiff loops and non-stiff loops. The non-stiff loops are solved as ODEs while the stiff loops are mere static equations. After any event in the circuit, it is necessary to ensure that the non-stiff equations fully represent the circuit. This means that the if the circuit is divided into two parts - non-stiff branches and stiff branches - the number of loops formed by the non-stiff branches with their associated nodes should be included in the loop analysis. A failure to do so will cause the simulator to break as the simulator in that case is not solving all the equations that represent the circuit.

The first error was it was assumed that two loops could be manipulated and the result need only be checked to ensure all nodes occur twice. This meant there would be no stray branches or multiple loops. This is not entirely true. It is possible that manipulating two loops could result in multiple completely disjointed loops that satisfy the condition that all nodes occur only twice. So it became necessary to trace out the loop from an origin node back to this node. If more than one loop was found, the loop manipulation was not valid.

The second error was in assuming that after two loops are manipulated there is no need to check the directions. It is always possible to have conflicts in the directions of branches with two loops that are being manipulated. For example, say loops L1 and L2 are being manipulated. There loops have a branch (say B1) common between them and the branch is in the same direction of loops L1 and L2. It is also possible that the loops have another branch (say B2) common but the direction of this branch may be the opposite in loops L1 and L2. So, with such loops, computing sum or difference of the loops is not totally straightforward and after performing the loop manipulations, it becomes necessary to check the directions of the branches in the resultant loop to make sure no branch direction is wrong.

The third error was in how the number of non-stiff loops are ensured. The number of non-stiff loops can be determined by counting the non-stiff loops and the number of nodes that they map and the loops will be equal to B-N+1. However, what was done so far was to manipulate the stiff loops and try to triangularize the stiff branches in the loop map. This technique would work in the first attempt for smaller circuits but as the circuits became bigger, this didn't work. One reason, it is not necessary that two stiff loops are compatible. Therefore, two stiff loops may have the same stiff branch but there is no way to eliminate this stiff branch from one of the loops because the result of their manipulation is not a genuine loop. In such circumstances, it is necessary to continue the loop manipulations even with non-stiff loops if necessary until the stiff branches have been eliminated from a sufficient number of stiff loops. This is now being implemented as a boot strap technique, the loop manipulations are continuously repeated until the number of non-stiff loops in the loop map meet the expectations.

At this stage, the bugs have been fixed for a three-phase inverter with LCL filter connected to the grid and behaving as a VAR compensator. However, it is still not completely certain that all bugs have been fixed as it still appears from some loop maps that some stiff loops have stiff branches common between them. This may or may not be a problem. For now, the non-stiff loops are equal to the number expected. However, I expect another round of bug fixing coming up soon.

Sunday, July 3, 2016

Electrical machines

Been a while since I blogged, so I thought I should post. Most of my updates on the software is on my facebook page:

The latest case I posted was of a single-phase three winding transformer. I spent almost two weeks on this and most of that time was trying to build a transformer model taking into account the magnetic circuit of the transformer. A magnetic circuit would allow a detailed model to be built if necessary - magnetizing current, core losses etc. The problem was that modeling the magnetic circuit involved calculating the flux and from this flux the induced emfs.

flux1 = L1*i1 + Lm*i2
emf1 = d/dt (flux1)

Where i1 is the primary current, i2 is the secondary current, L1 is the inductance of the primary and Lm is the mutual inductance between the windings. The problem is with the differentiation. Once you perform a differentiation, you magnify any noise and errors in the simulation. Which also means, when a non-linear component such a diode rectifier is connected, the simulation becomes unstable. This is the reason why the test case considers a diode rectifier load as it was needed to check whether the simulation was stable with this.

The second point was the method of simulating the transformer. It would have been convenient for the user to simply add a single transformer component with connections rather than to have to connect all the components together and furthermore to take into consideration the polarity of the ammeters and voltmeters. As of now I can't think of a way of doing this.

An advantage of this form of transformer modeling could be stated that a user has more control over the connections. But only a small fraction of users would really need this level of control on the modeling of a single component and that too one as basic as a transformer. For most people a transformer is basically for providing isolation or transformation between two circuits at different voltages. Without a transformer, all components would need to be transformed to one of the terminals and that means conversion of the impedances etc which could be cumbersome.

This also brings up another issue. As the circuit grows bigger, it would always be advisable to test parts out separately before integrating them together. For example, consider the case of two three-phase voltage source converters operating in current control mode connected to another three-phase voltage source converter operating in voltage control mode. It would be advisable to test each converter out separately. The problem comes when you begin to put them together. Let's say inverter 1 and inverter 2 have been tested. When putting them together, inverter 2 will have to be copied into the same spreadsheet as inverter 1. This might mean that inverter will need to be moved to another part of the spreadsheet. And this implies having to change all the parameters of Inverter 2 such as polarity of switches and diodes which could only make this integration error-prone.

A way to minimize this is that there is no need to have the entire circuit in one spreadsheet. Say all three inverters were in separate spreadsheets while testing. After testing, they remain in separate spreadsheets but are only connected together by jump labels. This would mean the parameters of these three inverters in their own spreadsheet do not change. This could make the entire process of building up a circuit so much simpler.

And this in turn might to some extent solve the problem of modeling transformers and machines. If the transformer circuit and its parameter spreadsheet always remain separate, a user can just use ready made spreadsheets over and over and not bother about changing any parameters. Only jump labels need to be added to connect them to other spreadsheets.

So this will be the next major release. The simulator should be able to deal with a circuit in multiple spreadsheets. This might take me a while.

Monday, May 23, 2016

Three-level three-phase grid connected inverter in current control mode

The next post is about a three-level three-phase inverter connected to a three-phase grid and in current control mode.

Follow Python Power Electronics on Facebook for updates:

Saturday, May 7, 2016

Single-phase three-level inverter

Posted the case of a single-phase three-level inverter in open loop.

Next will be three-phase three-level inverter in closed loop.

Tuesday, May 3, 2016

Releasing version 1.2.1

I have been out of action for the past two months. Traveling, immigration and then taxes. Now free from all of these I am back to my circuit simulator. I hope I can devote more time to this project as things are more or less working and I need to keep working on cases. Unfortunately it gets hard when I am neck deep in paperwork.

Anyway, here is the next version 1.2.1.

The only change is that I realized as the number of meters and plotted variables increases, it gets tough to count the variable column position in the output data file. So this version prints out the meter or plotted variable and the column number so that you could enter the column number directly into Gnuplot.

I am working on a three level three phase inverter case next. Hope that will be done in a week.

Monday, February 22, 2016

Releasing version 1.2.0

Finally got around to releasing the next version of the simulator. Only a minor change in the nodal analysis.

Will post the next case study of two inverters connected together - one working in voltage control mode and the other in current control mode.

Tuesday, February 16, 2016

Solver issues

After the last test case of an inverter with LC filter in voltage control mode, I have tried to simulate two inverters connected together - one in voltage control mode and the other in current control mode. To further complicate the system, the dc bus of the inverter in current control mode is formed by a three phase diode rectifier fed by a three phase ac source.

There have been strange glitches in the waveform that I could get rid off when I simulated the system at 100 nanoseconds. But then I felt that was way too demanding of such a system which should need 1 or 2 microseconds or maybe even more since both converters are switching at 5 kHz.

My first suspect was of the loop currents and felt that since the loops were being chosen randomly, they need to be rearranged to ensure that the d/dt of the ODEs were minimal. Several iterations and trials later, no change.

So the next suspect was the nodal analysis. Turns out this was the culprit. The main problem with nodal analysis is that impedances are vastly different. A diode when turned on has a resistance of 0.01 ohm while another diode that is off has a resistance of 100 megaohm. So the admittance matrix has elements that have a factor of 1e+10. This makes it prone to error.

One of the reasons for error turns out to be the nodal analysis that occurs after determining freewheeling operation. Apparently this one is particularly the case when an inductor is treated as a resistance when it has negligible current. By removing the check, the problem disappeared. That is an inductor is always treated as a current source in the nodal analysis immediately following freewheeling action.

The simulation is finally working with almost negligible glitches. Need to investigate the above effect a little more before I release the next version and post the next case. Hopefully by the end of the week.

Progress is going slow. But the good news is I have now moved on to multi-inverter systems. Hopefully, the next will be microgrids and renewable energy integration.