Free-flying aircraft that translates and rotates about the center of gravity (rotating frame + translation)

[ArneVoss]

Proposed Changes

Give a brief overview of your contribution here in a few sentences.

Currently, the dynamic mesh module allows either a translation or a rotation. The parameters involved are:
GRID_MOVEMENT= ROTATING_FRAME or TRANSLATION_RATE
MOTION_ORIGIN= x y z
ROTATION_RATE= p q r
TRANSLATION_RATE= u v w
The farfield MACH number is set to zero and MACH_MOTION is used instead.

For example, a pull-up maneuver of an aircraft could be calculated as a steady CFD simulation and by looping around a MOTION_ORIGIN far away from the aircraft as discussed here: https://www.cfd-online.com/Forums/su2/241889-rotating_frame-grid-velocity-correct-flow-physics-wrong.html. However, a combination of pull-up and roll or yaw is not possible because the roll/yaw would require a different MOTION_ORIGIN that the pull-up.

To simulate a free-flying aircraft (in a flight mechanical sense) which moves and rotates in all six degrees of freedom about the center of gravity, a combination of both translation and rotation is beneficial. In the proposed change, the ROTATING_FRAME now considers both parameters ROTATION_RATE and TRANSLATION_RATE given in the config file. Because the default translation rates are zero, there should be no effect for users who want pure rotation.

The option STEADY_TRANSLATION now appears obsolete to me because the functionality is included in the ROTATING_FRAME, but I didn't want to remove the code because someone else might use that parameter?

Related Work

Resolve any issues (bug fix or feature request), note any related PRs, or mention interactions with the work of others, if any.

This is a follow-up of a discussion here: https://www.cfd-online.com/Forums/su2/241889-rotating_frame-grid-velocity-correct-flow-physics-wrong.html

Fix #1595 (https://github.com/su2code/SU2/issues/1588)](https://github.com/su2code/SU2/pull/1595/commits/c2018c836791944383c13d32dcfec903d5657072) is required to get proper nodal forces and has already been merged into the develop branch, thank you Pedro :)

PR Checklist

Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with the '-Wall -Wextra -Wno-unused-parameter -Wno-empty-body' compiler flags, or simply --warnlevel=2 when using meson).
• My contribution is commented and consistent with SU2 style.
• I have added a test case that demonstrates my contribution, if necessary.
• I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp) , if necessary.

[pcarruscag]

Awesome 👍. Can you add some info about this in the config_template (section on DYNAMIC MESH DEFINITION) + modify the test I added in (py_wrapper/translating_NACA0012) to exercise this feature. Then we're good to go :)

[pcarruscag]

Using just STEADY_TRANSLATION skips computing the rotating source terms, and all the GCL corrections.

[ArneVoss]

I am not sure if a 2D case is a good example / test case for the ROTATING_FRAME option, because the cross product makes only sense in the 3D case. For example, there is no pitch axis, the y-axis actually goes in z-direction and so on...

(By the way, I am on vacation the next days. I will be back in office next Monday.)

[pcarruscag]

Makes sense, but a 3D case might be too expensive to run.
The 2D would at least ensure the rotation and translation are being accounted for.

[ArneVoss]

I see that the test pywrapper_translating_naca0012 fails, maybe because the reference results calculated on my computer deviate slightly?

[pcarruscag]

Thanks for updating the testcase. Let's keep the non dimensionalization to make sure the python forces are still being computed properly in that case.
Yep small differences between local and github are common (compiler differences, etc.) you can take the github values to update the reference file.