-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Negative Spike in Lift Forces #27
Comments
@MOLOCH-dev Thanks for the bug report. As you pointed out, the negative lift spike is most likely a numerical issue. The plot from the README was from an unsteady simulation of a static (non-flapping) wing. This may be the reason we don't see such a negative spike. The last time I looked into this, I hit a dead-end and, unfortunately, became sidetracked with other bugs. However, I have a hunch about a potential culprit. During the first time step, there are a few things different from subsequent time steps:
|
Please let me know if you have any luck finding the bug or need help. While I'm a bit overwhelmed with work this week, I will take a look and report back what I find! |
@MOLOCH-dev Okay, I have some updates on this issue. I've ruled out the motion-induced velocity calculation as being the sole reason for this bug. This is because the negative lift spike still occurs in simulations with no motion. |
Also, I found a few reference plots to compare our results against: This case is something easily simulated in Ptera Software. The one catch is that Katz and Plotkin use a different method for calculating forces than I'm using. They use a modified version of Bernoulli's equation, whereas I use the unsteady Kutta-Joukowski equation. I've read a paper comparing the two approaches (referred to as the Katz method and the Joukowski method), and they generate extremely similar results for most converged simulations, but the transient lift might be different. However, I also found the following plot from a paper that uses the Joukowski method: As you can see, both examples show lift coefficients that begin at roughly positive infinity and then dip slightly lower than expected before finally asymptotically converging. This is the opposite of what we're seeing in our simulations. |
@MOLOCH-dev I just created a branch ("hotfix-3.0.1") for us to work on this issue. |
@MOLOCH-dev As a baseline, I created suddenly_accelerated_plate.py in a new directory, "issue testing." It runs a simulation identical to one of the simulations shown in the Katz and Plotkin figure. Here's what it looks like now: |
I believe the "unsteady_near_field_forces_geometry_axes" term in the UnsteadyRingVortexLatticeMethodSolver.calculate_near_field_forces_and_moments() method has the wrong sign. It should be negative (or the order of subtraction of the circulations needs to be changed). After correcting this, the force behavior is correct as shown in the plot below that attempts to replicate the above plots. The large positive peak at the initial instant is actually the correct behavior due to the large acceleration. As the aspect ratio increases the solution converges to Wagner's analytical solution. The fact that early on the agreement with Wagner is not perfect is also expected. If anyone is interested, here is recent paper that explains why this is the case. |
If the fix isn't obvious, checkout my hotfix branch. |
Bug Description
Thank you for this great software. @RaphZufferey and I am using it currently to analyse flapping flight with UVLM to incorporate Aeroelasticity effects. I observed an initial Negative spike in Lift Force after plotting results from Ptera. This spike makes no physical sense for a flapping wing, so I was wondering if this is a numerical issue that could potentially be solved.
Reproduction
Running the provided example
with the addition of
will reproduce the above results
Expected Behavior
No spike in the lift coefficient is observed in the README.
Desktop
Please complete the following information.
Additional Context
A similar issue was being discussed about a year ago here #17 . I am wondering if any resolution was achieved to the same or any work is in progress. I am open to picking up some work towards this issue as I have been making myself familiar with Ptera's UVLM solver.
The text was updated successfully, but these errors were encountered: