Help! Meshing for Wing&Fuselage and the interpretation of VSPAero result.

[Zhenhao Li]

Good morning everyone,

  I am currently using OpenVSP for a conceptual design project and intend to use VSPAero for preliminary aerodynamic analysis. I am running VSPAero with a mixed setting—using a thick-thin combination for the wings and fuselage—but I have encountered some problems.

1. For now, I am using CLi and CLiw as diagnostic metrics; I assume that the magnitude of the difference between them indicates the level of inaccuracy in the results (or, more fundamentally, issues with the mesh settings). Is this a reasonable judgment? Furthermore, is there a 'gold standard' to aim for? For instance, should |CLi-CLiw| be below a specific threshold?

2.  In a wing-alone simulation, the results for CLi and CLiw are nearly identical. However, after adding the fuselage, CLi becomes significantly higher than CLiw (as shown below). Despite remeshing the wing and fuselage multiple times, the trend remains consistent, with the near-field data being higher. What does this trend tell us?

3. Aware that the problem might stem from the fuselage or mesh settings, I reviewed several workshop videos and forum threads. One specific concern is whether the fuselage modeling should follow the same rules as blunt-trailing-edge wings in panel codes. Specifically, should I be modeling the fuselage with a sharp trailing edge to satisfy the Kutta condition?

4. Regarding the mesh, I attempted to match the wing and fuselage nodes at the wing root. I set the tessellation to approximately the same density for both components; specifically, I created a fuselage section aligned with the wing and applied matching clustering settings. Despite these efforts, the grid lines still do not align perfectly. This is shown below in the diagram, and the model is attached in BASELINE-align: (Both tessels set to 33 and with LE, TE, fwd., aft. clustering all set to 0.25)

5. Another observation is that when the fuselage mesh is highly refined (using a large number of tessellations), VSPAERO generates triangular elements at the intersection region. These cases often lead to non-convergent results. Should these triangular meshes be avoided, and what is the proper way to configure the fuselage mesh? Are there specific rules of thumb for setting these parameters appropriately, such as some ratios of wing and fuselage tessellation? Or should I just reduce relaxation?

 

Thank you for reading these questions! Looking forward to any suggestions or answers. Again, thank you for your time and consideration!

Best,

Zhenhao

[Rob McDonald]

I would not equate similarity of CLiw / CLi with quality of the solution.

OpenVSP only applies a Kutta condition to lifting surfaces (wing, prop, and some BOR with airfoil sections).  It will never apply a wake to a Fuselage or a Stack.

I would not recommend you super-refine the fuselage at the wing/body join.  In particular, your approaches result in a rapid panel size change on the fuselage before the LE and after the TE -- I would encourage you to try for a more uniform mesh down the fuselage.

Because of the leading edge curvature, the thin surface representation is automatically clustered at the leading edge.  Consequently, when using clustering, you end up with super-clustering at the LE.  Consequently, I recommend you back off on the LE clustering.  Instead of the default of 0.25, use 0.5 or even 1.0.

Since you have a cambered wing that is aligned with the center line of the fuselage, you have some challenging panels under the wing at the side of the fuselage.  Since your fuselage is a body of revolution, rotating it by 12.5 degrees about X shifts the mesh so there is no mesh line that nearly coincides with the wing.

You have a cylindrical section of the fuselage at the wing-body join.  This will be a challenge.  The first wake line may have a tendency to go inside the body.  This is made worse because you forced an interior wing section whose boundary is nearly exactly at the side of body.  Ditch the interior wing panel and adjust the geometry to still recover your wing planform.  Then adjust the mesh such that you don't have sliver elements at the wing-body join.

With these changes, I get something like this...

Rob

[Zhenhao Li]

Thanks, Rob! These are really valuable suggestions!

How can we assess the quality of the results? And for the differences widely observed between the far and near field solutions, which one is more credible for a trimmed flight condition analysis? Say for a L/D estimation.

Also, for a sanity check, for the fuselage section near the wing, we should avoid the mesh line of the fuselage to align with the chamber line of the wing. Also, using a more spaced but uniform meshing setting could leads a more solid solution. But I wonder if there is a specific ratio or size of the mesh we should aim for?

Thank you for your help and time!

Best

Zhenhao

[Brandon Litherland]

The quality of the results will depend on what you need.  If you judge quality by the level of convergence in the solution, similar to more traditional CFD methods for validation cases, then the residual will be your metric.  On the other hand, if you are trying to recreate the performance of a known aircraft or wind tunnel experiment, then the solution quality will depend on how closely you can recreate that data.

See Rob's explanation of wake vs KJ methods in a previous post here: https://groups.google.com/g/openvsp/c/XTCCGReL7AI/m/e9Thx1rgAgAJ
There are others as well.

As for the spacing, tessellation, etc., the best arrangement will be the one that gives you the better answer as above.  Some will first find an appropriate chordwise setting (solution starts to change very little) and then work on the spanwise direction.  However, because you can "optimize" your resolution in a variety of ways with clustering and NumU/W, it's a fairly difficult task to run this manually.  Starting with a uniform chord distribution and clustering a bit tighter at the wingtip to better capture downwash is a good start.  But you will likely find that you can adjust these settings to produce a better solution, whatever that means to you.  My suggestion is that VSPAERO simulations are so fast and inexpensive to run, that you can make adjustments fairly quickly and go ahead with solving your problem.