SimScale Support Report — AMI Transient Simulation Cost/Convergence Issue Project: curved fin big pt2 (“omni wheel”) Simulation: AMI (sliding mesh) — transient run following a validated MRF steady-state sanity check Plan tier: Community 1. Project context 4-blade helical/curved Darrieus-type VAWT, rotation axis Y, 300 rpm (ω = ±31.42 rad/s), wind 5 m/s in −Z. An MRF steady-state sanity run was completed and validated first (torque steady and non-zero, confirming ω = −31.42 rad/s ; max velocity ≈19 m/s; pressure range in the tens–hundreds of Pa — all matching expected targets). The AMI transient run was set up as the next phase to capture the periodic torque ripple (expected ~4 pulses/revolution) that a steady MRF approximation cannot resolve. 2. What went wrong — timeline 2.1 Mesh cell-count estimate is unreliable Pre-generation “Estimate” repeatedly showed 571.6k–857.4k cells across multiple, very different actual configurations. First real generation attempt: failed with out-of-memory (OOM) , auto-retried on a larger instance, still failed. No core hours deducted. After loosening surface/volume sizing and boundary-layer settings, a mesh did complete , but at 11,158,394–11,549,903 cells (log shows it fluctuating in this range before settling) — roughly 13–20x the pre-generation estimate, and well above our 3–6M cell target. After further loosening (Curvature: Relative, “Number of nodes in a circle” reduced; Surface custom sizing default size increased to 6–8mm; Volume custom sizing default size increased to 20–25mm; Inflate Boundary Layer reduced to 6 layers), a second successful mesh completed at 4,956,801 cells — within target, quality metrics all within SimScale’s acceptable ranges (non-orthogonality avg 30.8°/max 75.8°, well under the 88° ceiling; skewness low). Question for support: why does the pre-generation cell-count estimate stay essentially static (571k–857k) across configurations that produce actual results anywhere from ~5M to ~11M+ cells? Is there a way to get a more representative estimate before committing to a full generation, especially for curvature-driven refinement on complex/helical blade geometry? 2.2 Resource (run) estimate also proved unreliable With the 11.2M-cell mesh and End time = 2.0s (Δt=0.001s, Adjustable time step = False): estimate was 930–1395 min duration, 124–186 core hours . After reducing to the 4.96M-cell mesh and End time = 1.0s: estimate dropped to 65–97 min, 8.6–13.0 core hours . The actual run (Run 6 of 10 on our Community quota) was started under this second, cheaper configuration. After 415 minutes and 55.43 core hours consumed , it had only reached 26% completion (~0.52s of 1.0s simulated, ~2.6 of 5 target revolutions) — roughly a 10x overrun versus the estimate in both duration and compute. We manually cancelled the run at that point. Per your platform’s own quota rules, this still consumed one of our 10 Community-plan simulation slots even though it did not finish — we now have 3 of 10 remaining. Question for support: is there a known reason the resource estimator would underestimate an AMI transient run by roughly 10x, when the same estimator was reasonably close for the steady-state MRF run earlier in this project? Does AMI/sliding-mesh interpolation overhead get correctly accounted for in the estimator? 2.3 Root-cause diagnosis of the actual overrun (from the cancelled run’s solver log) On every single timestep in the log excerpt we captured, two things appeared together, consistently: Courant Number mean: 0.0371918346668 max: 74.4923190571 ... PIMPLE: not converged within 5 iterations Mean Courant number stayed extremely low (~0.037) throughout , but the max Courant number was consistently in the 70–76 range — roughly 15–20x above our intended target ceiling of ~5. PIMPLE failed to converge within its 5-iteration outer-corrector budget on every single timestep we could see in the log, meaning the solver was burning its full corrector budget every step rather than exiting early — directly explaining the ~10x cost blowup versus the estimate (which likely assumed an average, not worst-case, corrector count). Simulation Control at the time of this run had Adjustable time step = False , fixed Delta t = 0.001s . With a fixed timestep and no Courant-based adaptation, any single small/fast-moving cell in the domain that produces a locally high Courant number will destabilize convergence for the entire domain’s outer-corrector loop, every step, for the whole run. Suspected physical location: our mesh’s boundary-layer prism cells at the blade trailing edge showed a minimum edge length of ~4.55×10⁻⁵–1.05×10⁻⁴ m (45–105 microns) in the mesh quality log, in a region where local blade-tip velocity is roughly 15–20+ m/s. A cell that small combined with that velocity, at Δt=0.001s, is consistent with producing exactly this kind of Courant spike — but we have not directly visually confirmed this is the specific cell/location; this is inferred from the mesh log statistics, not a direct inspection. We separately used Mesh Inspection’s Iso Volume filter (Aspect Ratio, min=100) plus visual inspection to check for boundary-layer collapse at the trailing edge (a known distinct failure mode from ordinary high-aspect-ratio boundary layer cells) and did not see obvious signs of collapse — the high-AR cells appeared as a thin, sparse trace along the blade edges consistent with expected (not defective) boundary-layer anisotropy. So we don’t believe the mesh is geometrically broken, but do believe a small subset of cells is limiting the timestep. 3. Changes planned in response (not yet run to completion) Adjustable time step: False → True Maximal Courant number: set to ~5 (previously the field existed but was arguably irrelevant with Adjustable time step off) Delta t: reduce starting value to 0.0005s (from 0.001s) so the adaptive solver has less distance to fall from the initial guess End time: kept/reverted to 1.0s (5 revolutions) rather than the full 2.0s (10 revolutions), specifically so this next attempt functions as a cheap validation test of the fix before committing further quota/compute Numerics left as previously set: Number of outer correctors = 5, Number of non-orthogonal correctors = 2 (both already reduced from higher starting values earlier in this process), residual tolerances unchanged (1e-6 abs / 0.01 rel across U, P, k, ω) We have not yet run this configuration , given we are down to 3 of 10 simulation slots and want to be confident before spending another one. 4. What we’d like support’s input on Is Adjustable time step + Maximal Courant number the correct/recommended fix for a localized Courant spike like this on an AMI case, or is there a more targeted mesh-side fix we should prioritize instead (e.g., specifically coarsening the boundary layer only at the trailing edge, rather than accepting a globally variable timestep)? Given our Community-plan quota constraint (3 runs remaining) , is there a lower-cost way to verify a fix like this without spending a full run — e.g., a short diagnostic mode, or guidance on reading intermediate logs/Courant behavior without letting a run go to significant core-hour cost first? Why do both the mesh cell-count estimate and the run duration/compute estimate diverge so significantly (10x+) from actual results on this AMI case specifically, when the same tools were reasonably accurate for our earlier MRF steady-state run in this same project? Is this a known limitation for sliding-mesh/AMI cases, or does our specific geometry/mesh trigger it? Any guidance on appropriate boundary-layer settings for a thin (~20% t/c), tapered trailing-edge blade in a rotating-zone context, to avoid producing the very small (~45–105 micron) near-wall cells implicated in the Courant spike, while still adequately resolving the boundary layer for accurate torque/lift prediction. 5. Reference numbers, for support’s convenience Quantity Value Final validated mesh cell count 4,956,801 Final mesh non-orthogonality (avg / max) 30.8° / 75.8° Prism min edge length 4.55e-05 – 1.05e-04 m Rotor angular velocity −31.42 rad/s (confirmed via MRF torque sign) Design rpm 300 Δt (fixed, failed run) 0.001 s End time (failed run) 1.0 s (5 revolutions) Cancelled run progress 26% (~0.52s / 2.6 revolutions) Cancelled run cost 415 min, 55.43 core hours Estimated cost (same config, pre-run) 65–97 min, 8.6–13.0 core hours Community plan simulation slots remaining 3 of 10