Skip to content
This repository has been archived by the owner on Oct 14, 2023. It is now read-only.

Default steps 2D plots are too visible #294

Closed
astrojuanlu opened this issue Dec 20, 2017 · 10 comments
Closed

Default steps 2D plots are too visible #294

astrojuanlu opened this issue Dec 20, 2017 · 10 comments
Labels
status:blocked Some other change is needed before working on this (see discussion) triaging:bug
Milestone

Comments

@astrojuanlu
Copy link
Member

馃悶 Problem

With the default number of points, the steps in the pericenter are too visible:

Before After
index index2

This came after the propagation changes in plotting and the different way to compute the data points.

馃幆 Goal

Make the plots smooth again.

馃挕 Possible solutions

  • Increase the default num_points
  • Other?

馃搵 Steps to solve the problem

  • Comment below about what you've started working on.
  • Add, commit, push your changes
  • Submit a pull request and add this in comments - Addresses #<put issue number here>
  • Ask for a review in comments section of pull request
  • Celebrate your contribution to this project 馃帀
@astrojuanlu
Copy link
Member Author

Another side effect:

index4

This is a slightly different issue, namely that the pericenter is not always included in the propagation.

@astrojuanlu
Copy link
Member Author

Notice that, while fixing the previous one, one might step into #265.

@astrojuanlu astrojuanlu added the status:blocked Some other change is needed before working on this (see discussion) label Dec 20, 2017
@nikita-astronaut
Copy link
Contributor

Started working on this issue

@astrojuanlu
Copy link
Member Author

Thanks @nikita-astronaut, keep us posted! Notice that the propagation might fail and distract you, see the last comment in this issue.

@astrojuanlu
Copy link
Member Author

This is a good moment to say that just increasing the number of points is not going to be the preferred solution. In the report "The generalized Sundman transformation for propagation of high-eccentricity elliptical orbits" we can read:

Because of the large number of satellites, attention must be paid to the total time of computation.
For very eccentric orbits, satisfactory accuracy can be maintained with a larger step size near apogee
than is used at perigee

Take a look at this plot:

screenshot-2018-2-21 a605040 pdf

We are now in the situation of Figure 2.d), since we're uniformly sampling the true anomaly:

https://github.com/poliastro/poliastro/blob/24a9299f/src/poliastro/twobody/orbit.py#L295-L302

And before we introduced the sample method, we were doing almost the same thing:

https://github.com/anhiga/poliastro/blob/cd0a31ca3e7ffc99a3/src/poliastro/plotting.py#L169-L182

The most immediate fix for this issue, in my view, would be to use a uniform sample of the eccentric anomaly instead of the true anomaly. However, from the same report:

Merson (Ref. 13) introduced the idea of using the value n = 3 / 2 in the generalized Sundman transformation, with an intent not of regularization per se, but of maximizing computational efficiency; see also Ref. 14. He gave an analysis showing that this value of n equally distributes the integration error around a full orbit, even if the eccentricity is high.

I will therefore accept a pull request (with plots of the before/after situation) that use the eccentric anomaly as a first step, but implementing an s-integrator as described in the report would be a great next step (see #253).

@astrojuanlu
Copy link
Member Author

I found another book that might be useful: "Regularization in Orbital Mechanics: Theory and Practice" (https://doi.org/10.1515/9783110559125)

@nikita-astronaut
Copy link
Contributor

I will now read the report and try to implement the s-integration.

@astrojuanlu
Copy link
Member Author

Great! Nevertheless this issue has been fixed in #320, so I'm closing. Let's continue the discussion in #253, or in the upcoming pull requests.

@astrojuanlu
Copy link
Member Author

Or in #265, for that matter. Notice that, when we have a working propagator, we can include the pericenter in all the samplings if we consider it appropriate, see #294 (comment).

@astrojuanlu
Copy link
Member Author

Another nice before/after table:

Before After
before after

This is with the same number of points. Veeeeeeeeery nice :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status:blocked Some other change is needed before working on this (see discussion) triaging:bug
Projects
None yet
Development

No branches or pull requests

2 participants