Solving
Choosing the kind of problem you have, running the solver, and reading its progress.
Problem type and simulation type
Two independent choices in the Solver settings panel describe the physics:
Problem type
- Planar 2D — an x-y cross-section extruded by a constant axial length (the ordinary case: a motor or transformer cross-section);
- Axisymmetric 2D — an r-z half-plane representing a solid of revolution (a solenoid, a round actuator). Draw the geometry entirely at x ≥ 0; the solver applies the axis condition for you. Rotary motion, circular/arc periodic boundaries and multi-slice skew are not available in this mode — a moving part must translate along the axis instead.
Simulation type
- Static — one solve, no time axis;
- Transient — a sequence of time steps, for anything that moves, switches, or otherwise changes with time;
- Time-Harmonic Core Pro — a single complex-valued solve at one frequency, for a sinusoidal steady state without stepping through a full period. Every AC coil runs at the one Simulated Frequency you set here (a coil's own frequency field is ignored in this mode); Snapshots Per Period controls how many time-domain instants are reconstructed from the complex result afterwards.
Axisymmetric combines with any of the three simulation types; it is independent of which one you pick.
Solver type
A separate radio choice, Solver Type, picks how the linear system inside every step is actually solved: Simplicial LDLT, a direct sparse factorization (the default), or Conjugate Gradient, an iterative solver with its own CG max. iteration number and CG tolerance. The direct solver pays its cost once per distinct sparsity pattern and is the more predictable choice for most 2D models; Conjugate Gradient trades that up-front factorization for a per-iteration cost that scales better on a very large mesh, at the price of a convergence tolerance you now have to tune, on top of the nonlinear-materials tolerance already described below. If you are not sure which to use, start with the default direct solver and only switch to CG if solve time on a large mesh becomes the bottleneck.
Time integration
A transient run's time-stepping scheme is set once, alongside the time step and end time:
- Backward Euler (1st order) — the default, unconditionally stable, the right choice for most models;
- Crank-Nicolson (2nd order) Core Pro — more accurate per step for the same time step size, at the cost of a tendency to ring after a sharp change (a switch opening, a step change in excitation). Startup BE Steps runs that many Backward-Euler steps before switching to Crank-Nicolson, which damps that initial ringing — raise it if you see oscillation right after a discontinuous start.
How you set a transient run's length depends on whether the Machines module is active:
- without it, you set Time Step and Time End directly, in the model's length/time units, and the number of steps follows from dividing one by the other;
- with it, you instead set Sim. Periods (Electrical) (how many electrical cycles to run, minimum 1) and Steps Per Period (Electrical) (time resolution within one cycle, minimum 3) — Nabla derives the time step and end time from those plus the electrical frequency, which is the more natural way to think about a machine run: "simulate 3 electrical cycles at 40 steps each" rather than working out a time step by hand from the frequency.
A Time-Harmonic run's Snapshots Per Period (see above) plays exactly the same structural role as the step count in a transient run — the reconstructed instants populate the same step list you page through in Post-processing (see Post-processing — stepping through a result), even though only one complex-valued solve actually ran.
For a machine model with the averaging sliding band enabled, the Sliding-band gap fraction and Sliding-band subdivision fields sit in this same Solver settings panel — see Meshing — mesh size for what they control.
Nonlinear materials and convergence
Tick Enable non-linear materials whenever a region uses a real B-H curve (almost always, once any region has iron in it) — each step then runs an inner iteration that converges the field against the material's actual saturation curve rather than a fixed permeability. Two settings control that inner loop:
- Nonlinear Materials Iteration Tolerance — the relative change in the
solution below which an iteration is accepted as converged (default
1e-3; tighter is more accurate and slower); - Max. Iteration Number — the most iterations attempted before giving up on that step (default 100).
A separate pair, CG max. iteration number and CG tolerance, governs the linear solver's own convergence when Conjugate Gradient is the selected Solver Type — a different, inner-inner loop from the nonlinear-materials one above; do not confuse a linear-solver convergence failure with a materials one when reading the log.
Enable eddy-current and Enable circuit solver live in the same panel: the first lets conducting regions carry induced currents rather than only the currents you impose, the second couples the RLC circuit editor (see Coils & circuits — circuits) into the solve instead of treating coil currents as independent sources.
Geometry feasibility checks
Before meshing (and so before every solve, since a solve always meshes first) Nabla runs a parametrized-geometry feasibility audit, separate from the traffic-light checklist's BC/region/motion rules: it looks specifically at whether the geometry itself — slot dimensions, air gaps, magnet pockets — is physically buildable at the parameters you set. Findings (worst severity first) are listed directly in the Mesh tab rather than behind a separate button, so a geometry that is technically meshable but dimensionally implausible (a magnet wider than its pocket, a slot opening larger than the slot itself) is flagged there before you spend time solving it.
How a licence limit shows up before you solve
A capability your licence does not include is not just refused at the moment you press Solve.
Time-Harmonic, Crank-Nicolson and 2nd-order elements
are disabled directly in their own controls (greyed out, with a tooltip naming the required tier)
whenever the active licence lacks Core Pro, and a model that
was saved with one of them under a fuller licence is silently reset to the unlicensed default
(Static, Backward Euler, 1st order respectively) with a line in the log explaining why — so a
setting "reverting itself" after opening a model on a different machine is expected behaviour, not
a bug. Enabling more than one motion zone at once is not pre-blocked the same way; it is instead
caught by the traffic-light checklist and, if you solve anyway, by the solver's own
LICENSE_ERROR: refusal (see Reading the log below and
Licensing). The mesh-node cap (see
Meshing — the free tier's mesh cap) is the one limit
that is never pre-blocked in a control, because it depends on how you meshed, not on a setting.
Progress and cancelling a run
A running solve shows a Solver Progress window: a step counter for a transient or time-harmonic run, and, whenever the nonlinear-materials loop is active, a residual readout against your tolerance plus an iteration count and a small histogram of recent residuals. Press Stop to cancel — the current position is kept, playback is limited to the steps actually completed, and the model is reloaded from what was written so far. A stopped run still exits the way a completed one does, so a partial result is not flagged as a failure; check the step count against what you asked for if you are not sure whether a run finished or was cut short.
Reading the log
The solver's own console output is copied verbatim into the log bar. The lines you will see routinely:
Simulation step: K | timeStep: dt— one per completed transient/time-harmonic step;Iteration N | error: E— one per nonlinear iteration inside a step;Efalling below your tolerance is what "converged" looks like in the log;LICENSE_ERROR:<capability>|<message>— a hard refusal to run a capability this licence does not include; see Troubleshooting — licence errors;- a line naming the specific problem for an axisymmetric, 2nd-order or thermal model that fails its own validation before solving even starts — these name the exact rule that was broken (an unsupported motion/BC combination, a missing boundary condition) rather than a generic failure.
A nonzero exit code means the solver refused or crashed and Nabla does not attempt to load a result from that run; read the log lines above the exit line for why.
Next steps
- Post-processing — reading the field once a solve finishes.
- Troubleshooting — non-convergence in a nonlinear solve.
- Back to the contents.