Determine why the accuracy of FK4 -> FK5 is poorer than FK5 -> FK4 in some cases

[astrofrog]

It seems the agreement for FK4 -> FK5 is generally lower - for instance, for pyslalib <-> kapteyn, the accuracy is 0.004" one way, and 0.2" the other. Is it something to do with the default epoch of observation?

[cdeil]

Would this imply that round-tripping FK4 -> FK5 -> FK4 changes the coordinates more than numerical errors?

You should be able to quickly check by removing the if statements in run_benchmark.py:

CELESTIAL_SYTEMS = 'fk5 fk4 icrs galactic ecliptic'.split()
CELESTIAL_CONVERSIONS = itertools.product(CELESTIAL_SYTEMS, CELESTIAL_SYTEMS)
CELESTIAL_CONVERSIONS = [dict(zip(['in', 'out'], _))
                         for _ in CELESTIAL_CONVERSIONS
                         if _[0] != _[1]]

TOOLS = 'astropy kapteyn pyast pyephem pyslalib astrolib idl'.split()
TOOLS.append('gammalib')
TOOL_PAIRS = [_ for _ in itertools.product(TOOLS, TOOLS)
              if _[0] < _[1]]

[astrofrog]

@cdeil - yes, I think the errors are larger than floating-point. However, If I remove the if statements, it won't round-trip via FK4 if I understand - it will just do FK5 -> FK5 for example - or am I misunderstanding?

[cdeil]

You are right, we have to write a separate test for round-tripping (should go in the astropy unit tests also if it's not there already).

I tried to estimate the numerical rounding error we can expect for float64 computations. According to http://en.wikipedia.org/wiki/Double-precision_floating-point_format there's about 16 good decimal digits, so there should rounding errors should appear only at the nano-arcsec level:

In [8]: 16 - log10(360 * 3600)
Out[8]: 9.887394998465425

Even if there are complicated formulae and errors accumulate, any differences we see at the micro-arcsecond level and above (this is what we print in the summary tables, %.6f) should not be rounding errors.

Is that estimate correct?

[astrofrog]

Yes, that sounds right!

[cdeil]

Here's the current FK4 -> FK5 and FK5 -> FK4 results summary:

To me it looks like the differences are now at the sub-milli-arcsec level everywhere, i.e. the issue reported above is no longer present.

@astrofrog - OK to close this issue?

If you think a check should be added for all tools that they round-trip OK, please open a new issue.
I think it would be good to have to make sure we're using each tool correctly, but it's low priority because probably everything is OK.

[astrofrog]

The difference with pyast is currently around 4mas, so it depends if we are happy with that level of accuracy? This is definitely >> 64-bit precision.

[astrofrog]

@cdeil - sorry, this issue can be closed, the accuracy is the same both ways. #18 is the one that should be kept open.