Archived
deploy.
This commit is contained in:
@@ -0,0 +1,172 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<title>CPU Usage During Simulation | HiAPI-C# 2025 </title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="title" content="CPU Usage During Simulation | HiAPI-C# 2025 ">
|
||||
|
||||
|
||||
<link rel="icon" href="../../img/HiAPI.favicon.ico">
|
||||
<link rel="stylesheet" href="../../public/docfx.min.css">
|
||||
<link rel="stylesheet" href="../../public/main.css">
|
||||
<meta name="docfx:navrel" content="../../toc.html">
|
||||
<meta name="docfx:tocrel" content="toc.html">
|
||||
|
||||
<meta name="docfx:rel" content="../../">
|
||||
|
||||
|
||||
|
||||
<meta name="loc:inThisArticle" content="In this article">
|
||||
<meta name="loc:searchResultsCount" content="{count} results for "{query}"">
|
||||
<meta name="loc:searchNoResults" content="No results for "{query}"">
|
||||
<meta name="loc:tocFilter" content="Filter by title">
|
||||
<meta name="loc:nextArticle" content="Next">
|
||||
<meta name="loc:prevArticle" content="Previous">
|
||||
<meta name="loc:themeLight" content="Light">
|
||||
<meta name="loc:themeDark" content="Dark">
|
||||
<meta name="loc:themeAuto" content="Auto">
|
||||
<meta name="loc:changeTheme" content="Change theme">
|
||||
<meta name="loc:copy" content="Copy">
|
||||
<meta name="loc:downloadPdf" content="Download PDF">
|
||||
|
||||
<script type="module" src="./../../public/docfx.min.js"></script>
|
||||
|
||||
<script>
|
||||
const theme = localStorage.getItem('theme') || 'auto'
|
||||
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
|
||||
</script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="">
|
||||
<header class="bg-body border-bottom">
|
||||
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
|
||||
<div class="container-xxl flex-nowrap">
|
||||
<a class="navbar-brand" href="../../index.html">
|
||||
<img id="logo" class="svg" src="../../img/HiAPI.logo.png" alt="">
|
||||
|
||||
</a>
|
||||
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
|
||||
<i class="bi bi-three-dots"></i>
|
||||
</button>
|
||||
<div class="collapse navbar-collapse" id="navpanel">
|
||||
<div id="navbar">
|
||||
<form class="search" role="search" id="search">
|
||||
<i class="bi bi-search"></i>
|
||||
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
</header>
|
||||
|
||||
<main class="container-xxl">
|
||||
<div class="toc-offcanvas">
|
||||
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
|
||||
<div class="offcanvas-header">
|
||||
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
|
||||
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
|
||||
</div>
|
||||
<div class="offcanvas-body">
|
||||
<nav class="toc" id="toc"></nav>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="content">
|
||||
<div class="actionbar">
|
||||
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
|
||||
<i class="bi bi-list"></i>
|
||||
</button>
|
||||
|
||||
<nav id="breadcrumb"></nav>
|
||||
</div>
|
||||
|
||||
<article data-uid="Technique-CpuUsage">
|
||||
<h1 id="cpu-usage-during-simulation">CPU Usage During Simulation</h1>
|
||||
|
||||
<h2 id="simulation-computation-threads">Simulation Computation Threads</h2>
|
||||
<p>Time-series data is computed on a single thread (using only one CPU core at a time); other data can be computed in parallel.</p>
|
||||
<h3 id="geometry-removal">Geometry Removal</h3>
|
||||
<p>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.</p>
|
||||
<h3 id="physics-computation">Physics Computation</h3>
|
||||
<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="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="optimization--one-burst-then-one-core">Optimization — One Burst, Then One Core</h3>
|
||||
<p>An NC optimization is not the play loop, and its CPU trace has a different shape. Exactly one of its
|
||||
stages is parallel: the per-step feed solve, which spreads the played steps across a private pool of
|
||||
workers running at below-normal thread priority, so it stays behind interactive work on the same
|
||||
machine. Every stage announced after it — the two feed constraints, the compensation build, the NC
|
||||
regeneration and the file write — runs on a single thread.</p>
|
||||
<p>So an optimization shows one multi-core burst and then a single-core tail. A CPU sitting near one
|
||||
core's worth of load for the rest of the run is the expected shape, not a stalled run.</p>
|
||||
<p>The host setting <code>HiNC:OptCoreNum</code> sizes that one parallel stage. The shipped value <code>0</code> gives it one
|
||||
worker per logical processor; any other value caps it at that many workers, which leaves more of the
|
||||
machine for other work and lengthens the burst. It changes nothing else: not the single-threaded
|
||||
stages that follow, and not the simulation loop above.</p>
|
||||
<h3 id="cpu-not-fully-utilized">CPU Not Fully Utilized</h3>
|
||||
<p>Possible reasons why the CPU is not fully utilized include:</p>
|
||||
<ul>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
</ul>
|
||||
<p>There is no setting that changes either of these. A CPU that looks idle during an NC optimization is
|
||||
a different question, and it is answered by the stage shape above rather than by this list.</p>
|
||||
<h2 id="see-also">See Also</h2>
|
||||
<ul>
|
||||
<li><a class="xref" href="../milling-physics/machinability.html">Process Machinability</a> — the mesh-quantization ripple a finer mesh removes, and what that costs in removal time</li>
|
||||
<li><a class="xref" href="../machine-capability/spindle-capability.html">Spindle Capability</a> — the other throughput ceiling in the loop: what the spindle can deliver, rather than what the workstation can compute</li>
|
||||
<li><a href="mesh-resolution.html">Mesh Resolution</a> — choosing the value that decides which of the two cost drivers above is in the way</li>
|
||||
</ul>
|
||||
|
||||
</article>
|
||||
|
||||
<div class="contribution d-print-none">
|
||||
</div>
|
||||
|
||||
<div class="next-article d-print-none border-top" id="nextArticle"></div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="affix">
|
||||
<nav id="affix"></nav>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
<div class="container-xxl search-results" id="search-results"></div>
|
||||
|
||||
<footer class="border-top text-secondary">
|
||||
<div class="container-xxl">
|
||||
<div class="flex-fill">
|
||||
<span> Copyright © 2025 <a href='https://superhightech.com.tw'>Tech Coordinate</a>. All rights reserved. <a href='https://superhightech.com.tw'>超級高科技股份有限公司</a> © 2025 版權所有 </span>
|
||||
</div>
|
||||
</div>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user