ENH: Minor Improvements and Replacement of NoseCone.draw()

[MateusStano]

Pull request type

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

Pull request checklist

• 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?

Warnings are raised when they should not be and the draw() method is not in the aero_surfaces_plot.py file

What is the new behavior?

The warnings have been fixed by adding a special check to see if the nosecone is of elliptical shape, and the method has been moved to the correct place.

I've also improved the documentation a bit.

Does this introduce a breaking change?

• Yes
• No

Other information

Special thanks to @CabGT for doing all the hard work here.

[Gui-FernandesBR]

Overall a good PR,
I made some comments because I think it is worth to make small adjusts before following through

[Gui-FernandesBR]

If you call the draw() method N times, this will run the method N times as well,

Maybe some try/except or even properties and cached_properties would be beneficial here, what do you think?

To be more specific, I think we should retrieve only the coords, not invoke the evaluate_nose_shape method everytime.

[MateusStano]

This was done on purpose for a few reasons, but they are no longer valid because of the length change that the blufness generates.

Removed this line in e847406

[Gui-FernandesBR]

So, if the length of the NoseCone is being modified when we set a bluffness ratio, do you agree that the length argument is being kinda redundant at the moment?

Should we convert the length to an optional argument? Just like the sweepLenght and sweepAngle arguments cannot be used at the same time when defining a trapezoidal fin set.

Imagine you as an user, you have set a nose_lenght at the beginning, but the simulation have used another. What are the implications for that?

[MateusStano]

So, if the length of the NoseCone is being modified when we set a bluffness ratio, do you agree that the length argument is being kinda redundant at the moment?

The length parameter is needed to calculate the "modified" length after the bluffness calculations. You could instead receive the fineness ratio from the user, but the same problem would apply because the fineness ratio also changes with bluffness.

Essentially, we need the length of the nosecone to define the nosecone and, if there is bluffness, calculate the new length.

Adding bluffness to a nosecone causes the length to change, its a geometrical problem. We can make it clearer in the documentation that this happens though.

[Gui-FernandesBR]

So, if the length of the NoseCone is being modified when we set a bluffness ratio, do you agree that the length argument is being kinda redundant at the moment?

The length parameter is needed to calculate the "modified" length after the bluffness calculations. You could instead receive the fineness ratio from the user, but the same problem would apply because the fineness ratio also changes with bluffness.

Essentially, we need the length of the nosecone to define the nosecone and, if there is bluffness, calculate the new length.

Adding bluffness to a nosecone causes the length to change, its a geometrical problem. We can make it clearer in the documentation that this happens though.

Hopefully there will be a method in the future to define the nosecone without modifying the length that was given by the user.
When inputting the data, the user should be able to measure what he is providing.