8
$\begingroup$

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?

Improve this question
$\endgroup$
3
  • 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 ♦
    Commented Oct 8, 2012 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.'s missing motivation ♦
    Commented Oct 8, 2012 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
    Commented Oct 8, 2012 at 20:27

3 Answers 3

Reset to default
2
$\begingroup$

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?

Improve this answer
$\endgroup$
3
  • 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
    Commented Oct 11, 2012 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
    Commented Oct 11, 2012 at 3:22
  • 1
    $\begingroup$ (Sigh.) Well, in any case, caching what I need is a serviceable, if inelegant, solution. $\endgroup$
    – orome
    Commented Oct 11, 2012 at 3:26
2
$\begingroup$

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]
Improve this answer
$\endgroup$
0
0
$\begingroup$

rm -rf is right:

AstronomicalData["Mercury"]

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

Improve this answer
$\endgroup$
7
  • $\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
    Commented Oct 8, 2012 at 4:11
  • $\begingroup$ @rax: Worse comes to worst, you might have to roll your very own ephemeris... :| $\endgroup$
    – J. M.'s missing motivation ♦
    Commented Oct 8, 2012 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
    Commented Oct 8, 2012 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$
    – user1722
    Commented Aug 26, 2015 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$
    – user1722
    Commented Aug 27, 2015 at 2:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.