ImperialCollegeLondon / ImperialCollegeLondon/sharpy
(mostly) velocities in *grid.py - rigid body velocity (linear and angular) contributions of strip/non-lifting surfaces
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 191
- Forks
- 69
- PR merge metrics
- No merged PRs in 30d
Description
I guess this bit is quite related to the original generate_zeta_timestep_info in aerogrid.py - in there I realised the rigid body velocity (linear and angular) for the most general expression for the strip velocities were missing (in eq 54 in screenshot attached).
Specifically here, it seems that in line 92, matrix_nodes used was already inclusive of the rigid body position -> effectively it's the strip coordinates in G frame already (as processed in line 85) - but then we premultiply with another Cga afterwards in line 96 - possible typo?
Originally posted by @kccwing in https://github.com/ImperialCollegeLondon/sharpy/pull/249#discussion_r1317051044
creating this to document future development/verification effort required - two sources of rigid body (translational and rotational) velocities in nonliftinggrid/aerogrid.py, and also in unsteady/unsteady_utils.h (compute_resultant_grid_velocity) - how to reconcile the differences? which velocity is included where?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing rigid-body velocity handling in grid.py and nonliftinggrid/aerogrid.py with generate_zeta_timestep_info in aerogrid.py and compute_resultant_grid_velocity in unsteady/unsteady_utils.h. Trace which translational and rotational contributions each path includes and reconcile their differences. Done means the intended velocity definition and any required verification are documented and consistently represented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100