search

astropy / coordinates-benchmark

Accuracy Benchmarks of different coordinate conversion codes. Maintainers: @astrojuanlu, @astrofrog, and @cdeil
https://www.astropy.org/coordinates-benchmark/summary.html
11 stars 12 forks source link

Updated astropy script and results #15

Closed astrofrog closed 11 years ago

astrofrog commented 11 years ago

This updates the Astropy script to the latest version of @eteq's fork in astropy/astropy#471. Surprisingly, the results now agree very well with other packages even though astropy.coordinates doesn't yet include e-terms. So either the effect of the e-terms is small, or other packages do not include then by default.

I've been working on trying to implement the e-terms, but I need to wait for a bug with the transform graph to be fixed before it will work correctly, so I can't properly check the magnitude of the difference.

@cdeil - can you double check whether you get the same results with the latest version of astropy.coordinates from @eteq's fork?

cdeil commented 11 years ago

With ./run_benchmark.py --task celestial --tools astropy I do get differences at the 1e-6 deg level for galactic to icrs ( see https://gist.github.com/4195949 ) for 

* eteq_coordinates bdd4941 add count in djikstra's algorithm to get around py 3.x change in sort behavior

Maybe you had local modifications for ICRS or Galactic? The others are identical.

Let's not worry about this small difference now while things in astropy.coordinates and coordinates-benchmark are in flux, we can do a final cross-check on several machines later before we announce results again on astropy-dev. (We should also make simpler and nice comparison html tables for precision and speed, taking pyast as the reference.)

I think e-terms are sub-arcsec, Kapteyn seems to have nice functions and documentation to cross-check your astropy implementation : http://www.astro.rug.nl/software/kapteyn/celestialbackground.html#fk4-and-the-elliptic-terms-of-aberration

Merging this now.

eteq commented 11 years ago

@cdeil @astrofrog - there was a glitch in the ICRS <-> Galactic conversion that might explain this: something in the algorithm was being stochastically unstable and sometimes doing ICRS -> FK4 -> Galactic and other times doing ICRS -> FK5 -> Galactic ... that may explain the difference you were seeing. It has been fixed now to work as originally intended: always ICRS -> FK5 -> Galactic (unless you explicitly do icrscoord.fk4.galactic)