zero control surface deflection - loading and wake discontinuities
41 views
Skip to first unread message
Zach Hazen
Aug 21, 2025, 6:37:46 PMAug 21
to OpenVSP
3.45.2 Windows
Was experimenting with control surfaces on a simple RC slope soaring wing. Really appreciate the fixes to surface norms and control surface file naming on windows. I'm not sure if I am just feeding a poor mesh, or this could help with further VSPaero refinements.
This is a case with zero elevon deflection. I'm seeing non-physical wake (unless maybe leakage modeling under the hood?) and some cl spikes using thin surface analysis.
Totally open to this just being a skill issue. I can certainly add section breaks at the start/end of the elevons and cluster appropriately. I was trying to avoid having the panels align with the control surface.
Was experimenting with control surfaces on a simple RC slope soaring wing. Really appreciate the fixes to surface norms and control surface file naming on windows. I'm not sure if I am just feeding a poor mesh, or this could help with further VSPaero refinements.
This is a case with zero elevon deflection. I'm seeing non-physical wake (unless maybe leakage modeling under the hood?) and some cl spikes using thin surface analysis.
Totally open to this just being a skill issue. I can certainly add section breaks at the start/end of the elevons and cluster appropriately. I was trying to avoid having the panels align with the control surface.
Rob McDonald
Aug 21, 2025, 6:45:37 PMAug 21
to OpenVSP
I've noticed this sort of thing too.
I've previously assumed it was because of the mesh size jump and the general quality of the mesh around the edge of the control surface -- but maybe there is something there that can be fixed.
I'll mention it to Dave.
Unfortunately, even if the control surfaces are not deflected, they still get 'cut' into the mesh. This is good if you're calculating control surface derivatives, but a hassle if you just want clean non-deflected results.
We have the option to turn off control surfaces (in terms of communicating them to VSPAERO), but we don't use that information to avoid intersecting them.
When I added cutouts (for windows) to the visibility analysis, I needed to be able to selectively intersect subsurfaces. I could probably use that code to do that here too...
In the immediate term, you could copy/paste the wing, delete the SubSurfaces from the copy, and then use two Sets -- one with control surfaces and one without -- so you can quickly switch between analysis modes.
Rob
I've previously assumed it was because of the mesh size jump and the general quality of the mesh around the edge of the control surface -- but maybe there is something there that can be fixed.
I'll mention it to Dave.
Unfortunately, even if the control surfaces are not deflected, they still get 'cut' into the mesh. This is good if you're calculating control surface derivatives, but a hassle if you just want clean non-deflected results.
We have the option to turn off control surfaces (in terms of communicating them to VSPAERO), but we don't use that information to avoid intersecting them.
When I added cutouts (for windows) to the visibility analysis, I needed to be able to selectively intersect subsurfaces. I could probably use that code to do that here too...
In the immediate term, you could copy/paste the wing, delete the SubSurfaces from the copy, and then use two Sets -- one with control surfaces and one without -- so you can quickly switch between analysis modes.
Rob
Zach Hazen
Aug 21, 2025, 6:57:56 PMAug 21
to OpenVSP
OK - thanks for the quick reply. A "_noSubs" copy is a really easy workflow. Thanks.
Rob McDonald
Aug 22, 2025, 1:40:42 PMAug 22
to OpenVSP
I went back and forth with Dave a bit on this.
It looks like it is usually just a bookkeeping issue when the load distribution is calculated. The underlying Cp solutions usually look pretty good, and the artifacts just show up in the load distribution.
Sometimes OpenVSP creates some ugly tris at the tip of the control surfaces that do cause solution problems, but you'll usually be able to see when that happens.
The historical problem with aligning control surface edges perfectly with the mesh has mostly been fixed. So, the prior guidance to avoid that alignment might not be best anymore. Perfectly aligned control surface ends will look better when it comes to the load distribution plot.
Rob
It looks like it is usually just a bookkeeping issue when the load distribution is calculated. The underlying Cp solutions usually look pretty good, and the artifacts just show up in the load distribution.
Sometimes OpenVSP creates some ugly tris at the tip of the control surfaces that do cause solution problems, but you'll usually be able to see when that happens.
The historical problem with aligning control surface edges perfectly with the mesh has mostly been fixed. So, the prior guidance to avoid that alignment might not be best anymore. Perfectly aligned control surface ends will look better when it comes to the load distribution plot.
Rob
Reply all
Reply to author
Forward
0 new messages