How to compare multiple IPMSM rotor topologies with autoML

PMSM design optimisation usually gets structured the same way: pick a topology, run FEA, evaluate the result, pick the next topology, repeat. Most teams accept this as the price of rigor. In our experience, it is not rigor — it is a sequencing problem that inflates runtime and delays the decisions that actually matter. A paper published in March 2026 in *Electric Power Components and Systems* (ScienceDirect) demonstrated a different approach: an AutoML surrogate framework that optimises across multiple IPMSM rotor topologies simultaneously, completing the full multi-objective pass in 19 minutes. That is not a research toy. It is a practical finding about how topology comparison can be structured — and it changes where we think engineer judgement should be concentrated in a motor design project.

--- ## Why Sequential FEA Is the Wrong Starting Point for PMSM Design Optimisation When you are designing an IPMSM rotor, topology selection is one of the first structurally significant decisions you make. V-type magnet arrangements, U-type, delta configurations, different flux barrier geometries, varying pole counts — these are not variants of the same design. They are structurally distinct configurations with different electromagnetic characteristics, different magnet mass requirements, different demagnetisation risks, and different manufacturing complexity. Most teams evaluate them sequentially. A full FEA solve on topology A — geometry, mesh, boundary conditions, post-processing, results review. Then topology B. Then C. By the time you reach the third configuration, you are carrying the conclusions of the previous two in your head, which is not the same as evaluating them on a common objective basis. And because each solve takes hours, the number of design points you can realistically explore at each topology narrows quickly. The deeper problem is that sequential evaluation conflates two distinct decisions: which topology to take forward, and how to optimise the chosen topology. These should happen in sequence — but they should not use the same tool at the same resolution. Running full FEA to eliminate a non-viable topology is expensive screening. It is also the default because most workflows do not separate the two stages explicitly. Surrogate models are the right tool for the screening stage. Full FEA is the right tool for the validation stage. Getting this sequence right is what the 19-minute result is actually about. --- ## What AutoML Surrogate Models Actually Do in Motor Optimisation A surrogate model is a fast-running approximation of a full FEA solve, trained on FEA data. You run enough full FEA cases to cover the design space, train the surrogate on those results, and then use the surrogate to evaluate thousands of design points in the time it would take the FEA solver to complete a handful. The 2026 paper took this further by applying AutoML — automated machine learning — to surrogate model selection. Rather than fixing one model type for all topologies, the AutoML framework evaluated multiple candidate models for each topology independently and selected the best-performing one automatically. The result was surrogate accuracy above 95% across all topologies examined. That is a meaningful threshold: at 95%+ accuracy, the surrogate is providing enough fidelity to make topology-level comparisons credible, even if it is not adequate for final validation. The multi-objective optimisation then used NSGA-II — a well-established evolutionary algorithm for handling competing objectives — across all topologies simultaneously. Objectives like peak torque, power factor, and magnet mass trade off against each other differently in each topology configuration. NSGA-II produces a Pareto front: the set of designs for which you cannot improve one objective without degrading another. Running this across topologies simultaneously means the Pareto front reflects all configurations at once, so the comparison is honest — you are not comparing the best-optimised version of topology A against a less-optimised version of topology B. The complete run — surrogate training, multi-objective optimisation, full topology comparison — completed in 19 minutes. The equivalent using repeated full FEA calls would take hours to days depending on the design space and solve complexity. This does not eliminate engineering judgement. It relocates it to where it belongs: at the topology selection stage, where the engineer defines which topologies to include, which operating points matter, and what the trade-off priorities are. The surrogate handles the computational screening. The engineer makes the structural call. --- ## The 19-Minute Result — and What It Requires to Achieve The 19-minute figure is worth being precise about, because it depends on conditions that do not arrive automatically. First, the surrogate has to be trained on real FEA data. Surrogate accuracy above 95% requires a training dataset that covers the design space adequately — geometry variations, operating point variations, topology variations. That training data comes from FEA runs. The time saving is in the optimisation pass that follows, not in eliminating FEA from the process entirely. If the training data is sparse or poorly distributed across the design space, the surrogate degrades and the accuracy guarantee fails. Second, the AutoML selection means the framework is choosing the best model for each topology. This is a genuine capability improvement over fixing a single surrogate type — different topologies respond better to different model architectures — but it requires that the AutoML framework has been set up to evaluate a meaningful candidate set. Out-of-the-box AutoML on poor training data still produces a poor surrogate. Third, the NSGA-II optimisation is only as useful as the objective functions it is given. Peak torque is an objective. Power factor is an objective. Efficiency over a drive cycle — WLTP, for instance — is a more complex objective that requires the operating point definition to be thought through before the optimisation runs. If the objectives do not reflect the real design requirements, the Pareto front shows you the best designs for the wrong question. None of these conditions are difficult to achieve in a well-structured project. But they are conditions — and they require engineering inputs before the optimisation starts, not after. --- ## Where Surrogates End and Rigorous FEA Begins Surrogate models at 95%+ accuracy are good enough for topology screening. They are not adequate for final validation of an IPMSM design, and we would not treat them as such. The final validation of a selected IPMSM configuration requires full FEA for reasons that are specific to motor design: **Peak torque at high current:** Surrogate models trained on mid-range operating points will interpolate reasonably well across most of the torque-speed envelope. The behaviour at current limits — near the onset of saturation, near demagnetisation thresholds — is nonlinear and highly sensitive to geometry. This is where the surrogate will drift first, and where field weakening performance is determined. **Cogging torque and torque ripple:** These are high-frequency phenomena relative to the fundamental electromagnetic quantities the surrogate is trained to predict. Cogging torque depends on the precise relationship between slot geometry, magnet pole arc, and airgap field harmonics. A surrogate that achieves 95%+ accuracy on torque and power factor may still miss cogging torque by a margin that is commercially significant in noise-sensitive applications. **Thermal derating over the operating cycle:** The electromagnetic performance at rated conditions is not the same as the sustained performance under continuous duty. Thermal behaviour under load — winding temperature rise, rotor heating, permanent magnet derating at temperature — requires a coupled electromagnetic-thermal analysis that surrogates are not typically structured to handle at the fidelity required. For all of these, we use Ansys Maxwell. The surrogate identifies which topology configuration is worth running at full resolution. Maxwell runs the rigorous validation: transient FEA across the operating cycle, including the edge cases that the multi-objective optimisation is not designed to explore. The boundary between the two stages is not arbitrary. The surrogate handles topology comparison at adequate accuracy for screening. Full FEA handles the validation of the selected topology at the accuracy required for design sign-off. --- ## How SimulaX Structures an IPMSM Optimisation Project In our PMSM electromagnetic design work — using Ansys Maxwell and OptiSLang — we have found that the biggest source of wasted time in motor optimisation projects is not slow FEA. It is poor staging: running full FEA resolution at a stage where topology screening would have been sufficient, then having to go back and revisit topology decisions after full-resolution work has already been done. The framework the 2026 paper describes formalises something we think should already be standard practice: separate the topology comparison pass from the final verification pass. Use the topology comparison stage to reduce your candidate configurations to the one or two worth taking to full resolution. Use full FEA to validate those configurations rigorously — including the edge cases, the nonlinear operating points, and the thermal-electromagnetic interactions that surrogates will not capture at adequate fidelity. What the AutoML surrogate result adds is a more systematic and automated approach to the screening stage — particularly useful when there are three or more structurally distinct topologies to compare, or when the design space per topology is large enough that manual steering of the optimisation is impractical. The design engineer's call — which topologies are in scope, which operating points define the product, what the trade-off priorities are between torque density, efficiency, and magnet cost — does not go away. It just happens earlier, at the stage where the workflow can actually benefit from it, rather than after six solver queues have already run. If you are working on an IPMSM design programme and want to discuss how to structure the topology comparison and validation stages — including what a Maxwell-based final verification pass covers — we are happy to talk through the workflow. --- *Designing an IPMSM and working out where surrogate modelling fits in your workflow? Get in touch — this is Andrzej's domain at SimulaX, and we are glad to discuss what a well-structured PMSM design optimisation project looks like for your geometry, operating requirements, and timeline.*