VSPAero Output Variable Query

[Klarisse Ng]

Hello All, 

I have been using OpenVSP for a research project. Upon installing the latest version, 3.46.0, I noticed that new output variables have been added compared to the older 3.42.3 version, notably variables with the subscript "w", such as "L/D" and "L/Dw", "CDtot" and "CDwtot", as well as "CLtot" and "CLwtot". 

Since the updates, I noticed a difference in values with "w" and without "w". I understand that the “w” terms in the results correspond to the wake-integrated solution results as opposed to the results by solving the Kutta-Joukowski Theorem. 

May I check on the explanation behind these two methods, as well as why they would differ? Thank you!

[Rob McDonald]

VSPAERO panels (either thick or thin) are constructed from vortex rings (which is equivalent to a constant strength doublet panel).  So the KJ approach directly computes the force on each vortex segment, summing across the entire body (a discrete surface integral).

The wake formulation instead considers the vorticity shed from the trailing edge into the wake, summing across the wake attachment lines (a discrete line integral).  This is similar to a Trefftz formulation used in many other panel codes.

Most potential flow codes (both 2D and 3D) have two analogous ways of integrating inviscid forces.  I'll talk in terms of a textbook 2D panel code just to simplify things...

In a 2D code, you can compute lift by either:

1) Computing Cp for every panel and integrating the forces.

2) Compute the vorticity jump at the TE point.

The accuracy of method 1) requires that the Cp distribution is accurately predicted -- and it also requires that you have sufficient resolution to accurately integrate the forces.

An interesting exercise is to start with an analytical solution (typically from conformal transformations) for a lifting airfoil (say Jukowski or Von Karman Trefftz).  You have an analytical expression for the airfoil shape and for the Cp distribution -- pretend like this is a perfect potential flow solution.  Then, discretize the airfoil (to say 50 panels, clustered as you see fit).  Then, evaluate the analytical Cp distribution at those 50 points and calculate the discrete approximation of the lift force -- compare that to the analytical solution for lift.  What you'll find is that even with a perfect flow solution (Cp distribution), the discrete surface integral needs pretty fine resolution to accurately capture force and moment.  Often, this requires finer resolution than you need from a wake formulation.

Part of the magic of potential flow theory is all the things that it captures implicitly through the formulation (i.e. independent of the discretization and the numerical method).

The best example of this is the boundary condition at infinity.  In finite volume or finite difference CFD, you not only need to resolve (make a volume grid) of the domain surrounding the body, the quality of your solution depends on how far away you place the 'far field' boundary.  In 2D, computations are cheap, so you'll probably see guidelines to place the outer boundary 10-100 chord lengths away (depending on what you're trying to accomplish).  In 3D, things are a lot more expensive, so you'll probably be thrilled to put the outer boundary 5-10 wingspans away.  Careful practitioners will conduct tests to convince themselves that they've placed their outer boundary far enough away to approximate the far field condition with sufficient accuracy for their purposes.

In an external flow code based on potential flow theory, the boundary at infinity is satisfied exactly.  Always.  Without trying.  Without even having a volume mesh.  Without even having to place a far field boundary anywhere.  Even for a solution that is poorly resolved and not run to convergence -- the far field behavior is satisfied exactly.  It is like magic. 

Using method 2) to calculate forces in a 2D code often boils down to simply reading one of the values from the solution matrix -- i.e. if the code is set up as a system of linear equations Ax=b, x[N] might actually be the lift coefficient.  Or sometimes it is x[N]-x[N-1].

This means that the lift is calculated as a part of the core solution to the flow -- not through a bunch of post-processing steps performed later.  It is as if the solution computes the momentum imparted on the flow as a part of the basic solution.  We simply choose to use that result instead of inferring the loads by summing a bunch of pressures and hoping everything comes together accurately.

The bottom line is that a wake formulation for loads will generally converge sooner (in terms of a grid resolution study -- i.e. at a coarser mesh) than a surface integral approach.  So, in general, it is preferred to use the wake forces.

Unfortunately, there are some complications...

The wake type approaches generally can't calculate moment (only forces).  Their formulation for unsteady flow is either more complex -- or doesn't work at all.  There are some other situations where they don't work.

So, pretty much every potential flow code will perform both computations and report them both.  It is up to an experienced user to decide when they need to use each one.

Rob

[Klarisse Ng]

Hi Mr McDonald, 

Thank you for your reply! Could I check what a suitably fine resolution would be? Currently, I divide the wingspan by 1.5 to get the value of Num U cells. 

Additionally, I was also wondering how the number of wake nodes would affect the results of VSPAero. I understand that wake nodes are run in powers of 2, and a paper states that a greater number of wake nodes would increase the stability of the solution. 

Thank you again for your kind attention. 

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openvsp/00415f8b-b657-4782-a352-59dc9d910f61n%40googlegroups.com.

[Brandon Litherland]

The W resolution, both in NumW and LE/TE clustering, will depend on your geometry.  There isn't really a fixed solution for "good enough". That's up to you to decide.  Some high-fidelity CFD folks will chase 10^-9 convergence of a solution for days compared to getting a close-enough solution very quickly if you don't need an exact answer.  You may find that your NumU starts to have diminishing returns on solution change/accuracy beyond 20 or so spanwise stations.  In some cases, with large spanwise gradients or with blown wings, you'll need more.  Similarly, you may find that your solution is relatively insensitive to the number of wake nodes for a steady run but requires more for unsteady runs.  The slides and video are a bit dated now but the 2021 OpenVSP Workshop page (https://openvsp.org/wiki/doku.php?id=workshop2021) has a presentation and recording for VSPAERO best practices if you'd like a place to start.

You could also find that your answers to these questions change between thin and thick modes. 

Take some time to get to know your model behavior using some of the information above and let us know how it goes!

[Rob McDonald]

The number of wake nodes does not need to be a power of 2 in 3.45.0+.

The number of wake nodes required depends on the complexity of the wake structure.  For a simple wake, a small number is plenty.  If your wake interacts with downstream bodies, has significant turning, is involved with an actuator disk or a rotating blade, etc. then you'll need more wake points.  For an isolated wing in a relatively benign flight condition, you don't need many.

Rob

[Steven Zhu]

Hi, and thanks for the discussion so far.
I’m wondering about one specific case. If an actuator disk is in front of a wing, will the wake-based force integration still give the correct forces on the wing? The wake becomes quite complex, but in principle, does the wake integration still reflect the “true” forces on the wing?

Thanks!

[Rob McDonald]

Yes, the wake integration should still work in the case of an actuator disk in front of the wing.

Rob