Open JurajCe opened 7 months 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
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.
@peterdsharpe @JurajCe Thank you for the explanation of this problem. Anyway, which version or commit has a control surfaces? I can't find it. thank you
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
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
System Information