Static Trim Routine Fails with Dynamic-Type Control Surfaces

[p-smith22]

The problem I am experiencing right now is the same one that has been documented as an issue previously. When setting a control surface to type 1 (dynamic), the static trim routine fails. In the original post, they state that this can be bypassed by initializing to static trim using the static control surfaces, then switching to dynamic at static coupled and continuing the simulation. I was wondering if this issue was fixed (ie- there is some other way to do it to avoid this error), and if not, if you had any clarification on how to switch from static to dynamic halfway through the flow sequence.

Currently, I am using two flow sequences that get called into the generate_solver() function separately, but this seems inadequate. With this method, the code either generates two separate .shapry solver files, or overwrites the first one during the second function call.

I understand that I have to switch from static to dynamic halfway through and I understand the concept of why, but I was just hoping to get some clarification or guidance on this issue. I could not find any documented examples that used the dynamic control surfaces, so I figured I might find some help here.

Thank you!

[kccwing]

Hello - sorry for the late reply. What @ngoiz meant in issue #122 was that you could firstly run a static trim routine and set the control surface type to static - then once you obtain the correct trim value, start another instance of sharpy, with static coupled as solver this time, with the trim value as initial value for the control surface, and continue with dynamic input.

[p-smith22]

Thank you for the reply. So would my second instance of sharpy have the following flow?
flow = ['BeamLoader', 'AerogridLoader', # 'NonLinearStatic', # 'StaticUvlm', # 'StaticTrim', 'StaticCoupled', 'BeamLoads', 'AerogridPlot', 'BeamPlot', 'DynamicCoupled', # 'Modal', # 'LinearAssember', # 'AsymptoticStability', ]

I am getting the first instance to run, and I used np.genfromtxt( ) to get the values from the static trim .txt file. Would I then run the above flow with just my deflection file altered with the new deflection trim values as the first few iterations for the new instance, or would I use
settings['StaticTrim'] = {'save_info':True, 'solver': 'StaticCoupled', 'solver_settings': settings['StaticCoupled'], 'initial_alpha': angle, 'initial_deflection': deflection, 'initial_thrust': force}
To input values back into the dynamic instance? I guess I am just confused on how to get the dynamic inputs to work. When I try to former option, it begins to run but fails after ~90 runs due to divergence. If I try the former (and put StaticTrim back in the flow), it predictably runs the static trim again with the corrected initial values, but still fails the routine.

[p-smith22]

Should the first iteration (with static type control surfaces) be run with a different solver other than StaticCoupled?

[ben-l-p]

You are correct:

• The first instance of SHARPy should be run with StaticTrim (StaticCoupled used as the underlying solver), recover the alpha, control surface deflection and thrust values required for trimmed flight. This can have static control surfaces.

• The second instance of SHARPy can have these as inputs for your StaticCoupled/DynamicCoupled cases. You don't need to run trim on your second instance, and so it can run with dynamic control surfaces, initialised at the trim values.

The initial parameters in the DynamicCoupled case are not set using parameters of the names you have stated above:

• Alpha is set using the orientation parameter in the BeamLoader.
• The initial deflection is set in AeroGridLoader
• The thrust can be set as a constant follower force mapped to the beam in the app_forces array in the FEM file

[p-smith22]

It seems to work now. Thank you!