Motor workflow

From a project to a signed, cross-checked result: cufemlab takes an electric-machine case through geometry, a chosen analysis, a GPU/CPU worker, and a versioned result.v1 envelope — with the moving-band cogging workflow independently cross-checked against FEMM and GetDP on every run.

The workflow at a glance

Every analysis — whether you drive it from the self-serve web app at /app/ or the Python client SDK — follows the same path. You create a project, attach inputs and optional CAD geometry, pick one of the fifteen analysis workflows, submit, and a queue worker runs it on the right compute lane. The run returns a structured result.v1 envelope plus downloadable artifacts, and any completed job can be turned into a signed PDF evidence report.

project ──► inputs + geometry ──► pick analysis ──► submit
   │              (.step/.stp        (1 of 15           │
   │               .iges/.stl)        workflows)        ▼
   │                                             queue + worker
   │                                          (GPU-first or CPU)
   ▼                                                    │
result.v1  ◄──  artifacts (VTU / plots / JSON)  ◄───────┘
   │
   └──► signed_report_generation ──► HMAC-signed PDF (SHA-256 provenance)

Step by step

1 · Create a project

A project is the container that groups related runs, uploaded inputs, and their artifacts. Create one per machine or study so results stay organized and comparable.

2 · Add inputs and geometry

Analyses are driven by input_params (dimensions, currents, sweep steps, material selections). Where a workflow accepts CAD, you can upload geometry — .step, .stp, .iges, or .stl — and reference the returned file id when you submit.

3 · Pick an analysis

Choose one of the fifteen live workflows (see Choosing your analysis). The picker at /app/new_analysis.html shows each workflow's parameter form; the SDK takes the same analysis_type string.

4 · Submit

Submitting enqueues the job. Cogging and PMSM analyses request the GPU (RTX-class) node and run GPU-first; iron-loss, material comparison, the signed report, the demo check, and 3-D field validation run on CPU. You can pass gpu to prefer the GPU lane where applicable.

5 · Queue and worker

A Redis-backed queue hands the job to a worker; you can watch progress live at /app/queue.html or poll from the SDK. A per-user concurrency cap keeps runs fair — see the operational note at the end.

6 · Read result.v1

When the worker finishes it writes a versioned result.v1 envelope carrying a verdict, a headline value, a summary, and a metrics block (including the FEMM/GetDP card for cogging). See The result.v1 envelope.

7 · Artifacts and the signed report

Field data (VTU), plots, and JSON attach to the job as downloadable artifacts. Any completed job can feed signed_report_generation to produce a deterministic, HMAC-signed PDF you can download from /app/reports.html or via job.download_report().

Run it with the SDK

The Python client mirrors the web app. Issue an API key from /app/api_keys.html, set it in your environment, and the base URL defaults to the canonical host. This example submits the flagship validated cogging workflow end to end.

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

# 1 - A project groups related runs, inputs and artifacts.
project = client.create_project("PMSM cogging study")

# 2 - Optional: attach CAD geometry (.step / .stp / .iges / .stl).
geo = client.upload_file(project.id, "rotor_stator.step")

# 3 - Submit the flagship VALIDATED moving-band cogging analysis.
job = client.analyze(
    project_id=project.id,
    analysis_type="cogging_torque_movingband",
    input_params={"poles": 8, "slots": 12},
    input_file_ids=[geo.id],
    gpu=True,                 # cogging / PMSM run GPU-first; omit max_minutes for the per-type default
)

# 4 - Poll the queue until the worker finishes.
job.wait(poll_interval=5)

# 5 - Read the result.v1 envelope.
result = job.result()
print(result.verdict)    # PASS / PARTIAL / ...
print(result.value)      # peak cogging torque
print(result.metrics)    # includes the FEMM / GetDP validation card (tolerance + measured error)

Omit max_minutes to use each workflow's own default budget; only set it when you deliberately want a shorter cap (never above the per-type limit).

Choosing your analysis

The catalog is fifteen live workflows; the core motor workflows are below (the full fifteen are in the feature matrix). Start with demo_motor_quick_check to see the whole path end to end, then move to the workflow that matches your question.

• demo_motor_quick_check — a fast end-to-end sanity run of the full submit → result path.
• cogging_torque_movingband — flagship validated 2-D moving-band (Arkkio) cogging, cross-checked vs FEMM and GetDP.
• cogging_sweep_2d — legacy 2-D sweep, superseded by moving-band (see below).
• pmsm_operating_torque — 2-D operating-torque engineering estimate.
• iron_loss_estimate — Steinmetz-type core-loss engineering estimate.
• material_comparison — compare electrical-steel and magnet grades from the materials catalog.
• signed_report_generation — deterministic HMAC-signed PDF evidence report from a completed job.
• cufem3d_field_validation — the 3-D geometry and field validation lane.

Validated, estimate, 3-D field, and roadmap

Read this before quoting a result to a stakeholder. It separates what is independently validated today, what is an engineering estimate, the 3-D field validation available now, and what remains on the roadmap.

The result.v1 envelope

Every finished job returns the same versioned envelope so tooling can consume results uniformly across workflows. From the SDK, job.result() exposes:

• result.verdict — overall status such as PASS or PARTIAL.
• result.value — the headline scalar (for cogging, the peak cogging torque).
• result.summary — a short human-readable summary of the run.
• result.metrics — the structured detail block, including the FEMM/GetDP validation card for cogging and the relative-error field verdict for 3-D field validation.

Alongside the envelope, the worker attaches artifacts — VTU field data, plots, and JSON — downloadable from the job in the app or via the SDK.

Signed evidence report

Turn any completed job into a deterministic, HMAC-signed PDF with SHA-256 provenance. This is a utility workflow: point it at a finished run and download the report.

# Deterministic, HMAC-signed PDF with SHA-256 provenance from a finished run.
report_job = client.analyze(
    project_id=project.id,
    analysis_type="signed_report_generation",
    input_params={"source_job_id": job.id},
)
report_job.wait(poll_interval=5)
report_job.download_report("report.pdf")   # signed PDF; also at /app/reports.html

Because the report is deterministic and signed, re-running it on the same job reproduces the same provenance hash — useful for design reviews and audit trails.

3-D field validation lane

cufem3d_field_validation extends the same workflow into three dimensions. It performs a 3-D magnetostatic edge-element (Nédélec) solve on your geometry and returns the mesh together with the magnetic field and flux as VTU, plus a relative-error field verdict. It runs on CPU today, is free-trial eligible at 1 credit, and typically completes in under five minutes — a fast way to validate 3-D geometry and field before committing to a larger study.

This is the geometry-and-field validation lane, available now, and the first step on the roadmap toward full 3-D motor simulation. Full 3-D motor torque with skew and end-effects, and full 3-D operating maps, are on the roadmap; the current lane focuses on validating 3-D geometry, mesh, and the magnetic field and flux. See Physics domains for more on the solver.

Next steps

• New here? Start with Getting started and issue a key at /app/api_keys.html.
• See the Examples & recipes for per-workflow parameter sets.
• Read Compute: GPU & CPU to understand which lane each analysis runs on.
• Check Hard limitations before promising a result, and the Roadmap for what is coming next.
• Want a scoped evaluation? Request a pilot or book a technical evaluation.