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.
Implementation of time-marching scheme
Dear David,
In the guidelines three options for velocity integration are found, as attached to this post. I tend to doubt the implementation as described in the guidelines. That is, the PC algorithm exhibits an implicit character, which usually is solved by iterating of some sort. However, I think it is highly unlikely to iterate over the computationally costly velocity induction function.
A more logical implementation would be that in the 2nd equation, last term on RHS i.e. V_ind(x_{i+1}) is changed to for example V_ind(x_{i+1,EF}). This makes it somewhat psuedoimplicit, a term that is also frequently found in the Leishman papers.
Is this correct, or does QBlade really iterate because it is an implicit scheme?
Uploaded files:- You need to login to have access to uploads.
Hi,
you are indeed correct, the predicted V_ind(x_{i+1}) velocity is obtained by 1st order Euler Forward integration. So this scheme in fact requires two full evaluations if the induced velicities at the wake node positions for each timestep.
BR,
David
Do you have any tips on when to use what scheme? I can imagine that with high thrust or high TSR simulations some form of stability in the numerical scheme is preferred.
Best,
Luc
Hi Luc,
in general, prefer using the simple, computationally efficient EF 1st order scheme. Since the velocity integration only affects the forward propagation of the vortex elements it doesn’t impact the stability of the simulation.
Based on my experience, for the commonly used timestep size (~3° rotor advancement) I found the accuracy of the EF integration to be satisfactory in almost any case.
BR,
David
