Motion

Setting up a rotor, a linear mover, or several of each, without remeshing.

Nabla never moves the mesh. A moving part is a motion zone: a group of regions that rotate or translate together, connected to the rest of the model by one or two sliding bands that re-solve the interface at the mover's current position on every step. Because the mesh itself is untouched, you can enable more than one motion zone at once — two independent rotors, a rotor plus a linear mover, a magnetic gear — each with its own profile, bands and results.

Adding a motion zone

1. Select the region(s) that make up the moving part (a rotor's iron and magnets, a mover's core).
2. Add a Circular Motion (rotary) or Linear Motion (translating) zone from that selection.
3. Assign a periodic/anti-periodic boundary condition to each interface between the zone and the rest of the model, marking which ring(s) move — see Boundary conditions — the sliding band. A disc-shaped rotary zone needs one such interface; an annular one (a zone with air, or another part, both inside and outside it) needs two.
4. Enable the motion zone. Enabling is not exclusive: turning one zone on does not turn another off, so a model can run with several zones live at the same time.

Motion profile

Each zone carries its own profile: an initial position (Initial Position, in degrees for a rotary zone or a length for a linear one) plus a speed-vs-time table (angular speed for a rotary zone, speed and direction for a linear one) that drives it during the run. A constant speed is simply a one-row table; add more rows for a speed that changes partway through the run — a ramp-up, a step change, a reversal. There is no position-vs-time table and no way to drive a zone from an external mechanical result or from the circuit: Nabla always integrates position forward from the speed table itself. A profile belongs to one zone only; two zones never share a profile even if you want them to move in lock-step (drive them with matching speed tables instead).

Two moving parts sharing an interface

When the interface is between two zones that both move — counter-rotating rotors, a magnetic gear, two independent linear movers passing each other — mark both rings of that band as moving and name each ring's own motion. The band is then driven by the relative displacement between the two zones rather than by either zone's absolute position, which is what makes the interface behave correctly regardless of which side you happened to select first.

Skewed zones

Rotor-bar or stator skew is set up on the machine geometry itself (see Machines), not from the Motion panel — the number of skew slices comes from the parametric machine's own skew setting. The Motion panel's only skew-related control is a skewed part checkbox, which only appears once the model has more than one skew slice and more than one motion zone enabled: tick it on the zone that is actually the skewed one so the solver knows which motion's position feeds the per-slice offset. With only one motion zone enabled there is nothing to disambiguate and the checkbox stays hidden.

Reading motion results

What a zone reports depends on its kind:

• Rotary zones report torque;
• Linear zones report a force pair: thrust along the direction of travel and a normal force across it.

Results are kept per motion zone, so with several zones enabled you read each one's torque or force separately rather than a single combined number. For backward compatibility, the position and torque/force of whichever zone has the lowest enabled ID also appear as the model's single "primary" motion result — the number every single-motion model has always shown.

Enable only sets the zone's enabled flag — disabling a zone again leaves its regions, bands and boundary-condition assignments exactly as they were, so re-enabling it later needs no rework. This also means a disabled zone's leftover band assignments do not disappear on their own; delete them by hand if you are repurposing those regions for something else.

Motion validation rules

The traffic-light checklist runs a set of motion-specific rules on every edit and reports which one failed rather than a generic "motion is invalid." The ones you are most likely to meet:

• a zone with no enclosed area (an outer radius no larger than the inner one, on a rotary zone; zero width or height, on a linear one);
• two enabled zones whose regions overlap, or a single region claimed by more than one zone;
• a zone driving no sliding band, more than the two bands a zone can have, a band mixing arc and line edges, or a band with a moving/stationary ring mismatch;
• a band's two rings naming different motions, or a band left ambiguous when more than one zone is enabled and it does not say which one drives it;
• a linear band whose edges are not parallel to its zone's direction of travel;
• a skewed model with more than one motion enabled but no zone marked as the skewed part;
• the Thermal Module enabled together with any motion — the thermal solver has no concept of a moving mesh and rejects the combination outright;
• more than one enabled motion zone at once requires the Core Pro licence tier.

What is not supported

• A mover nested inside another mover (one motion zone entirely inside a second moving zone).
• Mechanically coupled motion — Nabla does not compute a rotor's speed from the torque it produces; you supply the position profile.
• Axisymmetric models combined with rotor/stator skew (see Meshing — element order) — both are supported separately, never together.

Next steps

• Boundary conditions — the sliding band.
• Post-processing — forces and torque.
• Back to the contents.