CDi becomes negative when using a canard

102 views
Skip to first unread message

Luka

unread,
Sep 17, 2021, 3:08:41 AM9/17/21
to OpenVSP
Hi to all,

ever since the new VSPAero module was rolled out with the new OpenVSP version, I've been getting (in some cases) very odd CDi values.

I'm testing a canard-wing configuration. When testing the wing with the panel method, I get values which make sense.

Introducing a canard increases the CL (using the same reference area) and CD0, as expected, but changes the CDi from 0.00514 to -0.00355.

The main question I have is what could be the reasoning behind these negative values? I understand I can use the VLM method and this does not produce negative values, but this explanation is not sufficient, as I would like to understand why this happens.

Also important to note, this never happened to me with previous versions.

When performing the same analysis with the 3.24.0 version, I get a reasonable increase in CDi to 0.0067.

Attached pictures below are from 3.25.0, with the CP graph adjusted to show the same scale. No visible differences to explain the difference.

I've also attached both files. If you can, try it with the old version as well to see the effects.

Wing_only.PNGCanard-wing.PNG

Thanks and kind regards,
Luka
H1_KD.vsp3
H1_D.vsp3

Brandon Litherland

unread,
Sep 17, 2021, 11:08:34 AM9/17/21
to OpenVSP
Dave Kinney or Rob could provide more information but I'll try to pass along what might help.
For neither Panel or VLM mode are the CPs or dCPs used to calculate forces and moments directly.  They are more for understanding the distributions or to export for other purposes, if needed.  You should look at the convergence of CL, CDi, and L/D independently instead to get an idea of how well the solution is behaving.  The forces are backed out using the Kutta-Joukowski theorem, reported as CDi in the latest version, and there is also a CDi from the wake solution using a trailing edge algorithm (similar to Trefftz) and compare them for steady flow.

Brandon Litherland

unread,
Sep 17, 2021, 12:03:23 PM9/17/21
to OpenVSP
After some tweaking I've got the lift distribution looking better but the cd*cl/cref is still showing negative buckets that are driving the induced to be negative.
Add some round caps to the tips of your wings.  This will eliminate the extra wakes being attached on the upper surface of the tip airfoil.  Set root caps to None.  This will eliminate the distribution peaks at the root.  Also, you can try setting the z-offset to zero.  There have been posts here about shifting Z causing some issues in panel mode.  Dave is aware of this and is working it out.  

I'm not sure where the CDi buckets are coming from since they are present even if you run the wing or canard in isolation.  The solution convergence looks really good so it must be something on the back end where the forces and moments are being integrated and totaled.  Probably just a hiccup in the code that will get worked out shortly.  It could also very well be the case that VSPAERO Panel mode works just fine on Dave's Linux system and the issues have to do with running Windows or Mac.  Building and testing on these systems, particularly as several updates to OSs keep happening quickly, is difficult when each of the developers are largely volunteering their time to implement fixes and keep things up to date.  I digress.

Anyway, if you must run in Panel mode (which for a simple case like this you really shouldn't) I suggest reverting to 3.24 for those runs.  In the meantime, we will keep working on pushing updates and fixes to new versions of VSP as always to try and keep it running smooth and providing reliable results.

deenri...@gmail.com

unread,
Sep 17, 2021, 12:35:24 PM9/17/21
to OpenVSP
On 3.25
Just a caution/note, I performed the root/tip change on my model and my control surfaces U locations got changed. This probably isn't intended behavior. (?)

Brandon Litherland

unread,
Sep 17, 2021, 12:59:51 PM9/17/21
to OpenVSP
No. That's as expected.  I checked the KD version you posted here and didn't run with any control surfaces.
By removing the root caps, you move the number of U stations.  With a cap, the U=0 is along the camber line, then 0.333 is the root, 0.667 is the tip, and 1.0 is the tip camber.  Removing the cap sets the stations to root, tip, tip camber = 0.0, 0.5, 1.0. (For a single-section wing).  Rob is the expert here but the U and W parameterization of the surfaces treats each station as if it is equidistant from each other or as some "bin" of U or W.  What happens between those stations is controlled by the other parameters.  I think this has to do with how the splines are generated.  In any case, you'll run into the same issue if you have attachments in UW and insert/remove sections as well.  

Rob McDonald

unread,
Sep 17, 2021, 1:27:29 PM9/17/21
to ope...@googlegroups.com
I ran this by the VSPAERO developer.

He noticed that you have it set to only 16 wake nodes.  The default is 64.  You can set the entry to -1 and it will go with the default.

Changing that to -1 allowed it to converge to a positive CDi value.

Dave did mention that this case took a long time to converge (15 wake iters) -- I think that is likely because the canard wake is hitting the wing, so you might see faster convergence at higher / lower alpha.


The old TE based induced drag model was found to be wrong for unsteady wakes.  It also had problems with the panel solver and complex geometries.  That number is still reported as CDTrefftz off to the right of the *.history file.

The main loads calculations used to be based on interpolating velocities to edge centers.  The new version directly calculates velocities at edge centers for calculating loads.  This is more reliable.  The main CDi value is based on this calculation.

Rob



--
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 on the web visit https://groups.google.com/d/msgid/openvsp/a9a0a86e-d5fe-4aee-a476-781d7d7f8733n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages