Reluctance networks 104: Practical implications

Welcome back to my post series about reluctance network analysis. I started it after the acceptance of my paper to the EPNC conference, after which we have discussed some typical mistakes, and seen what to do instead. Today’s post brings us a full circle, to the very paper that kicked of this all, and some practical considerations as well. But worry not,  I remembered to include some nigh-incomprehensible maths as well!

So, my paper.

It got accepted as a poster presentation, meaning I get to stand before an A0-sized print summarizing the results, to discuss with some fellow researchers and answer their questions. You can find it on my newly-established SlideShare account, or in the hopefully-working embed below.

Reluctance networks in practice

As you can see, it all started with an EU project, in which our group was responsible for developing a design software. The device being developed was a so-called axial flux electrical machine. These machines have the nasty characteristic that they are fundamentally three-dimensional devices, meaning that the magnetic field inside them travels axially at some points. By contrast, in the more common radial flux machines the field will quite nicely stay on the plane of the machine cross-section. Thanks to this phenomenon, they can be reasonably well analysed by two-dimensional finite element analysis, i.e. FEM.

But as mentioned, this is not the case in axial flux machines. Instead, all three dimensions have to be considered in the numerical simulations, greatly increasing the computational cost. Hence, reluctance networks were chosen as the tool of analysis, and the rest is – if not history, then at least this post series.

As you can see, our final software had quite a many features. It was fully nonlinear, considering the magnetic saturation of the iron parts. The common pitfall of scalar potentials was avoided by using the loop method, while still enabling efficient modelling of the rotor motion by separating the time-varying components of the network. And of course, it was fully coupled with circuit equations, to model the effects of voltage supply.

Plus lots of other cool details, not quite fitting into the poster, or the preceding paper either for that matter.

And it turned out to work quite well indeed. Near the bottom-right corner of the poster you see some flux linkages and induced voltages, computed both with our software and the commercial FEM software Comsol. As you see, the results from our network software are quite accurate, especially considering it was more than 200 times faster. Indeed, computing the no-load curves in the figures required more than two hours of Comsol-time, versus 40 seconds for the network.

Well okay, two hours is not too bad for a computation time – if you have to do it once or twice. But remember that the goal was a design software. In other words, something to be run over and over again with small changes in some parameters or dimensions. Imagine waiting two hours to see if your approach works – now that would be frustrating.

And that was for no-load simulation only, meaning that there we no currents flowing in the machine. That meant that Comsol could use the so-called magnetic scalar potential for the problem solution. Had there been currents flowing, the FEM software would probably have used some kind of vector potential in at least some portions of the machine geometry, tripling the number of unknowns in those parts. This would have probably increased the computation time even further. By contrast, the reluctance network would – and did – still finish in 40 seconds.

Maths again

Talking about scalar potentials brings us to the maths I promised at the beginning of this post. In the previous two posts I wrote how many people use the nodal method to solve a magnetic scalar potential for the nodes of the network. However, recently I realized this is not 100% accurate. Or, at the very least, it deserves a different interpretation.

Indeed, the method should be called a reduced scalar potential approach, rather than pure scalar potential. At least, that’s a common term for a very similar approach sometimes used in FEM.

You see, there are actually two quantities solved in the problem, rather than simply one potential. Well, the first one is literally solved with the nodal method – the quantity associated with each node. The second one is the rotational field contribution of the current sources, obtained with whatever means possible.

In FEM, the Biot-Savart law can be used, or a simpler linear problem can be first solved to obtain the source field. With reluctance networks, experience is often the method of choice – presenting each current with a suitable mmf source that hopefully does not violate the underlying physical laws. And that may not be easy.

Besides this difficulty of source placement, the reduced scalar potential method is also known to suffer from other difficulties in non-linear problems. You remember that the flux going through a reluctance element is proportional to the potential difference between the element’s end-nodes. Now, if that element happens to be iron, its reluctance is very low. This means that the node-potentials have to be very close to each other, lest to flux grow enormously.

This alone would be problematic – computer’s don’t like handling numbers very close to each other. And things get even worse when the magnetic nonlinearity of iron is taken into account – nonlinearity in this context meaning that the reluctance value will increase with the amount the flux flowing through it.

Now, remember that the flux is in turn dependent both on the aforementioned small potential difference and the reluctance value, again depending on the flux. This combined interdependency makes the problem very difficult to solve with iterative methods – small changes in the potentials will lead to big changes in the reluctance values, requiring huge changes in the potentials on the next iteration.

And this may lead to the method not reaching any solution at all, or reaching the correct solution only after a huge number of iterations. And that’s not cool.

Reluctance networks 104: Practical implications