Blog
Kaan Kaan Mod Oct 8, 2026

From Customer Requirements to a Simulated Motor: How Our Configurator Works

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.