开云体育

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Xephem
  2. Topics

Strange jumps of Pluto between 2246 and 2247

 

开云体育

Dear friends of XEphem,

I am very happy that the improving pandemic situation has enabled me to resume my practical courses with XEphem in a real room with real Bachelor students...

I haven however, experienced an anomalous behavior of Pluto in the Solar system view. I simulate a revolution with a 500d step, starting today. The motion seems to be OK until the year 2246 but over the next time-step Pluto jumps backwards by approximately 1/4 of an orbit.

If I continue further, it seems to be OK between the years 2247 and 2498 (period ~251yrs) and again between 2498 and 2748 (period ~250yrs).

I enclose two consecutive screenshots (in 2246 and 2247). This is XEphem 4.1.0 on Ubuntu 20.04 (x64).

Do you have an idea of what could cause these jumps?

Yours,
Maxime

--
Maxime GOMMEAUX, ma?tre de conférences
- Affiliation:
??Université de Reims Champagne-Ardenne, UFR Sciences,
??Département des sciences de la Terre
??Laboratoire GEGENAA, EA 3795
- Adresse de visite ou postale:
??CREA, 2 esplanade Roland Garros
??F-51100 Reims (GPS: N 49.2385; E 4.0628)
- Tél: +33 3 26 77 36 83
-
??
??

xephem_capture_pluto_2246.png
xephem_capture_pluto_2247.png

 

Hello Maxime,
?
Two comments:
?
1. I confirm your report using XEphem 4.0.1 but I can also report the?jumping does NOT happen with my legacy 3.7.6 so?SOMEBODY BROKE SOMETHING.
?
5/16/2247 00:00 UTC? ? 4.1.0 RA 16:52:53.90? Dec -10:36:26.5
? ? ? ? ? ? ? ? ? ? ? ?3.6.7 RA 16:52:53.90? Dec -10:36:26.5
9/27/2248 00:00 UTC? ? 4.1.0 RA 11:52:36.30? Dec 16:13:59.6
? ? ? ? ? ? ? ? ? ? ? ?3.6.7 RA 16:46:16.01? Dec -11:05:43.7
?
2. Remember that Pluto's orbit?is only modeled as a simple ellipse, so its accuracy will degrade more quickly (albeit still smoothly) than the other planets.
?
 

On Mon, Jan 24, 2022 at 2:06 PM Elwood Downey <elwood.downey@...> wrote:
1. I confirm your report using XEphem 4.0.1 but I can also report the?jumping does NOT happen with my legacy 3.7.6 so?SOMEBODY BROKE SOMETHING.

Back in July, someone offered to update the Pluto orbital elements:


Here's the code update they suggested:


Could those parameters be at fault? They looked like fairly innocent adjustments when I read over the change. But maybe the real problem is elsewhere in the code, in a change I'm not even thinking of; I'll go do a quick search.?
 

On Mon, Jan 24, 2022 at 2:27 PM Brandon Rhodes via <brandon=[email protected]> wrote:
On Mon, Jan 24, 2022 at 2:06 PM Elwood Downey <elwood.downey@...> wrote:
1. I confirm your report using XEphem 4.0.1 but I can also report the?jumping does NOT happen with my legacy 3.7.6 so?SOMEBODY BROKE SOMETHING.

Back in July, someone offered to update the Pluto orbital elements … Here's the code update they suggested:


I have just tested and can confirm that the above-linked commit is the one that introduced the discontinuity. Apparently this new elliptical orbit for Pluto does not provide a smooth join with the “chap95_pluto” Pluto positions that "planpos()" uses over the time period from?CHAP_BEGIN to?CHAP_END which, it appears, are the dates?1689/3/19 through?2247/10/1.

I'm open to ideas about the best way to resolve this. Should we revert the improvement and go back to our old Pluto ellipse?
 

Many thanks for your research, Brandon.

Since 2248 uses the new elements and this date produces wildly incorrect positions, I would suggest reverting back to the older elements.

For reference, I ran a quick check on Horizons and for?9/27/2248 it reports 16:55 -11:55 so the old elements are still within a few degrees.

On Mon, Jan 24, 2022 at 12:48 PM Brandon Rhodes <brandon@...> wrote:
On Mon, Jan 24, 2022 at 2:27 PM Brandon Rhodes via <brandon=[email protected]> wrote:
On Mon, Jan 24, 2022 at 2:06 PM Elwood Downey <elwood.downey@...> wrote:
1. I confirm your report using XEphem 4.0.1 but I can also report the?jumping does NOT happen with my legacy 3.7.6 so?SOMEBODY BROKE SOMETHING.

Back in July, someone offered to update the Pluto orbital elements … Here's the code update they suggested:


I have just tested and can confirm that the above-linked commit is the one that introduced the discontinuity. Apparently this new elliptical orbit for Pluto does not provide a smooth join with the “chap95_pluto” Pluto positions that "planpos()" uses over the time period from?CHAP_BEGIN to?CHAP_END which, it appears, are the dates?1689/3/19 through?2247/10/1.

I'm open to ideas about the best way to resolve this. Should we revert the improvement and go back to our old Pluto ellipse?
 

Dear friends,

Indeed, 2247/10/1 is the date the jump occurs for me. I am impressed that you found out so quickly!

Another basic question: is there an easy way to activate the Inertial frame by default in Earth view (so that it's selected even at the very first use of XEphem on a specific student's own session)? I find this much more pedagogical...

Yours,
Maxime

Le 24/01/2022 à 21:37, Elwood Downey a écrit?:
Many thanks for your research, Brandon.
Since 2248 uses the new elements and this date produces wildly incorrect
positions, I would suggest reverting back to the older elements.
For reference, I ran a quick check on Horizons and for 9/27/2248 it reports
16:55 -11:55 so the old elements are still within a few degrees.
--
Maxime GOMMEAUX, ma?tre de conférences
- Affiliation:
Université de Reims Champagne-Ardenne, UFR Sciences,
Département des sciences de la Terre
Laboratoire GEGENAA, EA 3795
- Adresse de visite ou postale:
CREA, 2 esplanade Roland Garros, Bureau NE-401
F-51100 Reims (GPS: 49.2385°N; 4.0628°E)
Réception: 08:30-12:15 et 13:30-17:30 (sauf Ve: 13:30-17:00)
- Tél: +33 3 26 77 36 83
-

1 - 6 of 6