Blog

I came to finite element simulation from the software side. At Turncircles I wanted a simulation pipeline we could control end to end, run on our own servers, and drive entirely from code. That led me to Open CASCADE for geometry, GMSH for meshing, and ElmerFEM as the solver.

This isn't a tutorial. These are notes from a long stretch of work on one hard problem, written for anyone who is considering the same tools for electric machines.

Why open source

Three things made the decision for me.

GMSH has a Python API, so our configurator can generate geometry and meshes from parameters without anyone opening a GUI. Elmer reads plain text input files, which means code can write them too. And there are no per-seat or per-core licenses, so the number of simulations we run depends on our hardware and nothing else.

The fourth reason only became clear later. When the documentation runs out, you can read the source code. With these tools, that turned out to be the most valuable part.

The motor

Our motors are dual-rotor, coreless axial-flux machines. Two rotors carry the magnets and spin, and the stator sits between them and stays still. In a time-stepping simulation, the rotor mesh has to move relative to the stator mesh at every step, so you need a sliding interface where two meshes meet without matching node for node.

The first thing I did to keep the problem manageable was use symmetry. With 24 poles and 9 coils, the greatest common divisor is 3, so the machine repeats every 120°. Modelling one third of the motor cuts the problem size by three, and it also shrank the circuit definition from 42 unknowns to 18.

Sliding interfaces and the saddle point

Elmer couples the moving and static meshes with mortar boundary conditions. Under the hood, mortar conditions add Lagrange multipliers to the system of equations. Those multipliers create a block of zeros on the diagonal of the matrix, and mathematicians call the result a saddle-point system.

In practice this meant two things for me. The iterative solvers I tried, with ILU preconditioning, could not handle the zero diagonal on the full-size model. The direct solver MUMPS could, but its memory use grows fast with mesh size. RAM became the real design constraint for the whole simulation, and that pushed every decision about mesh density.

The hang

For several weeks I fought a problem that I still find instructive. The solver would complete a few timesteps cleanly and then stop. No crash, no error message, no new log line. One thread stayed busy while all the others went idle. Running the exact same files twice moved the stall from one timestep to another.

I tried around thirty variations: different solver settings, newer MUMPS versions, meshes with zero badly shaped elements. Nothing gave a reproducible fix.

The answer was in the mesh, on the sliding surfaces. My mesh size fields had produced elements of varying size along the interface. Once I forced a uniform element size there with a constant size field in GMSH, the hang disappeared. Mesh quality metrics had looked fine the whole time. The solver cared about consistency on that one surface far more than about the quality numbers I was watching.

Read the source

At one point I wanted Elmer to eliminate the interface constraints from the system instead of carrying the Lagrange multipliers along. The documentation suggested this was possible. Reading the Fortran source showed that this elimination path works for nodal unknowns but gets skipped for the edge elements that magnetic field simulations use. No warning, no error. It just didn't do anything for my case.

Since then I verify every solver keyword against the source before I trust it. That includes answers from AI assistants, which can sound very confident about Elmer keywords that behave differently, or don't exist at all.

The other thing I'd recommend: talk to the people who wrote the code. The Elmer community is small, and the developers behind specific solvers are reachable. A short, well-prepared question with a minimal example goes a long way.

Checking the physics

A solver that converges can still give you the wrong answer. Early on, one version of my model produced about a tenth of the expected torque, and the problem persisted across solvers, which told me it wasn't a convergence issue. Another version gave almost identical results with and without the interface conditions, which meant the conditions weren't doing anything.

These days the back-EMF waveform is my favourite sanity check. A clean, sinusoidal voltage tells me the setup is behaving. Noise in the waveform usually points to something in the interface handling, and tuning the regularization of the field formulation made a visible difference there.

Would I do it again

Yes. The cost is time, and I spent more of it than I planned. But I learned it and any new future setup will be much faster to setup. Commercial tools hide many of these problems behind a polished interface, and for a one-off design that's a fair trade.

For us, the simulation is part of the product. I need to understand every step, automate it, and scale it on our own hardware. Open source tools let me do that, and the debugging taught me more about how these motors work than any course would have.

If you're simulating electric machines in Elmer and hitting similar walls, I'd like to hear from you.

Custom motors have a reputation for long email threads. A customer sends requirements, an engineer comes back with questions, a few weeks pass, a design arrives, and then it turns out something got lost along the way.

I'm not the electrical engineer at Turncircles. My job is the software around the motor: the configurator you see in the browser, the back end behind it, the simulation infrastructure, and the work of turning what customers ask for into features. This post explains how those pieces fit together and why we built them this way.

What you put in

The configurator asks for the things you already know about your application: the torque and speed you need, your supply voltage, how much space the motor can take up, and how much it is allowed to weigh. You describe the problem. You don't need to know anything about pole counts or winding layouts.

Behind the form, these inputs become a parameter set that describes a motor geometry. That parameter set is what the rest of the system works with.

What happens after you press the button

The front end doesn't run any physics. It writes a simulation request into a database and goes back to being a website.

On a dedicated simulation server, a worker process checks that database for queued jobs. When it finds one, it does three things:

1. It builds the 3D geometry and mesh with GMSH, using the parameter set from your request.
2. It runs the electromagnetic simulation in ElmerFEM, an open-source finite element solver.
3. It writes the results back to the database, where the configurator picks them up and shows them to you.

We separated the website from the simulation on purpose. A finite element run needs a lot of memory and CPU time, and you don't want that competing with the page you're looking at. With a queue in between, the website stays fast, jobs wait their turn, and we can add another simulation server when demand grows without touching the front end.

Running heavy solvers in production taught me a few lessons I wouldn't have learned from a tutorial. One run that eats all the RAM can freeze the whole machine, so the worker runs as a managed service with a guard that kills runaway processes before they take the server down. Small things like the choice of math library under the solver changed our run times more than I expected. None of this is visible to you as a user, and that's the point.

Turning requests into features

A big part of my work is listening to what customers ask for and deciding what belongs in the product.

When someone asks "will it fit into our housing?", that question shouldn't need an engineer. The configurator can check the envelope constraint before a person ever looks at the request. When several customers ask for the same result, for example efficiency at their own operating point rather than at peak, that result becomes a standard output instead of a one-off calculation.

The rule I try to follow: if a question comes up more than twice, the software should answer it.

Laying the ground for a digital twin

Every motor that goes through the configurator leaves a record behind. Its parameters, its geometry, its mesh, and its simulation results all sit together and stay linked to each other.

That record is the starting point for a digital twin. The next step I'm working toward is connecting test bench measurements to the same record, so we can compare what the simulation predicted with what the real motor does, and use the difference to calibrate our models. Further out, operating data from motors in the field could feed into the same place.

We're at the groundwork stage, and I want to be honest about that. But we designed the data model with this in mind from day one, because adding it later would mean rebuilding everything.

Why this matters for you

For a customer, all of this comes down to two things. You get a realistic, simulation-backed answer much earlier in the process. And when you talk to our engineers, the conversation starts from a concrete design instead of a blank page.

Try the configurator with your own requirements. We have created a through Configurator Guide. If something you need is missing, tell me directly or raise your questions here in the forum. That's usually how the next feature starts.

When customers compare motors, efficiency usually ends up as one line in a spec table. 90 % on one datasheet, 92 % on the other. The price column gets far more attention.

I understand that. At Turncircles I run operations and build our business cases, and the purchase price is the number that hits a budget first. A motor runs for years, though, and the cost of running it shows up on someone's books every single month. This post walks through how I translate efficiency into money, so you can run the same math for your own application.

Look at the losses first

The efficiency figure hides the part that matters. Take a motor delivering 15 kW at the shaft:

• At 90 % efficiency it draws 16.7 kW and turns 1.7 kW into heat.
• At 92 % efficiency it draws 16.3 kW and turns 1.3 kW into heat.

Two points on the datasheet look small. In losses, they mean about 22 % less heat. Keep that number in mind, because heat costs you twice: once on the electricity bill, and again in everything you build to get rid of it.

The energy bill

Say the motor runs 8,000 hours a year (a machine in continuous production) and you pay €0.20 per kWh. The difference in input power is 0.36 kW. Over a year that adds up to roughly 2,900 kWh, or about €580. Over ten years you are at €5,800 for a single motor, before any price increases.

If you want to plug in your own numbers, the formula is short:

Annual saving = shaft power × operating hours × energy price × (1/η₁ − 1/η₂)

Multiply by the number of motors in your plant or your fleet, and the gap between two quotes often looks very different.

Heat costs you a second time

Every watt of loss leaves the motor as heat, and you pay to remove it. With less heat you can sometimes size a smaller fan, drop a liquid cooling loop, or fit the motor into a tighter enclosure. Each of these saves money on the system around the motor, and that saving rarely shows up when people compare motor prices.

Temperature also affects lifetime. A common rule of thumb for winding insulation says that every 10 °C of extra temperature roughly halves its life. A motor that runs cooler needs replacing less often, and in many applications the downtime for a replacement costs more than the motor.

This is one reason we build coreless axial-flux motors. Without iron in the stator, there are no iron core losses in the stator to turn into heat, and the machine keeps the torque advantage of the axial topology.

In battery-powered machines, efficiency buys range

For robots, drones, and other mobile machines, the math changes. You don't pay for kilowatt-hours from the grid. You pay for battery capacity, and the battery is often the heaviest and most expensive part of the system.

If most of your stored energy goes into the motors, a few points of motor efficiency translate into a few percent more range, or a battery a few percent smaller for the same range. A smaller battery weighs less, which means the motors work less hard, which saves energy again. Engineers on mobile platforms know this loop well, and it's why they ask about efficiency before they ask about price.

Ask where the motor actually runs

The peak efficiency on a datasheet describes one operating point. Your machine probably spends most of its life somewhere else: at partial load, at low speed, or cycling between the two.

A motor with a great peak number can sit 5 to 10 points lower at the point where your application spends most of its hours. So when you compare motors, ask for the efficiency map, or at least the efficiency at your main operating points. Then weight each point by how many hours you spend there. That weighted number is the one that belongs in your business case.

Designing for a specific duty cycle is the main reason to go custom. We can put the efficiency sweet spot where your machine runs, instead of where it looks best in a brochure.

Putting it together

When I build a total cost of ownership comparison, I include:

• the purchase price
• energy cost over the expected lifetime, weighted by duty cycle
• cooling hardware and its running cost
• battery size or range, for mobile applications
• expected replacement intervals and the downtime they cause

The cheapest motor on the quote is often the most expensive one on this list.

If you'd like to go through these numbers for your own application, send us your duty cycle and operating conditions. I'm happy to work through the business case with you.