Why is AstronomicalData so slow?

Question

I'm having trouble getting some pretty simple functions using AstronomicalData to perform at anywhere near the speed I need them to.

For example, I have many places where I need to compute something like

ParametricPlot[
 {AstronomicalData[
   "Mercury", {"RightAscension", 
    DatePlus[Date[], d], {$GeoLocation[[1]] , $GeoLocation[[2]]}}], d},
 {d, 0, 365}, AspectRatio -> 1/1.6]

but find that it takes far to long for even this simple fragment to run. I want to put several such fragments (e.g. one for each of several astronomical objects) into a single figure, and even to dynamically change the parameters for the figure (such as location and date) inside a Manipulate, which would be prohibitively slow given the times I'm seeing with even the simple fragment above.

Why is AstronomicalData so slow? Is there something I can do to speed it up so I can use it as I hope to?

Looks like you're downloading data from the internet for every point... perhaps preloading the data to your disk might help. I don't have Mathematica to test it right now — rm -rf, Oct 08 '12 at 03:47
Just to make sure: have you done what @rm -rf has suggested (i.e., executing AstronomicalData[All, "Preload"] before doing anything else)? — J. M.'s missing motivation, Oct 08 '12 at 05:07
@J.M.: Yes, but the plot still takes the same time. Perhaps that only loads data for the current day? — orome, Oct 08 '12 at 20:27

score 2 · Answer 1 · answered Oct 08 '12 at 23:16

One way to overcome this issue is simply to define functions to store the data, so that it AstronomicalData is only needed once for each value, using something like

astroData[datum_, object_, dayoffset_, location_] :=
 (astroData[datum, object, dayoffset, location] =
   AstronomicalData[object, {datum, DatePlus[Date[], dayoffset], location}])

Then the data can either be preloaded, with something like

astroData["RightAscension", "Mercury", #, $GeoLocation] & /@ Range[0, 365];

and will in any case accumulate through use so that execution eventually becomes quite speedy.

The example above becomes

ListPlot[{astroData["RightAscension", "Mercury", #, $GeoLocation], #} & /@ Range[0, 365],
    AspectRatio -> 1/1.6, Joined -> True]

score 2 · Accepted Answer · answered Oct 10 '12 at 21:16

2

Once can see by using Trace that an apparently simple call is far more complex than you might imagine. Why it is designed this way, and if it needs to be, is an entirely different matter.

Be prepared to forcefully terminate Mathematica (or at least Quit[] the kernel) and then run:

AstronomicalData["Mercury",
  {"RightAscension", {2012, 10, 11, 12, 13, 14}, $GeoLocation}
] // TracePrint

A lot more going on behind the scenes than a simple database look-up, eh?

answered Oct 10 '12 at 21:16

Mr.Wizard

271,378
34
587
1,371

1

Yes, that "entirely different matter" keeps coming up with Mathematica. One wonders whether there is any thought given to use cases or architecture at all. – orome Oct 11 '12 at 03:17
2

@rax Oh, I'm sure thought has been given. I wish that they'd be more transparent about the limitations of the design, trade-offs made, and places they simple haven't optimized well (Calendar package, PlotLegends, etc.). I didn't even start trying to look through the massive Trace output above, but I'd guess from the length of it that Mathematica is calculating the information requested (from more fundamental data) rather than simple doing a database access. That may be a reasonable trade-off for certain applications, yet cause trouble for yours. – Mr.Wizard Oct 11 '12 at 03:22
1

(Sigh.) Well, in any case, caching what I need is a serviceable, if inelegant, solution. – orome Oct 11 '12 at 03:26

score 0 · Answer 3 · answered Oct 08 '12 at 03:55

0

rm -rf is right:

AstronomicalData["Mercury"]

then execute your command. It takes about 25 seconds on my computer.

answered Oct 08 '12 at 03:55

Eric Brown

4,406
1
18
36

Sorry, no, see above: this needs to run inside a Manipulate, so 25 seconds is way too slow. And in any case, running AstronomicalData beforehand makes no difference in performance (at least not for me). – orome Oct 08 '12 at 04:11
@rax: Worse comes to worst, you might have to roll your very own ephemeris... :| – J. M.'s missing motivation Oct 08 '12 at 05:08
Have you actually tried this? This doesn't do anything at all, it just returns an empty list { }. But it does it fast! :-) – stevenvh Oct 08 '12 at 07:05
The first time I run this - at the start of every Mathematica session - I get the "Initializing indices..." messages for about 10 seconds. Then the expression returns the string "Mercury". Subsequent calls for the expression in that session are immediate. But the parametric plot still takes 15 seconds... – cormullion Oct 08 '12 at 12:25
1

@J. M. Mathematica's AstronomicalData uses a precessing reference frame, and I want ICRF 2000, so rolling my own ephermis is exactly what I'm doing: downloading the SPICE kernels (http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/req/kernel.html), importing them into Mathematica, and then saving them as .mx dump files for faster loading. Seems to help quite a bit. – Aug 26 '15 at 22:00
@barry, a look at all the formulae involved quickly shows how nontrivial that project is. Best of luck! Do you plan to release code when you're done? – J. M.'s missing motivation Aug 27 '15 at 01:38
1

It's messy, but https://github.com/barrycarter/bcapps/tree/master/ASTRO has enough code to compute planetary positions (but you have to download the SPICE kernel files separately). I used this to compute Regulus/Jupiter/Venus conjunctions for http://astronomy.stackexchange.com/questions/11456/has-the-conjunction-between-venus-jupiter-and-regulus-only-occurred-twice-in-2 and to find a 15-year-old bug (now fixed) on the calsky.com site. If there's interest, I can release the .mx dump files, but these are ~300M for every 1000 years of data (and I'm only looking at the visible planets). – Aug 27 '15 at 02:08

Why is AstronomicalData so slow?

3 Answers3

Linked