ImperialCollegeLondon / ImperialCollegeLondon/sharpy

(mostly) velocities in *grid.py - rigid body velocity (linear and angular) contributions of strip/non-lifting surfaces

Open
#256 0 comments 0 reactions 0 assignees View on GitHub

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?

Screenshot 2023-09-06 at 10 54 53 AM

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.