Wing chord glitch

135 views
Skip to first unread message

C.P.

unread,
May 21, 2025, 11:10:23 AM5/21/25
to OpenVSP
Greetings,

I have noticed a weird glitch/bug in this randomly generated wing. The root chord is by default at around 1.79m. As you can see the wing is totally broken. The chord has resulted in a very small edge.

Changing the chord length to below 1.77 and above 1.81 fixes the chord airfoil to a normal-looking wing.

What kind of sorcery is going on? Is this logical?
-
Chris
wing_6250.vsp3

Rob McDonald

unread,
May 21, 2025, 12:29:39 PM5/21/25
to OpenVSP
Looks like a bug...

It also goes away if I change the airfoil type to not-a-file airfoil.
I'll see what I can figure out.

Rob

C.P.

unread,
Jun 11, 2025, 5:14:46 AM6/11/25
to OpenVSP
Hey Rob,

Found one more weird wing, this time regarding the tip chord. 
It seems that you can fix this in multiple ways:
  1. Changing the chord tip a bit (going from 0.605 to 0.62 or going to 0.59)
  2. Increasing the airfoil thickness
  3. Changing the trailing edge cut, in relative mode, to either 0.004 or 0.006. This is weird to me.
Aside from being curious about what is causing that, I'm interested in knowing if there is a way to "catch" those cases using the Python API. We are currently utilizing OpenVSP in a large-scale pipeline (see:  An Automated Framework for Streamlined CFD-Based Design and Optimization of Fixed-Wing UAV Wings ) that performs automatic CFD on UAV wings. Therefore, it is of utmost importance to us to identify this issue early and avoid wasting resources on meshing and CFD.

Thanks in advance,
Chris
wing_7569.vsp3

Rob McDonald

unread,
Jun 25, 2025, 8:02:36 PM6/25/25
to OpenVSP
In both of these cases, the same underlying problem is happening.

You're trimming the airfoil TE by specifying a target thickness (THICK mode instead of X).  This causes OpenVSP to run a Newtons Method solver to find the chord that corresponds to the target thickness.

I believe the problem is exacerbated by the fact that your airfoils have a cusped trailing edge.

Instead of finding the target t/c near the trailing edge, the solver is finding an alternate solution near the leading edge.  This is of course not what is desired.

I'll see if I can make the solver more robust to this sort of thing.

In the immediate term, as a workaround, you could also consider using X trimming instead of THICK.  That should avoid this issue entirely.

Rob

Rob McDonald

unread,
Jun 25, 2025, 11:50:50 PM6/25/25
to OpenVSP
I've got a fix that will go into the next release.  Hopefully that takes care of this for you.

Rob
Reply all
Reply to author
Forward
0 new messages