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 |