changed default num_points in OrbitPlotter class #320
Conversation
Hi @nikita-astronaut, thanks for your interest in poliastro! As you say, just increasing the number of points is not the best solution. I added more information in the original issue, so please take your time to read it. |
…d num_points a bit
Codecov Report
@@ Coverage Diff @@
## master #320 +/- ##
=========================================
+ Coverage 80.19% 80.2% +0.01%
=========================================
Files 30 30
Lines 1439 1440 +1
Branches 113 113
=========================================
+ Hits 1154 1155 +1
Misses 252 252
Partials 33 33
Continue to review full report at Codecov.
|
Hi @Juanlu001 I attached three images. The first is how it was before (true anomaly + 100 points), second: eccentric anomaly + 100 points (the problem is ameliorated but nonsmoothness however is still seen), third: eccentric anomaly + 150 points (orbit looks smooth). Now, I think, I'll try to go further and work with s-integrator you've mentioned. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Now this is a change we can include in poliastro I think. I left some comments and also would ask you to add a test or two for the new functionality.
@@ -29,7 +29,9 @@ | |||
{ | |||
"cell_type": "code", | |||
"execution_count": 1, | |||
"metadata": {}, | |||
"metadata": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you restore the changes in this notebook?
src/poliastro/plotting.py
Outdated
"""Constructor. | ||
|
||
Parameters | ||
---------- | ||
ax : ~matplotlib.axes.Axes | ||
Axes in which to plot. If not given, new ones will be created. | ||
num_points : int, optional | ||
Number of points to use in plots, default to 100. | ||
Number of points to use in plots, default to 300. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update docstring :)
src/poliastro/twobody/orbit.py
Outdated
@@ -4,10 +4,13 @@ | |||
|
|||
from astropy import units as u | |||
from astropy import time | |||
|
|||
from astropy.coordinates import CartesianRepresentation, get_body_barycentric_posvel | |||
|
|||
from poliastro.constants import J2000 | |||
from poliastro.twobody.angles import nu_to_M |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about importing all these functions in the same line?
src/poliastro/twobody/orbit.py
Outdated
@@ -294,12 +297,17 @@ def sample(self, values=None, function=propagate): | |||
|
|||
elif isinstance(values, int): | |||
if self.ecc < 1: | |||
nu_values = np.linspace(0, 2 * np.pi, values) * u.rad | |||
# first sample eccenric anomaly, then transform into true anomaly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/eccenric/eccentric/g
Also, what about adding a reference to the report in the comment? "Why sample uniformly on the eccentric anomaly to minimize error in the apocenter, see ..."
src/poliastro/twobody/orbit.py
Outdated
else: | ||
# Select a sensible limiting value for non-closed orbits | ||
# This corresponds to r = 3p | ||
nu_limit = np.arccos(-(1 - 1 / 3.) / self.ecc) | ||
nu_values = np.linspace(-nu_limit, nu_limit, values) | ||
E_limit = nu_to_E(nu_limit, self.ecc) / u.rad |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if the eccentric anomaly makes sense in the context of hyperbolic orbits. I wouldn't be surprised if this fails.
I think I fixed everything you were asking) |
Awesome! Thanks for your contribution 😁 |
Addresses #294
I simple changed the default num_points in OrbitPlotter class, now orbits in the example look smooth.
Still, this is not the best solution. Nonsmoothness appears in the vicinity of perihelion, cause the speed there is the highest, but the points in time are chosen uniformly, so the difference in position is the largest.
What I think could be done next is to place points non uniformly but with density ~1/current_speed, so that between every two points the position change is the same.
What do you think?
P.S. I am actually looking to joining your project later in the GSoC18.