Physics domains

cufemlab is a GPU finite-element tool for electric-machine engineers: 2-D magnetostatic FEM motor workflows and a live 3-D magnetic field validation lane, plus a new GPU thermal, core-loss and coupled-multiphysics lane (internally validated) and an experimental neural surrogate — with every externally-validated result carrying an independent cross-check.

Magnetostatics — the domain we solve today

The core physics domain is low-frequency magnetostatics for permanent-magnet and reluctance machines: solve for the magnetic vector potential over a 2-D motor cross-section, recover air-gap flux density, and integrate the Maxwell stress tensor (Arkkio) to get torque. Everything the platform ships today is built on this domain — the eight magnetostatics workflows are organised around this magnetostatic core, from the validated cogging path to the supporting utilities. The self-serve app is live at /app/, and a Python client SDK drives the same engine programmatically against https://app.cufemlab.secrotec.nl.

The magnetics workflows, by role

The eight magnetostatics workflows fall into four roles within the magnetostatics domain. (Six further live types — GPU thermal conduction, eddy-to-thermal coupling, core-loss, coupled core-loss/thermal, and a neural surrogate — are covered in Thermal, core-loss & FNO; the full 15-type list is in the feature matrix.)

• Validated magnetics. cogging_torque_movingband is the flagship, cross-checked against FEMM and GetDP on every run. cogging_sweep_2d is an older 2-D cogging sweep. It carries no oracle card and is legacy / superseded — prefer the moving-band workflow for new work.
• Engineering estimates. pmsm_operating_torque (2-D loaded-torque estimate) and iron_loss_estimate (Steinmetz-type) — labelled estimates, not validated numbers.
• Utilities. material_comparison compares electrical-steel and magnet grades from the materials catalog; signed_report_generation turns a completed job into a deterministic, HMAC-signed PDF evidence report with SHA-256 provenance; demo_motor_quick_check is a fast introductory pass for first-time users.
• 3-D field validation. cufem3d_field_validation — the 3-D lane, covered below.

New: thermal, core-loss & coupled multiphysics (live)

As of 2026-07-11 the platform also exposes a thermal and core-loss lane on the same GPU engine. These six analysis types are live on the API:

• Thermal conduction — thermal_conduction_steady and thermal_conduction_transient: GPU P1-tetrahedra heat conduction (−div(k grad T)=Q), steady and θ-method transient. Validated internally (MMS spatial order and Crank-Nicolson time order; energy balance to ~1e-14); an external validation passport is not yet attached.
• Eddy-to-thermal coupling — eddy_thermal_coupled: eddy skin-effect Joule loss driving a thermal response (energy chain, internally validated). This is how eddy-current physics reaches the customer API today; standalone eddy-current solvers remain engine-internal.
• Core loss — core_loss_estimate (Bertotti 3-term separation with cited coefficients) and coreloss_thermal_coupled (core-loss density driving a cooled-block thermal response). Internally validated; external passport pending.
• Field-to-field neural surrogate — field_to_field_neural_operator: an experimental in-distribution surrogate / self-validating demo. It predicts a thermal field from a seed-drawn in-distribution conductivity field and self-scores against the real solver on the same field each run (held-out rel-L2 0.68% on the training distribution; out-of-distribution degrades). It is not a general-purpose neural operator, and arbitrary custom-field / CAD input is a planned follow-on, not shipped.

Running a magnetics workflow

The SDK flow is the same for every workflow: create a project, optionally upload a geometry file, submit an analyze(...) call, wait for the job, and read the result envelope. Omitting max_minutes uses the per-analysis default, so you never have to guess a limit.

import os
from cufemlab_client import Client

client = Client(api_key=os.environ["CUFEMLAB_API_KEY"])   # base url defaults to https://app.cufemlab.secrotec.nl
project = client.create_project("PMSM cogging study")

job = client.analyze(
    project_id=project.id,
    analysis_type="cogging_torque_movingband",   # flagship validated 2-D workflow
    input_params={"stator_slots": 12, "rotor_poles": 10},
    gpu=True,                                  # cogging runs GPU-first; omit max_minutes for the default
)

job.wait(poll_interval=10)
result = job.result()

print(result.verdict)    # e.g. PASS - measured against the FEMM/GetDP validation card
print(result.value)      # peak cogging torque
print(result.metrics)    # tolerance + measured relative error from the card

Every result is returned in the result.v1 envelope with .verdict, .value, .summary, and .metrics, plus downloadable artifacts. To attach evidence, run signed_report_generation on the completed job and call job.download_report("report.pdf") for a signed PDF. See Motor workflow and the API reference for the full parameter set.

3-D field validation lane

cufemlab has a live 3-D field validation lane. cufem3d_field_validation runs a 3-D magnetostatic edge-element (Nédélec) solve on a controlled analytic benchmark (a uniformly-magnetized sphere, whose interior field has a known closed form): it builds the 3-D mesh, solves for the magnetic field, and grades the computed field against the analytic reference, returning a relative-error field verdict and a downloadable result artifact. It runs on CPU and is the first rung of our roadmap toward full 3-D motor simulation — a working 3-D magnetostatic field-validation capability you can run today.

project = client.create_project("3-D field validation")

job = client.analyze(
    project_id=project.id,
    analysis_type="cufem3d_field_validation",     # 3-D edge-element (Nedelec) magnetostatic solve
    input_params={"mesh_n": 24},                  # controlled analytic case; omit input_params for the defaults
)
job.wait(poll_interval=10)
r = job.result()

print(r.verdict, r.value)   # relative-error field verdict on a controlled 3-D magnetostatic case

Scope at a glance

Where the product sits across the magnetostatics domain and its neighbours:

Validated results vs engineering estimates

The distinction is deliberate and visible everywhere in the product:

• Validated means the run ships with an external cross-check card. Exactly two types do: cogging_torque_movingband, compared against FEMM and GetDP, and cufem3d_field_validation, compared against an analytic sphere. Both cite a tolerance and a measured error. The legacy cogging_sweep_2d does not.
• Engineering estimate means a physically-grounded, repeatable model without an independent reference on the run — pmsm_operating_torque and iron_loss_estimate. Good for design exploration; not a validated figure.
• Utility means a supporting tool — material_comparison, signed_report_generation, demo_motor_quick_check — not a physics claim.

For an exhaustive list of what is and is not claimed, see Hard limitations; for what comes next, see the Roadmap.

Where each workflow runs

Compute is split by cost profile across a FastAPI + Redis-queue + Postgres backend with a dedicated GPU (RTX-class) node. The magnetics FEM workflows run GPU-first; the estimators, utilities, and the 3-D lane run on CPU:

• GPU-first: cogging_torque_movingband, cogging_sweep_2d (legacy), pmsm_operating_torque, and the new thermal lane — thermal_conduction_steady, thermal_conduction_transient, eddy_thermal_coupled, coreloss_thermal_coupled, field_to_field_neural_operator.
• CPU: iron_loss_estimate, material_comparison, signed_report_generation, demo_motor_quick_check, core_loss_estimate, and cufem3d_field_validation (3-D, currently CPU).

A per-user concurrency cap protects the shared GPU node — a second concurrent job over the cap returns HTTP 429 CONCURRENCY_LIMIT_EXCEEDED. See Compute: GPU & CPU for the full picture.

Where to go next

• Run your first analysis: Getting started → /app/new_analysis.html.
• Understand the flagship magnetics path: Motor workflow.
• Try the 3-D field validation lane: /app/new_analysis.html.
• Check the full parameter set: API reference and Examples & recipes.
• Talk to us about a scoped evaluation: Request a pilot or book a technical evaluation.