Skip to content

Control Surfaces Deflections directly applied to WingXSecs | New Indexing System for points/faces in Wing Meshing #162

@ArthurLaneri05

Description

@ArthurLaneri05

Initial Context:

I was editing the vortex_lattice_method.py module to account for control surfaces deflections, with the ultimate goal of developing a module for NVLM/VPM, when I thought that it could be great to "bake" the control surface deflections directly into WingXSec.airfoil for each section.

In that way, it would be way easier to generate the thin wing mesh for VLM, to display the deflection when the wing gets drawn and to employ NeuralFoil to estimate viscous circulation for each section, an essential aspect of every nonlinear VLM code.

My proposal for WingXSec class modification:

My idea is to store a reference istance of the airfoil with no deflections applied, called self.airfoil_undeflected, then to execute the line self.airfoil = self.airfoil_undeflected.add_control_surface() whether the section is initialized inside a Wing object or the Wing.set_control_surface_deflections() method is called.
In that way all the meshing utilities will effectively just use the deflected version of the airfoil.

The limitations of this method arise when dealing with asymmetric control surfaces and symmetric wings, because in that case only one half of the wing gets explicitly generated.
A great workaround is to set the Wing.symmetric flag to false after all xsecs get explitcitly duplicated and mirrored during Wing initialization.
In this way it is sufficient to add the attribute .is_mirrored to the WingXSec class and to have it set to true in the mirrored copies. The flag can then be used to reverse the deflection value sent to add_control_surface() whenever the control surface gets actuated.

Image As it can be seen in the picture, I also enabled sharp discontinuities between sections with deflected control surfaces and adjacent, undeflected ones (or sections belonging to the other half of the wing as it is in this case). However, I won't go into the details of how I did that here.

P.S. A logical follow-up could be to edit the Airfoil.add_control_surface() method to account for LE control surfaces too.

My proposal for New Indexing System for points/faces in Wing Meshing:

A peculiarity of mesh management inside asb is the merge of points/faces belonging to different wing objects in a single stream of points and faces. This approach is indeed streamlined for displaying the mesh, however it becomes a strong limitation when, given a point on the list, it is desired to know which WingXSec the point belongs to. This task is especially vital in nonlinear VLM codes.

My proposal is to merge the points into a single list only in graphic applications, and instead go with 2D indexing for all the others. Consider a single wing object: a point p = np.array([x,y,z]) is accessed from the points array like this p = points[i,j] with i being the spanwise index of the point, and j the chordwise one.
To deal with Airplane objects containing more than one Wing it is sufficient to bundle all these arrays into one single list.

I'm aware that this last modification would lead to severe modifications to the code, but I'm afraid it is the only way to make AeroSandbox suitable for more advanced simulation types.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions