Problem reduction

Posted on May 29, 2009


So, we’re still hammering the motor model in school. You can always take a peek here.

We’ve decided early on to drop the Opti-Y optimization suite in favor of good old fashioned homegrown Octave scripts. On one hand, Opti-Y didn’t look friendly to Linux at all, and on the other hand we wanted to leverage our own knowledge of Intelligent Algorithms. So Octave+FEMM it is.

We’re getting a Genetic Algorithm (“GA”) toolbox ready for action with our FEMM scripts, and at the same time improving those model scripts. The modeling is becoming more complicated each week, as we go along and add variable parameters to the machine model; in our classes people come up with pertinent observations, like for example “what happens to torque if the rotor magnets are embedded instead of salient?”, or “what happens to performance and efficiency if the stator teeth are not ferromagnetic?”; usually the correct answer is “it depends!”. So we add these options into the design as parameters, instead of choosing anything beforehand. But that shouldn’t be a problem, since the GA really doesn’t mind – in fact, the more parameters we have, the more pertinent it is to use GA instead of a simpler exploration approach.

The intention of the project is not to cover traditionally known ground and emulate the “typical” decisions; it is in fact to throw as large as possible a universe of options into the evolutionary cauldron and see which “genetic” traits emerge victorious. I expect we are only going to confirm the already known industrial tricks (if we do it right), but the approach lends itself to the appearance of surprises (which is something I would enjoy very much).

Anyway, not all are roses. There is the tiny problem of CPU workload. The GA itself is really light, but for each iteration and each “individual” in the “population” of options there must be at least one execution of machine simulation in FEMM. This means we are possibly looking at many thousands, possibly millions, of simulations necessary to make the GA converge to a good enough solution. And since the original version of the model takes around 6 minutes to solve on my most powerful computer… you do the math. I’d be an old man when we got the results.

So, the computational problem must be reduced. Two approaches are being taken to achieve this:

1 – Reduce the node count. I used to have somewhat “generic” sizes for the finite mesh in each part of the machine; I had 3 sizes (fine, medium, coarse) and used them more or less arbitrarily. Now that node count has become important, I’ve taken to define each zone’s mesh size as a fraction of the zone’s own dimensions. If I’m very interested on what is going on in a zone, I may pick a mesh size of “dimension/5”; if the zone is of little importance, I may pick as low as “dimension/2” (although it is theoretically advised to stay over “dimension/3”). Anyway, the node count got reduced last night by around 20% as a consequence of this effort. The subdivision of the air gap into 2 areas (inter-pole gap and stator-rotor gap) also helped a lot, allowing to specify different mesh sizes in these two.

2 – Reduce the overall size of the problem. It is a well-known fact that electric machines are projected with a lot of symmetry. It is correct to do a finite element simulation of a single “tooth” of certain types of machine and then extrapolate for the whole machine. This cuts down tremendously in CPU time, and allows us greater precision (with finer meshing if we like) with the same resources. Unfortunately, our machine has a lot less symmetry than others… The typical 12 pole LRK windings force us to simulate a minimum of half the machine (6 stator poles). Well… half is better than full. 🙂 And when we increase the pole count to twice as much, we can reduce the simulation to one quarter of the machine (the same 6 stator poles). So, it’s not perfect, but it’ll do nicely. I’ve gotten the stator to “reduce” cleanly upon request, but the rotor is a much more delicate problem because it can be drawn in any position, and so the magnets may end up cut in any proportion. I need to change a lot of code in the framework to achieve this. Oh, and then there’s the debugging… 😉

So, in a nutshell, that’s what’s going on. Time is running out, so we must focus on the important.

Posted in: Motorfemmulator