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

   "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?

  • 2
    $\begingroup$ 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 $\endgroup$ – rm -rf Oct 8 '12 at 3:47
  • $\begingroup$ Just to make sure: have you done what @rm -rf has suggested (i.e., executing AstronomicalData[All, "Preload"] before doing anything else)? $\endgroup$ – J. M. is in limbo Oct 8 '12 at 5:07
  • $\begingroup$ @J.M.: Yes, but the plot still takes the same time. Perhaps that only loads data for the current day? $\endgroup$ – orome Oct 8 '12 at 20:27

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:

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

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

  • 1
    $\begingroup$ 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. $\endgroup$ – orome Oct 11 '12 at 3:17
  • 2
    $\begingroup$ @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. $\endgroup$ – Mr.Wizard Oct 11 '12 at 3:22
  • 1
    $\begingroup$ (Sigh.) Well, in any case, caching what I need is a serviceable, if inelegant, solution. $\endgroup$ – orome Oct 11 '12 at 3:26

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]

rm -rf is right:


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

  • $\begingroup$ 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). $\endgroup$ – orome Oct 8 '12 at 4:11
  • $\begingroup$ @rax: Worse comes to worst, you might have to roll your very own ephemeris... :| $\endgroup$ – J. M. is in limbo Oct 8 '12 at 5:08
  • $\begingroup$ Have you actually tried this? This doesn't do anything at all, it just returns an empty list { }. But it does it fast! :-) $\endgroup$ – stevenvh Oct 8 '12 at 7:05
  • 1
    $\begingroup$ @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 (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. $\endgroup$ – barrycarter Aug 26 '15 at 22:00
  • 1
    $\begingroup$ It's messy, but 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 astronomy.stackexchange.com/questions/11456/… 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). $\endgroup$ – barrycarter Aug 27 '15 at 2:08

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.