peterdsharpe / AeroSandbox

Aircraft design optimization made fast through modern automatic differentiation. Composable analysis tools for aerodynamics, propulsion, structures, trajectory design, and much more.
https://peterdsharpe.github.io/AeroSandbox/
MIT License
687 stars 111 forks source link

Control surface deflection is not working in the analysis #134

Open JurajCe opened 2 months ago

JurajCe commented 2 months ago

Bug Description / Observed Behavior

I am trying to simulate wing with deflected control surface. I tried to run both Cessna 152 example from airplane.py, and example of elevator from wing.py installed in AeroSandbox folder. It doesn't raise any exception or error. The problem is that deflection is not shown using .draw() function, and is not included in VLM analysis. I also tried my own geometry, but with no success.

Steps to Reproduce

import aerosandbox as asb

def control_surface_test():
    elevator = asb.ControlSurface(
                        name="Elevator",
                        deflection=30
                    )
    wing = asb.Wing(
        name="Horizontal Stabilizer",
        symmetric=True,
        xsecs=[
            asb.WingXSec(
                xyz_le=[0, 0, 0],
                chord=1,
                airfoil=asb.Airfoil("naca4412"),
                control_surfaces=[elevator]
            ),
            asb.WingXSec(
                xyz_le=[0.5, 2, 0],
                chord=0.5,
                airfoil=asb.Airfoil("naca4412"),
            )
        ]
    )

    wing.subdivide_sections(10).draw()

    op_point = asb.OperatingPoint(
        velocity=100,  # m/s
        alpha=0,  # degree
    )

    airplane = asb.Airplane(
        name="Elevator Test",
        xyz_ref=[0, 0, 0],
        wings=[wing]
    )

    print(asb.ControlSurface.__repr__(elevator))
    print(f'Control surface name: {wing.get_control_surface_names()}')
    print(f'Control surface area: {wing.control_surface_area()}')

    aero = asb.VortexLatticeMethod(
            airplane=airplane,
            op_point=op_point,
        ).run()
    print(f'CL: {aero["CL"]:.3f}, CD: {aero["CD"]:.4f}')

Expected Behavior

Airplane object is expected to have control surface deflected. Results are supposed to be different with different angle of control surface deflection.

My terminal output

ControlSurface (name=Elevator, symmetric=True, deflection=30, hinge_point=0.75)
Control surface name: ['Elevator']
Control surface area: 0.75
CL: 0.299, CD: 0.0051

System Information

ceto14 commented 1 week ago

Experienced a simillar issue with the AVL interface. I believe the error is in the _default_keystroke_file_contents function of the AVL(ExplicitAnalysis) Class. Line 379 adds the command f"d1 d1 1" to the list of commands to be executed by avl, where 1 is the magnitude of the control surface deflection to be taken into account by AVL analysis. After this the command "x" from line 229 in keystroke_file_contents variable tells AVL to execute the analysis with all the _default_keystroke_file_contents .

If you have just one control surface an easy fix is to modify line 379, where instead of 1, there should be the actual deflection of the control surface group control handle. If you have more control surfaces you should implement a for loop, but be careful how avl names the surface group handles (d1,d2,d3,...) For a bit more info this video shows how this would look like in the AVL gui: https://youtu.be/C0PJOxmrpY0?t=677

Overall looks like a substantial bug that should be addressed with the next package revision @peterdsharpe

peterdsharpe commented 3 days ago

Yes, control surface deflections are not yet included in the current implementation of asb.VortexLatticeMethod. This was implemented in previous AeroSandbox versions (roughly, major versions 1 and 2), but when VortexLatticeMethod was rewritten for AeroSandbox v3+ to preserve differentiability and continuity (which is needed for high-dimensional gradient-based optimization), the control surface modeling was not included. This is definitely possible to do, and will be done in the future, but I haven't had a need to port it over yet. For users that have both an immediate need for this capability and the resources to implement it, please feel welcome to submit a pull request.

In practice, the reason why including control surface deflections in asb.VortexLatticeMethod has not been a priority is that most trim studies lately use asb.AeroBuildup instead for aerodynamic modeling, which does include control surface deflection effects.


Re: AVL: d1 d1 1 is intended, since the magnitude of the control surface deflection is instead modeled in the gain parameter during the CONTROL blocks during aircraft geometry definition. All deflections are attached to d1, which is named "all_deflections" on the AVL side.

This allows the control surface deflections to be defined as part of the airplane geometry definition (i.e., the .avl file), rather than separately as part of the operating point (i.e., a .run file). Control surface deflections were implemented this way to simplify some of the file I/O, since only the .avl file is needed to define both the aircraft and control surface deflections -- this also maps on to how AeroSandbox stores control surface deflections as part of the aircraft data structure.

Alternatively, one could write a .run file and execute that, where control surfaces are part of this file. This maps more directly on how AVL intends for control surfaces to be implemented, and is probably better in the long run, but it involves a bit of extra work in the asb.AVL module. None of my immediate aircraft design projects are significantly affected this asb.AVL rework, so it may be awhile before I can take a look at it. However, once again, pull requests are welcome here.