What is the precision of ephemeris?

[10110111]

I was comparing the ephemeris calculated by Stellarium's tool with the results given by libnova. From my experiments with whole day 2019-04-14 at latitude 59°56'19.06" and longitude 30°18'50.87", the difference is up to 0.39° in azimuth and 0.22° in altitude when refraction is disabled.

What is actual expected error of Stellarium's calculations? Is the difference above within the error tolerance?

For reference, here's the code I used to get libnova's results:

#include <stdio.h>
#include <libnova/solar.h>
#include <libnova/julian_day.h>
#include <libnova/rise_set.h>
#include <libnova/transform.h>

void print(const int hour, const int minute, const int second)
{
    struct ln_lnlat_posn observer={.lat = 59+56./60+19.06/3600,
                                   .lng = 30+18./60+50.87/3600};

    struct ln_zonedate date={2019,4,14,hour,minute,second,3*3600};
    const double JD = ln_get_julian_local_date(&date);  

    /* ra, dec */
    struct ln_equ_posn equ;
    ln_get_solar_equ_coords(JD, &equ);

    /* az, alt */
    struct ln_hrz_posn hrz;
    ln_get_hrz_from_equ(&equ, &observer, JD, &hrz);

    printf("%02d:%02d:%02d,%.4g,%.4g\n",
           hour, minute, second, hrz.az-180, hrz.alt);
}

int main (int argc, const char *argv[])
{
    for(int i=0;i<3600*24-2*60;i+=2*60)
    {
        const int h=i/3600;
        const int m=i%3600/60;
        const int s=i%60;
        print(h,m,s);
    }
}

[gzotti]

How accurate is libnova?
Honestly, we cannot answer this question. Compare Stellarium with e.g. Horizon.
Appendix F of the Guide lists our expectations. We don't compute aberration so far, that causes about 20 arcseconds error in ecliptic longitude. The errors listed by you seem much too high and should have been detected by many observers.
Not sure, do positions shown on screen match with the results of Stellarium's ephemeris panel?
Did you compute earth-moon barycenter or earth position in libnova? Or does libnova compute DeltaT? (what is ln_zonedate, or what is JD? Is that Julian Date (UT) or Julian Date (Ephemeris Time ET)?)

[10110111]

Compare Stellarium with e.g. Horizon.

What is Horizon? Doesn't seem to be an easily googlable name :) I get lots of irrelevant search results.

Not sure, do positions shown on screen match with the results of Stellarium's ephemeris panel?

Yes, at least the marker is exactly in the center of solar disc.

Did you compute earth-moon barycenter or earth position in libnova? Or does libnova compute DeltaT?

I didn't try to compute these. And yes, libnova does have a function for deltaT: ln_get_dynamical_time_diff.

what is ln_zonedate, or what is JD? Is that Julian Date (UT) or Julian Date (Ephemeris Time ET)?

From the docs, ln_get_julian_local_date returns Julian day (UT).

[gzotti]

Sorry, JPL Horizons. https://ssd.jpl.nasa.gov/?horizons

You must compute planet positions in JDE time frame before determining their location relative to the observer in UT time frame. Please read e.g. Meeus, Astronomical Algorithms or other astronomy ephemeris calculation books (or at least our Guide) about DeltaT.

[10110111]

Reading now the Guide. I actually didn't even know there was such a thing before creating this issue, much less that it explains such details!

BTW, in §17.4.2, I see a strange statement that "a double precision float can keep only about 13 decimal places". This is actually wrong: for IEEE754 binary64, 15 decimal digits are guaranteed to round-trip through decimal-binary-decimal conversion with the standard rounding to nearest/ties-to-even. See e.g. the value your compiler provides for std::numeric_limits<double>::digits10 for x86 or ARM targets.

So the calculations saying that 12:34:56UT is computed to be 2451545.02426 are misleading: the closest representable binary64 JD to this date is 2451545.0242592594586312770843505859375 (in hex 0x1.2b42c831aed6bp+21), which is accurate to 16 digits.

[10110111]

OK, compared with JPL Horizons' ephemeris, and the differences from Stellarium appear much smaller: 0.007° for azimuth and 0.01° for elevation. This looks much closer to the 20" you mentioned for light aberration.

[gzotti]

BTW, in §17.4.2, I see a strange statement that "a double precision float can keep only about 13 decimal places". This is actually wrong: for IEEE754 binary64, 15 decimal digits are guaranteed to round-trip through decimal-binary-decimal conversion with the standard rounding to nearest/ties-to-even. See e.g. the value your compiler provides for std::numeric_limits<double>::digits10 for x86 or ARM targets.

Indeed, thanks for noting. For some reason I had falsely remembered 13 digits, it's 15 and somewhat more (WP says 15.95). That's fine!

[10110111]

OK, since Stellarium is reasonably close to JPL Horizons in the output, and the latter must be much more reliable than some largely-unmaintained library like libnova, I think Stellarium's ephemeris are good enough. (libnova even in its sun.c example which uses ln_get_julian_from_sys and supposedly uses it in intended way, gives quite different RA/DEC coordinates for the Sun from those given by Stellarium, so I don't think DeltaT is the culprit.)