Forum
Important Notice for New User Registrations
To combat an increasing number of spam and bot registrations, we now manually approve all new user registrations. While this may cause a delay until your account is approved, this step is essential to ensure the quality and security of this forum.
To help us verify your registration as legitimate, please use a clear name as user name or an official email address (such as a work, university, or similar address). If you’re concerned that we may not recognize your registration as non-spam, feel free to email us at with a request to approve your username.
Simulation crashing: Wake blow up, filament with pos > 1e5 found!
Hello!
My team and I are engineering students in the process of simulating a three-bladed H-rotor for our design team. An issue I am encountering with my current simulations is that whenever I run it, this error is returned:
Wake blow up, filament with pos > 1e5 found!
The simulation file with detailed specs is attached below. Please let us know if there is anything significant that we may have overlooked which is causing this outcome!
Thanks!
Uploaded files:- You need to login to have access to uploads.
Hi Alina,
In your case, the wake blow-up is caused by a vortex core size that is too small for the free-wake vortices. With an overly small core radius, induced velocities become unrealistically large when wake filaments pass close to each other, which can eject a filament to extreme coordinates (pos > 1e5) and trigger this error.
This can be fixed by increasing the free wake vortex core size (you are using 0.02c at the moment).
Besides, the rotor you are modeling is particularly challenging to model aerodynamically:
- The rotor is high-solidity. With 3 blades, chord ≈ 0.4 m and radius ≈ 0.5 m, the solidity is about σ ≈ 0.38, which is well into the high-solidity regime.
- The chord-to-radius ratio is very large (c/R ≈ 0.8), leading to very strong induction and intense blade-wake interaction.
- The blade aspect ratio is low (H/c ≈ 2.5), so 3D effects and deep stall dominate large parts of the rotation.
- Large azimuthal regions operate in dynamic stall, producing strong, rapidly varying vorticity that makes free-wake models especially sensitive to numerical settings.
- Overlapping bound vortex elements from the struts at r=0
This rotor concept is not expected to produce significant power in practice. High-solidity H-rotors typically operate at very low tip-speed ratios, where large portions of the blades are in deep stall for most of the revolution. Combined with the very large struts (chord ≈ 0.2 m, i.e. ~50% of the blade chord), the parasitic drag losses are substantial and can easily dominate any useful aerodynamic torque. As a result, even if the wake is numerically stabilized, the achievable power coefficient will be low and the solution will remain highly sensitive to numerical and modeling parameters.
I would suggest to significantly reduce the blade chord. Also, make sure that the struts dont end at r=0, to avoid panel overlap.
BR,
David
Hi David!
Thank you for the detailed explanation! We tried running the same rotor configuration with the blade chord reduced by half, and in that case the free‑wake simulation produced stable results with positive torque and a reasonable Cp. These results also aligned fairly well with our DMS predictions, which was encouraging.
However, in our DMS analysis, the higher chord value actually showed higher power and Cp, whereas the free‑wake simulation for that same configuration became unstable and produced negative power. Are these differences mainly because the DMS model does not capture the same instabilities? We want to better understand why the DMS predicts acceptable performance while the free‑wake simulation becomes problematic.
Thanks again for your guidance!
Kind regards,
Alina
Hi Alina,
In the current QB 2.0.9.6 release, the DMS algorithm in QBlade has significant convergence issues, especially for high-solidity turbines.
As a result, you should not rely on the DMS results in this case.
Instead, use the free vortex wake method, which explicitly resolves wake dynamics over time and provides reliable results here.
These DMS convergence issues have been fixed in the upcoming release 2.0.9.7, which will be available soon.
Best regards,
David
