Table of Contents

CPU Usage During Simulation

Simulation Computation Threads

Time-series data is computed on a single thread (using only one CPU core at a time); other data can be computed in parallel.

Geometry Removal

Geometry removal is single-threaded because sequential cutting is required to obtain the correct CWE (Cutter-Workpiece Engagement). The workpiece geometry surface after removal appears in light pink, which typically indicates that the physics for that region have not yet been computed.

Physics Computation

Cutting force computation begins after CWE is obtained. Since it is independent of computation order, it runs in multi-threaded mode under normal conditions. Torque and other physical quantities are also computed in parallel during this stage.

Temperature computation must follow time-series order, so it converges back to a single thread.

The entire machining simulation alternates between these modes. Once a step is fully computed, it is colored according to the designated indicator.

Two Independent Cost Drivers

Total simulation time comes from two largely independent parts:

  • Per-step physics (force, torque, power, temperature, wear) — computed once per step. The total physics cost scales with the number of steps, which is set by the machining motion resolution together with the spindle revolutions along the toolpath. It does not depend on the mesh resolution, and it does not depend on the overall workpiece size.
  • Geometry removal (voxel subtraction) — its cost is set by the mesh resolution (MachiningResolution_mm). A finer mesh (smaller value) is more expensive; a coarser mesh (larger value) is cheaper. Removal work is localized to the tool–workpiece contact region, so it is roughly area-scaled and, again, largely independent of the bulk workpiece size.

MachiningResolution_mm genuinely controls the removal resolution — it is not clamped away or ignored. But because removal and physics run concurrently, the larger of the two costs governs wall-clock time:

  • When geometry removal dominates — the common case at the fine resolutions real NC machining needs — a finer mesh is much slower, and a coarser mesh reduces total time.
  • When the mesh is coarse enough that geometry removal is already cheap, several fixed per-step costs (physics, thermal/wear, per-step bookkeeping) dominate instead. Coarsening further — e.g. raising MachiningResolution_mm from 1.0 to 2.0 mm — then barely changes total time; to speed up, reduce the number of steps with a coarser motion resolution. (Note: 1–2 mm is already very coarse for NC machining.)

CPU Usage

Coarse Mesh — Physics-Bound

When the mesh is coarse (a large MachiningResolution_mm), geometry removal is faster than physics computation, so a large area of light pink follows behind the tool during simulation. There is a cap on the number of unfinished steps; geometry removal only proceeds when the count is within that limit. When physics computation cannot keep up with geometry removal, the number of pink steps stays constant.

In this scenario, the workload is primarily multi-core (physics computation), and you are more likely to see high multi-core CPU utilization. Making the mesh even coarser will not reduce total time — the step count (physics) is the limit.

Coarse mesh: geometry removal outruns physics, leaving a large pink trail

Fine Mesh — Geometry-Bound

When the mesh is fine (a small MachiningResolution_mm), geometry removal is slower than physics computation, so the light pink area is barely visible.

In this scenario, the workload is primarily single-core (geometry computation), and a coarser mesh will reduce total time.

Fine mesh: physics keeps up with geometry removal, almost no pink trail

Balanced State

If the geometry resolution is such that geometry and physics computation do not bottleneck each other, the light pink area appears and fluctuates within a certain range. In this case, physics computation does not hold back geometry computation, and geometry computation is typically the performance bottleneck.

CPU Not Fully Utilized

Possible reasons why the CPU is not fully utilized include:

  • The operating system reserves headroom to ensure the GUI remains responsive. For example, Windows desktop applications (such as WPF) lower the priority of non-GUI threads by one level.
  • The software/hardware throughput has reached its limit for the process. The reported CPU usage may not reach 100%, but other resources such as cache and bus bandwidth may be saturated. System-level factors like branch misprediction are also not reflected in the reported CPU usage.

There is currently no solution for this.