Hard limitations

This is the authoritative scope statement for cufemlab: exactly what is independently validated today, what ships as an engineering estimate, and what is on the roadmap toward full 3-D motor simulation — stated plainly so nothing is ever mistaken for more than it is.

Scope at a glance

The live catalog is 15 analysis workflows (magnetics, a thermal / core-loss / coupling lane, a neural surrogate, and GPU-accelerated 3-D field analysis), all self-serve through the web app and the Python SDK. Here is where each capability sits today.

On the 3-D lane specifically: GPU-accelerated 3-D field analysis is available on compatible GPU workers. Runtime metadata reports the actual execution backend and fallback state. It is experimental, it is fail-closed (no silent CPU fallback), and it is not an independently validated 3-D torque prediction — it is the GPU execution lane for the same 3-D field solve as the CPU cufem3d_field_validation utility.

Validated vs engineering estimate

Two of the torque-class workflows sit at different confidence levels, and we are explicit about which is which. Read a result's .verdict and validation card before you rely on it.

cogging_sweep_2d is legacy

cogging_sweep_2d is an older 2-D sweep that predates the moving-band implementation. It remains in the catalog for backward compatibility but is partial and superseded. For any new work, prefer cogging_torque_movingband — it is the validated path and the one that carries the FEMM/GetDP card.

The 3-D lane: field validation today, full torque on the roadmap

cufemlab has a live 3-D lane. cufem3d_field_validation performs a 3-D magnetostatic edge-element (Nédélec) solve and returns geometry, mesh, and the magnetic field & flux as VTU, together with a relative-error field verdict. This is the geometry and field validation lane — available now, free-trial eligible (1 credit, ≤ 5 min), currently on CPU.

What sits on the roadmap is full 3-D motor torque with skew and end-effects, and full 3-D operating maps. The 3-D lane today validates geometry, mesh, magnetic field, and flux, and the roadmap extends it toward full 3-D motor simulation. The 3-D verdict is a relative-error verdict on the computed field and flux, and full 3-D motor torque with skew and end-effects is the direction this lane is building toward.

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(name="rotor-3d-check")
mesh    = client.upload_file(project.id, "rotor.step")          # .step / .stp / .iges / .stl

job = client.analyze(
    project_id=project.id,
    analysis_type="cufem3d_field_validation",               # 3-D magnetostatic edge-element (Nedelec)
    input_params={},
    input_file_ids=[mesh.id],
)                                                            # omit max_minutes -> per-analysis default

job.wait(poll_interval=5)
r = job.result()
print(r.verdict, r.value, r.summary)                          # relative-error field & flux verdict

See getting started for how to submit a job, upload geometry, and read the result verdict, and compute architecture for the result.v1 contract.

The new thermal / core-loss / neural lane: what it is and is not

As of 2026-07-11 the platform ships a thermal, core-loss and coupling lane plus a neural surrogate. These are real and live, but their validation status is precise — do not read them as externally certified.

• Thermal conduction (steady & transient), eddy-to-thermal and core-loss-to-thermal coupling, and core-loss are validated internally against their own analytic / energy identities (MMS spatial order, Crank-Nicolson time order, energy balance to ~1e-14, cited Bertotti coefficients). They carry validation_card = not_validated: no external validation passport is attached yet. They are not independently cross-checked the way the moving-band cogging workflow is.
• The field-to-field neural surrogate (field_to_field_neural_operator) is an experimental in-distribution surrogate / self-validating demo. It 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 inputs degrade). It is not a general-purpose or production neural operator, and arbitrary custom-field / CAD input is a planned follow-on, not shipped — today the input is a seed that draws an in-distribution conductivity field.
• Standalone eddy-current solvers exist in the engine but are not exposed as customer API types; eddy-current physics reaches the API only through eddy_thermal_coupled.

Not in the product today

The following are not shipped and are not claimed. Several are on the roadmap; all are called out here so a planned direction is never read as a live capability.

• Full 3-D motor torque with skew and end-effects, and full 3-D operating maps — roadmap; the live 3-D lane validates field and flux.
• External validation passports for the new thermal / core-loss types — they are validated internally today, not externally certified.
• A general-purpose neural operator that accepts arbitrary custom fields or CAD — the live surrogate is in-distribution only.
• Standalone transient / time-harmonic eddy-current as a customer API type — engine-internal today.
• Full industrial core-loss material database — material_comparison and core_loss_estimate use cited coefficients and the built-in materials catalog; not an exhaustive industrial database.

No commercial-tool benchmark claim

Billing and access

Billing is fail-closed: if entitlement cannot be confirmed, the job does not run. Stripe is not activated yet — there is no live self-serve card payment path, and no mock or placeholder billing is presented as real. Access today is via pilot and technical evaluation. Managed Jupyter access is provisioned as up to 24 h/day (never described as unlimited); see cufem in Jupyter.

The per-user concurrency cap is enforced: a second concurrent job over the cap returns HTTP 429 CONCURRENCY_LIMIT_EXCEEDED. Compute, queueing, and the result.v1 contract are described in compute architecture.

Where to go next

Start with getting started, review the validated motor workflow, and browse examples & recipes. For the direction of travel toward full 3-D motor simulation, see the roadmap. If any page, output, or report appears to contradict this scope statement, that is a bug — please report it to info@secrotec.nl. cufemlab is built by Secrotec B.V.