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$
  • $\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$ – barrycarter Mar 4 '18 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 Mar 4 '18 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$ – barrycarter Mar 5 '18 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$ – barrycarter Mar 5 '18 at 4:21
  • $\begingroup$ @barrycarter thanks. If you repost the above as an answer, I'll accept it. $\endgroup$ – jp2g Mar 5 '18 at 4:56
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$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.