4
$\begingroup$

I have a working implementation of Schlyter's method for calculating the Sun's position. I would like to know how Schlyter got the 3.24587E-5_deg in the following calculation for Mercury.

N =  48.3313_deg + 3.24587E-5_deg   * d    (Long of asc. node)

I could not find this number in JPL Horizons. I'm guessing it's the difference between the N at two epochs divided by number of days between the two epochs, but I'm not sure.

$\endgroup$
6
  • $\begingroup$ ssd.jpl.nasa.gov/txt/p_elem_t1.txt doesn't answer your question, and actually disagrees with your equation. ssd.jpl.nasa.gov/txt/p_elem_t2.txt gives the same information with slightly different coordinates, but still shows the change in Mercury's ascending node as being negative, not positive. $\endgroup$
    – user21
    Commented Mar 4, 2018 at 22:59
  • $\begingroup$ @barrycarter Schlyter in that article used a date before 2000 as the observation date. Could that be why the sign is different? Also, if I took 0.12534081 deg/Cy from your rate tables divided by the avg no. of days in a century (3650.2425), I get 3.4338E-5. Not quite 3.24E-5, but close. Any idea how to get deg/Cy from JPL Horizons for any object in its catalog? $\endgroup$
    – jp2g
    Commented Mar 4, 2018 at 23:55
  • $\begingroup$ I don't know if there's a uniform way to get this from HORIZONS, or even if osculating elements for other bodies precess at a uniform rate. As you suggested, you could use HORIZONS (or SPICE) to simply compute the osculating elements at constant intervals and draw a best fit linear regression line through them. As VSOP2013 theory notes, you might even want to find polynomial fits: github.com/barrycarter/bcapps/blob/master/ASTRO/… (sorry, the only copy I have is my own). $\endgroup$
    – user21
    Commented Mar 5, 2018 at 4:15
  • $\begingroup$ I'm sure you're aware of ssd.jpl.nasa.gov/sbdb.cgi but this only yields fixed osculating elements, and doesn't include a precession term. Even pages like nssdc.gsfc.nasa.gov/planetary/factsheet/joviansatfact.html give only fixed elements. $\endgroup$
    – user21
    Commented Mar 5, 2018 at 4:21
  • $\begingroup$ @barrycarter thanks. If you repost the above as an answer, I'll accept it. $\endgroup$
    – jp2g
    Commented Mar 5, 2018 at 4:56

1 Answer 1

3
$\begingroup$

My email to Paul Schlyter and his reply, posted with permission:

On http://www.stjarnhimlen.se/comp/tutorial.html you note that Mercury's ascending node is given as:

N = 48.3313_deg + 3.24587E-5_deg * d

According to https://ssd.jpl.nasa.gov/txt/p_elem_t1.txt Mercury's ascending node precesses in the negative direction.

As Where to get rate of change for calculating ephemeris from JPL Horizons notes, NASA's value matches the negative of your value almost exactly.

Are you using a different sign convention here, or is this an error?

Reply:

It's neither - instead I use a somewhat different reference system.

I use the "epoch of the day" instead of the fixed epoch of, say, J2000.0. So add the rate of precession to the negative rate of change you found at NASA's site, and you should get my rate of change.

Since I use the "epoch of the day", the positions I get are suitable to compute e.g. the rise, transit, and set times for the planets. Of course they are also good for computing the positions of several planets relative to one another. But if you need the positions to plot on a star map drawn for some fixed epoch, you need to apply a correction for precession to these positions.

Yes, it can be confusing to distinguish those different astronomical coordinate systems from one another. But that's a consequence of living on the planet Earth which orbits the Sun, rotates, and wobbles.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .