Hi Nestor,
I should warn you: I'm probably not going to actually _do_ the following
really soon. I've a few other projects to get out of the way before I can
do my "fun" stuff. But that hasn't stopped me from _thinking_ about "fun".
> What do you think about generate a file with pre-calculated approaches of these
> 300 objects for a limited range of years (or different files with different
> ranges), and then Find_orb can look on this file(s) to know when to use one
> of these objects as perturbers.
> Could this method be less CPU-time consuming?
The problem is that you'd have to compute those close approaches for any
new object that you load. What I'm looking for is a way in which Find_Orb
can say: "This object is clearly not going to get within, say, .1 AU for
the next 57 days."
There are several tricks that can be used for this. I outlined one on
MPML. I'm also thinking about the following possibility. It's more
complicated, but would be faster :
BC-405 gives orbital elements for 300 asteroids, at 40-day intervals,
at 3654 times. So, for a given 40-day interval, pre-compute the range
of each asteroid. Maybe its x-coordinate will range from -1.376 to
-1.023. (Over 40 days, your average main-belter will move about .4
AU.) You also compute its range in y and z over those 40 days. This
is all mildly computationally demanding, but it only has to be done once.
We then convert these limits to integers, in units of 0.001 AU. This
has two advantages. It lets us store the coordinates in six bytes (three
16-bit integers), so we save lots of space. And integer math is nearly
instantaneous.
Now then. When integrating over that 40-day interval, all you have
to do is to check the x-coordinate of your object and see if it's between
-1476 and -923 units (remember that .1 AU tolerance). If it's in that range,
you'll have to check y and maybe z. Most of the time, you'll find that
your object and the asteroid in question are going to be strangers.
> Yeah, I know, this will generate a huge file (or several large files)...
Shouldn't be too bad. BC-405 is about 131 MBytes, unZIPped :
ftp://cfa-ftp.harvard.edu/pub/MPC/BC405/BC405.zip
I'll have to convert it to binary; the ASCII version doesn't make it
easy to access records at random. The resulting file will be 52617600 bytes
(eight bytes for each value in BC-405). The pre-computed coordinate file
I've just described, though, would be a mere 3654*300*6 = 6.6 MBytes.
In other words, not much.
> If the size of the file(s) is a problem, obviously this could be optional.
It'll have to be. Basically, if you turn asteroids on, Find_Orb
will require that BC-405 be present, and will build the pre-computed file
the first time you use asteroid perturbers.
-- Bill