<p>Just to preface this, I know that Astrolog is software meant for astrology, which is pseudoscientific nonsense; however, I have a friend who insists on using it for certain astronomical calculations (yeah, don't ask me why), and who is asking about why there seems to be a difference between some values it returns and some values I get using Skyfield and JPL's DE422 ephemeris. Astrolog itself is using the Swiss Ephemeris, which supposedly should have a precision of under 1 arcsecond for the bodies in question for the date in question.</p>
<p>For anyone interested in actually checking for themselves in Astrolog, the simplest way to get the values in question would be to go to Info -&gt; Set Chart Info and plug in the date in question (1859-08-23, 3:20 PM, time zone UTC and longitude and latitude of 0), Setting -&gt; Include Minors to get Juno, and Display Settings -&gt; 360 Degrees to show the ecliptic longitude on the right hand side in degrees. The chart itself can be ignored completely, the only thing I'm interested in are these longitudes.</p>
<p>With the above it should now say that the ecliptic longitude of Pluto is 38.504 and that of Juno is 216.504. However, when I use Skyfield to do observations like these I get different values:</p>
<pre><code>t = ts.utc(1859, 8, 23, 15, 20)
ep = earth.at(t).observe(pluto).ecliptic_latlon('date')[1].degrees
ej = earth.at(t).observe(juno).ecliptic_latlon('date')[1].degrees
</code></pre>
<p>Here I get an ecliptic longitude for Pluto of <code>38.502</code> and one for Juno of <code>217.322</code>; these are of course fairly close, but they're evidently not the same. What gives? The value for Pluto is particularly close, but still just enough off that I assume there's something wrong. The Juno one is almost an entire degree off, which I really don't get.</p>
<p>Is there something the Astrolog program itself is doing wrong? As far as I'm aware it's just using the Swiss Ephemeris, which should be just as accurate as the DE422 ephemeris used by Skyfield here, but maybe it's not for some reason? Is there something else which has gone wrong here that I'm not thinking of? I guess maybe someone more seasoned could check for themselves what the ecliptic longitudes of the bodies in question should be on that date and time, and compare it to what's been found here.</p>
<p>Addendum:</p>
<p>Accounting for the fact that Horizons uses apparent positions rather than astrometric ones for ecliptic longitude, and UT1 rather than UTC for dates before 1962, I used this to get the ecliptic longitudes instead:</p>
<pre><code>t = ts.ut1(1859, 8, 23, 15, 20)
ep = earth.at(t).observe(pluto).apparent().ecliptic_latlon('date')[1].degrees
ej = earth.at(t).observe(juno).apparent().ecliptic_latlon('date')[1].degrees
</code></pre>
<p>This yielded <code>38.50416</code> for Pluto, which is in agreement to 3 decimals (off by just <code>0.00008</code>, less than an arcsecond, that's fine), but the error for Juno persists, as I get <code>217.31988</code>, still roughly <code>0.8</code> degrees off. This is simply too large to be accounted for by the difference in apparent and astrometric, or the leap seconds of difference between UT1 and UTC. I read that the MPC orbital elements being used to compute the position for Juno should have precision to five digits, so I'm very confused as to what exactly is going wrong when that position is computed.</p>

CC BY-SA 4.0
2024-07-20T20:57:15.467Z
From astro.com’s page about the Swiss Ephemeris, it “is based upon the planetary and lunar ephemeris DE431,” whereas you write that Skyfield uses DE422. That should explain the differences.
Pierre Paquette
CC BY-SA 4.0
2024-07-20T21:31:01.817Z
@PierrePaquette: Strictly speaking Skyfield can use a variety of ephemerides, but there is a quirk that prevents some from being used, and I believe DE431 is one of them. However, I had only set it to DE422 because of checking some things very far back, I just tried it using both DE430, published the same year as DE431 and using the same precision, as well the even newer DE440, and in both cases I get the exact same ecliptic longitude for Juno: `217.322`. However, when I check using the Horizons System I get `216.504`, exactly what Astrolog also yields, so presumably Skyfield is the problem.
Outis Nemo
CC BY-SA 4.0
2024-07-21T00:23:18.290Z
Juno is not part of any JPL DE, so it has to be using something else for that.  They are both probably using completely different ephemeris of varying accuracy, and that's likely the source of the error.  Pluto is close enough that it may be an issue with time scales, or eliminating part of the reduction procedures (like abberation or leap seconds).
Greg Miller
CC BY-SA 4.0
2024-07-21T11:53:27.000Z
@GregMiller: I must reiterate that I strongly doubt the problem is which ephemeris being used. As stated in the above comment I got the same result using DE422, DE430, and DE440; the Swiss Ephemeris is based on DE431 and JPL's Horizons System uses DE441, which should agree with DE430 and DE440 respectively (and they also agree perfectly with each other). Moreover, the precision of all these ephemerides should exceed the difference found here by a wide margin, the same goes for the MPC orbital elements used for Juno. I still struggle to understand what exactly is the reason for the difference.
Outis Nemo
CC BY-SA 4.0
2024-07-21T12:28:13.613Z
@GregMiller: I will say that there's probably something to what you're saying about Juno being the primary problem. I just checked the Horizons output, and they are indeed using apparent positions for the ecliptic longitudes rather than astrometric ones; accounting for that I brought Pluto's ecliptic longitude into agreement to 3 decimal places (`38.504`), but Juno is still around `0.8` degrees off. What I find strange is that the MPC orbital elements supposedly should have precision to five digits, so getting an error this large is very much unexpected to me.
Outis Nemo
CC BY-SA 4.0
2024-07-21T23:34:54.220Z
In the header JPL will specify a "source" for the ephemeris, might be helpful to check that.
Greg Miller
CC BY-SA 4.0
2024-07-22T16:05:14.100Z
@GregMiller: Right; from what I can tell it seems like JPL is using something called a "small-body perturber", SB441-N16. I'm assuming this is to account for perturbations that aren't accounted for with the orbital elements from MPC? It still seems a bit strange though; I could buy that for Juno being `0.8` degrees off, but I also checked for Vesta, which is roughly `10` degrees off, that seems like way too much, but maybe I'm underestimating how much error can accumulate in that time from it. Not sure there's any way to account for these perturbations with Skyfield either, hmm.
Outis Nemo
<coordinate><software><ephemeris><ecliptic><skyfield>
Why is there a discrepancy between ecliptic longitudes found with Skyfield and Astrolog for old dates?
Outis Nemo
# Why is there a discrepancy between ecliptic longitudes found with Skyfield and Astrolog for old dates?

(Asked by: username_0 on 2024-07-20)

Just to preface this, I know that Astrolog is software meant for astrology, which is pseudoscientific nonsense; however, I have a friend who insists on using it for certain astronomical calculations (yeah, don't ask me why), and who is asking about why there seems to be a difference between some values it returns and some values I get using Skyfield and JPL's DE422 ephemeris. Astrolog itself is using the Swiss Ephemeris, which supposedly should have a precision of under 1 arcsecond for the bodies in question for the date in question.
For anyone interested in actually checking for themselves in Astrolog, the simplest way to get the values in question would be to go to Info -> Set Chart Info and plug in the date in question (1859-08-23, 3:20 PM, time zone UTC and longitude and latitude of 0), Setting -> Include Minors to get Juno, and Display Settings -> 360 Degrees to show the ecliptic longitude on the right hand side in degrees. The chart itself can be ignored completely, the only thing I'm interested in are these longitudes.
With the above it should now say that the ecliptic longitude of Pluto is 38.504 and that of Juno is 216.504. However, when I use Skyfield to do observations like these I get different values:
t = ts.utc(1859, 8, 23, 15, 20)
ep = earth.at(t).observe(pluto).ecliptic_latlon('date')[1].degrees
ej = earth.at(t).observe(juno).ecliptic_latlon('date')[1].degrees

Here I get an ecliptic longitude for Pluto of 38.502 and one for Juno of 217.322; these are of course fairly close, but they're evidently not the same. What gives? The value for Pluto is particularly close, but still just enough off that I assume there's something wrong. The Juno one is almost an entire degree off, which I really don't get.
Is there something the Astrolog program itself is doing wrong? As far as I'm aware it's just using the Swiss Ephemeris, which should be just as accurate as the DE422 ephemeris used by Skyfield here, but maybe it's not for some reason? Is there something else which has gone wrong here that I'm not thinking of? I guess maybe someone more seasoned could check for themselves what the ecliptic longitudes of the bodies in question should be on that date and time, and compare it to what's been found here.
Addendum:
Accounting for the fact that Horizons uses apparent positions rather than astrometric ones for ecliptic longitude, and UT1 rather than UTC for dates before 1962, I used this to get the ecliptic longitudes instead:
t = ts.ut1(1859, 8, 23, 15, 20)
ep = earth.at(t).observe(pluto).apparent().ecliptic_latlon('date')[1].degrees
ej = earth.at(t).observe(juno).apparent().ecliptic_latlon('date')[1].degrees

This yielded 38.50416 for Pluto, which is in agreement to 3 decimals (off by just 0.00008, less than an arcsecond, that's fine), but the error for Juno persists, as I get 217.31988, still roughly 0.8 degrees off. This is simply too large to be accounted for by the difference in apparent and astrometric, or the leap seconds of difference between UT1 and UTC. I read that the MPC orbital elements being used to compute the position for Juno should have precision to five digits, so I'm very confused as to what exactly is going wrong when that position is computed.

**Tags:** coordinate, software, ephemeris, ecliptic, skyfield
> **Comments:**
> **username_1**: From astro.com’s page about the Swiss Ephemeris, it “is based upon the planetary and lunar ephemeris DE431,” whereas you write that Skyfield uses DE422. That should explain the differences.  
> **username_0**: @PierrePaquette: Strictly speaking Skyfield can use a variety of ephemerides, but there is a quirk that prevents some from being used, and I believe DE431 is one of them. However, I had only set it to DE422 because of checking some things very far back, I just tried it using both DE430, published the same year as DE431 and using the same precision, as well the even newer DE440, and in both cases I get the exact same ecliptic longitude for Juno: `217.322`. However, when I check using the Horizons System I get `216.504`, exactly what Astrolog also yields, so presumably Skyfield is the problem.  
> **username_2**: Juno is not part of any JPL DE, so it has to be using something else for that.  They are both probably using completely different ephemeris of varying accuracy, and that's likely the source of the error.  Pluto is close enough that it may be an issue with time scales, or eliminating part of the reduction procedures (like abberation or leap seconds).  
> **username_0**: @GregMiller: I must reiterate that I strongly doubt the problem is which ephemeris being used. As stated in the above comment I got the same result using DE422, DE430, and DE440; the Swiss Ephemeris is based on DE431 and JPL's Horizons System uses DE441, which should agree with DE430 and DE440 respectively (and they also agree perfectly with each other). Moreover, the precision of all these ephemerides should exceed the difference found here by a wide margin, the same goes for the MPC orbital elements used for Juno. I still struggle to understand what exactly is the reason for the difference.  
> **username_0**: @GregMiller: I will say that there's probably something to what you're saying about Juno being the primary problem. I just checked the Horizons output, and they are indeed using apparent positions for the ecliptic longitudes rather than astrometric ones; accounting for that I brought Pluto's ecliptic longitude into agreement to 3 decimal places (`38.504`), but Juno is still around `0.8` degrees off. What I find strange is that the MPC orbital elements supposedly should have precision to five digits, so getting an error this large is very much unexpected to me.  
> **username_2**: In the header JPL will specify a "source" for the ephemeris, might be helpful to check that.  
> **username_0**: @GregMiller: Right; from what I can tell it seems like JPL is using something called a "small-body perturber", SB441-N16. I'm assuming this is to account for perturbations that aren't accounted for with the orbital elements from MPC? It still seems a bit strange though; I could buy that for Juno being `0.8` degrees off, but I also checked for Vesta, which is roughly `10` degrees off, that seems like way too much, but maybe I'm underestimating how much error can accumulate in that time from it. Not sure there's any way to account for these perturbations with Skyfield either, hmm.  

---

## 0 answers

