deploy webservice static-file routing for docsite folder URLs, per-instance step-cache db, and constant-height panel title bars.

App/wwwroot/HiAPI-docsite/manual/analysis/cpu-usage.html

@@ -95,15 +95,26 @@
 <p>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.</p>
 <p>Temperature computation must follow time-series order, so it converges back to a single thread.</p>
 <p>The entire machining simulation alternates between these modes. Once a step is fully computed, it is colored according to the designated indicator.</p>
+<h2 id="two-independent-cost-drivers">Two Independent Cost Drivers</h2>
+<p>Total simulation time comes from two largely independent parts:</p>
+<ul>
+<li><strong>Per-step physics</strong> (force, torque, power, temperature, wear) — computed once per <strong>step</strong>. The total physics cost scales with the <strong>number of steps</strong>, which is set by the <a href="../../workflows/basic-simulation.html#33-machining-motion-resolution">machining motion resolution</a> together with the spindle revolutions along the toolpath. It does <strong>not</strong> depend on the mesh resolution, and it does <strong>not</strong> depend on the overall workpiece size.</li>
+<li><strong>Geometry removal</strong> (voxel subtraction) — its cost is set by the mesh resolution (<a class="xref" href="../../api/Hi.MachiningProcs.SessionShell.html#Hi_MachiningProcs_SessionShell_MachiningResolution_mm">MachiningResolution_mm</a>). 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.</li>
+</ul>
+<p><code>MachiningResolution_mm</code> genuinely controls the removal resolution — it is <strong>not</strong> clamped away or ignored. But because removal and physics run concurrently, the <strong>larger</strong> of the two costs governs wall-clock time:</p>
+<ul>
+<li>When geometry removal dominates — <strong>the common case at the fine resolutions real NC machining needs</strong> — a finer mesh is much slower, and a coarser mesh reduces total time.</li>
+<li>When the mesh is coarse enough that geometry removal is already cheap, several <strong>fixed per-step costs</strong> (physics, thermal/wear, per-step bookkeeping) dominate instead. Coarsening further — e.g. raising <code>MachiningResolution_mm</code> from 1.0 to 2.0 mm — then barely changes total time; to speed up, <strong>reduce the number of steps</strong> with a coarser motion resolution. (Note: 1–2 mm is already very coarse for NC machining.)</li>
+</ul>
 <h2 id="cpu-usage">CPU Usage</h2>
-<h3 id="high-geometry-resolution">High Geometry Resolution</h3>
-<p>When geometry resolution is high, 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.</p>
-<p>In this scenario, the workload is primarily multi-core (physics computation), and you are more likely to see high multi-core CPU utilization.</p>
-<p><img src="cpu-usage-img/geom-quick.png" alt="High geometry resolution"></p>
-<h3 id="low-geometry-resolution">Low Geometry Resolution</h3>
-<p>When geometry resolution is low, geometry removal is slower than physics computation, so the light pink area is barely visible.</p>
-<p>In this scenario, the workload is primarily single-core (geometry computation).</p>
-<p><img src="cpu-usage-img/geom-slow.png" alt="Low geometry resolution"></p>
+<h3 id="coarse-mesh--physics-bound">Coarse Mesh — Physics-Bound</h3>
+<p>When the mesh is coarse (a large <code>MachiningResolution_mm</code>), 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.</p>
+<p>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.</p>
+<p><img src="cpu-usage-img/geom-quick.png" alt="Coarse mesh: geometry removal outruns physics, leaving a large pink trail"></p>
+<h3 id="fine-mesh--geometry-bound">Fine Mesh — Geometry-Bound</h3>
+<p>When the mesh is fine (a small <code>MachiningResolution_mm</code>), geometry removal is slower than physics computation, so the light pink area is barely visible.</p>
+<p>In this scenario, the workload is primarily single-core (geometry computation), and a coarser mesh will reduce total time.</p>
+<p><img src="cpu-usage-img/geom-slow.png" alt="Fine mesh: physics keeps up with geometry removal, almost no pink trail"></p>
 <h3 id="balanced-state">Balanced State</h3>
 <p>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.</p>
 <h3 id="cpu-not-fully-utilized">CPU Not Fully Utilized</h3>