Skip to content
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

WIP: Enh/estimate drag coefficients #112

Closed
wants to merge 10 commits into from

Conversation

Lucas-KB
Copy link
Contributor

Pull request type

Please check the type of change your PR introduces:

  • Code base additions (bugfix, features)
  • Code maintenance (refactoring, formatting, renaming, tests)
  • ReadMe, Docs and GitHub maintenance
  • Other (please describe):

Pull request checklist

Please check if your PR fulfills the following requirements, depending on the type of PR:

  • ReadMe, Docs and GitHub maintenance:

    • Spelling has been verified
    • Code docs are working correctly
  • Code base maintenance (refactoring, formatting, renaming):

    • Docs have been reviewed and added / updated if needed
    • Lint (black rocketpy) has passed locally and any fixes were made
    • All tests (pytest --runslow) have passed locally
  • Code base additions (for bug fixes / features):

    • Tests for the changes have been added
    • Docs have been reviewed and added / updated if needed
    • Lint (black rocketpy) has passed locally and any fixes were made
    • All tests (pytest --runslow) have passed locally

What is the current behavior?

The user has to provide a drag curve as a function of the Mach number.

What is the new behavior?

The user can supply additional rocket parameters instead of the curves themselves, but the old behavior can still be achieved.

Does this introduce a breaking change?

  • Yes
  • No

Other information

Lucas-KB and others added 8 commits September 26, 2021 16:52
Add method to calculate the viscous friction coefficient in Rocket class
to be used in the drag coefficient estimations. The calculations
required the addition of new parameters to `__init__`.
Added formulas for estimations of the drag coefficients regarding the fins and tail. Also, the method `evaluateForebodyDragCoefficient` still needs to be completed.
Now the drag coefficient estimation is supposedly finished, but testing
and validation is still needed.
Some issues with the code were corrected.
Add a new branch in the calculation to correct when Reynolds number is
less than 10^4.
The forebody drag coefficient was forgotten on the sum of all drag
coefficients. It is now fixed.
@Lucas-KB Lucas-KB changed the base branch from master to develop November 19, 2021 01:07
Comment on lines 369 to 370
reynolds = (
(self.air_density ** 2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Gui-FernandesBR pointed out that this should be:

Suggested change
reynolds = (
(self.air_density ** 2)
reynolds = (
(self.air_density)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We reviewed our references and I believe there is the square, because of an algebraic manipulation. The deduction can be seen below:

image

image

Substituting the values yields:

image

What do you think, @Gui-FernandesBR @giovaniceotto?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reynolds is a dimensionless quantity... Just change "kinematic" for "dyanamic" in the first image you've sent and it's going to work then, it's a honest and simple mistake.

https://en.wikipedia.org/wiki/Reynolds_number

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I still believe there is a slight error here. I hope this source, which has both formulas (using dynamic and kinematic viscosity) can help settle the debate: https://www.engineeringtoolbox.com/reynolds-number-d_237.html

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I understand now what is going on now, apparently our main reference had a typo on the definition of the Reynolds number and we just trusted it. Thank you both for pointing it out and helping us understand the problem. It will be fixed soon.

rocketpy/Rocket.py Outdated Show resolved Hide resolved
rocketpy/Rocket.py Outdated Show resolved Hide resolved
rocketpy/Rocket.py Outdated Show resolved Hide resolved
rocketpy/Rocket.py Outdated Show resolved Hide resolved
@Gui-FernandesBR
Copy link
Member

Hey @Lucas-KB and @lucasfourier , great to have such an interesting contributions from you guys.

I made some commetns in order to help your review before pulling the code to the develop branch, can't wait to see that happening!

Documentation was fixed and some lines of code were added to make sure plots worked fine.
@Lucas-KB Lucas-KB marked this pull request as ready for review November 20, 2021 21:29
Copy link
Member

@Gui-FernandesBR Gui-FernandesBR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some comments on some files, but I believe it accomplished with your initial goals so congratulations for this development. Hope you can commit again soon

@@ -174,7 +188,7 @@ def tests_export_eng_asserts_exported_values_correct(solid_motor):
"0",
"{:2.3}".format(grain_mass),
"{:2.3}".format(grain_mass),
"RocketPy"
"RocketPy",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should that comma exist? I believe it was created automatically, but I'm concerned if this going to create a bug or not. @Lucas-KB @lucasfourier


# In the formula, instead of span, it should be the distance between the
# midpoint of the root and the tip of the fin, but we are using
# span for now.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you consider a right-trapezoid, it should be sqrt(span² + (Rc - tc)²/4). If you want to be more abstract, could get the angle bettwen span and rocket axis and use it on the law of cosines.

In my opinion, you don't need to make this correction on the code, I'm approving the pull request with the current approach. My point here is that it's not so hard to determine the distance you said, I think it's just about geometry. Reccomend save this idea for later.

@giovaniceotto
Copy link
Member

Quick question. Is this implementation compatible with rockets which have multiple "tails" (which may actually be diameter variation) and multiple fin sets?

@Gui-FernandesBR
Copy link
Member

As I just made with #110, I suggest merging this PR and then start another to (1) create the examples and (2) better documation, if the plan is still to do do 1 and 2 before merging.

@giovaniceotto sorry, I took a look but I can't answer your last question precisally. @Lucas-KB may know it.

@Gui-FernandesBR Gui-FernandesBR added the Enhancement New feature or request, including adjustments in current codes label Jan 31, 2022
@Gui-FernandesBR Gui-FernandesBR added NewFeature and removed Enhancement New feature or request, including adjustments in current codes labels Feb 18, 2022
@Gui-FernandesBR Gui-FernandesBR changed the title Enh/estimate drag coefficients WIP: Enh/estimate drag coefficients Feb 20, 2022
@Gui-FernandesBR
Copy link
Member

TODO (@Lucas-KB & @lucasfourier):

  • Start varying angle of attack during the evaluation of drag coefficient
  • Standardize the reference area (the problem of using rocket area to adjust the Cd)
  • Correct geometric parameters for the fins
  • Implement Rail Button (launch lug) drag
  • Study decorated functions

@Gui-FernandesBR Gui-FernandesBR requested review from MateusStano and removed request for giovaniceotto June 13, 2022 14:01
@Gui-FernandesBR
Copy link
Member

Gui-FernandesBR commented Jun 21, 2022

I'm quoting @MateusStano here : (automatic translated through google translate)

Guys, just talking about the PR of the Drag Coefficient calculation. Basically what had been done there were some functions to calculate the drag. Functions are basically implementations of formulas. Furthermore, the functions are implemented in a provisional way and in the current state of the code it is not possible to define a Rocket object. Another thing is that the results are different from what was expected (comparing to rasAero for example).
I would say that since we know the results of the drag calculations are not satisfactory (or different from rasAero) and since we don't know why, PR is not ready for Merge. For it become ready for merge I would say that we would have to do a review of the whole theory so we can start to understand the old code and find what is wrong (or not) in it. Honestly, I would say that the best thing would be to just redo the PR from scratch and that would take a long time. I don't think it's feasible to merge PR now and maybe the best thing is just to close it

@giovaniceotto
Copy link
Member

Getting this PR back online will be no easy task. That being said, I do not believe closing it as a viable option.

We need someone to take over the great work left by @Lucas-KB and @lucasfourier.
I truly believe it is more a challenge of manpower rather then technical dificulties. So let's go find someone who could help!

@Gui-FernandesBR
Copy link
Member

Getting this PR back online will be no easy task. That being said, I do not believe closing it as a viable option.

We need someone to take over the great work left by @Lucas-KB and @lucasfourier. I truly believe it is more a challenge of manpower rather then technical dificulties. So let's go find someone who could help!

Yeah agreed on that. I think it would be good if we could convert it to a draft PR since the code is not finished yet. But I'm afraid only @Lucas-KB can perform such conversion.

Also, I think we need not only new people to work on aerodynamic developments but also need to improve our development and integration process. Similar to Environment Analysis, we should list all implementations before start cododing, and try our best to separate everything into small pull requests so it can be better managed.

@Gui-FernandesBR
Copy link
Member

Thinking again, there's no problem if we close the PR since github will still remain information regarding everything. There's a difference between closing and deleting.

The only thing we must me carefull is that we should not delete head branch!

Therefore I believe we should go ahead and close the PR in the next few days

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants