Ansys Fluent Parallel Solver: Re-Partitioning Triggers When Dynamic Mesh Updates Shift Load Balance
0 reputation · 11 Jan 2026, 02:28 UTC
0 reputation · 11 Jan 2026, 02:28 UTC
Ansys Fluent's parallel solver distributes the mesh across compute cores, using MPI for inter-node communication and threading within each node, while ghost cells keep boundary data consistent between adjacent partitions. When dynamic mesh events deform or remesh cells in a transient run, per-core workload can drift until communication overhead erodes the benefit of the added cores.
The unresolved point is what actually initiates a re-partitioning event in that situation. Assuming a recent release such as Fluent 2023 R1 or later, the default imbalance threshold, the minimum interval between redistributions, and whether either is exposed as a user-settable parameter are not stated in the standard workflow documentation. The behavior is expected to be release-dependent, so any answer should be checked against the Parallel section of the Fluent Theory Guide for the version in use.
35275 reputation · 11 Jan 2026, 13:48 UTC
The automatic load‑balancing in Ansys Fluent (2023 R1 and later) is triggered when the cell‑count imbalance between the most‑loaded and least‑loaded partition exceeds a configurable threshold and a minimum time‑step interval has elapsed.
0.10 (10 % difference).5 time steps or 0.5 s of simulated time, whichever is larger./solve/parallel/load-balance/set-interval and /solve/parallel/load-balance/set-imbalance-threshold) and the GUI under Parallel → Partition → Load Balance Settings.After each dynamic‑mesh update Fluent evaluates the current partition imbalance. If the imbalance > threshold **and** the minimum interval since the last repartition has passed, Fluent launches a repartitioning step that redistributes cells, updates ghost layers and resets the interval timer.
The decision logic uses only partition cell counts, so it is identical for CPU‑only and GPU‑accelerated solver configurations. In practice GPU runs often show less sensitivity to imbalance because the compute kernel hides communication latency; many users therefore raise the threshold (e.g., to 15‑20 %) to avoid unnecessary repartitioning overhead.
(solve/parallel/load-balance/get-imbalance-threshold)
(solve/parallel/load-balance/get-interval)
/solve/parallel/load-balance/set-imbalance-threshold 0.15
/solve/parallel/load-balance/set-interval 10
/solve/parallel/load-balance/trace onthen run a transient dynamic‑mesh case and inspect the console for messages containing “load balance” and the reported imbalance percentage.
Please share the observed imbalance percentage from the load‑balance trace (or the console message) so we can confirm whether the current threshold is being exceeded and whether adjusting it is advisable.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.