Néstor D. DÃaz Feb 6, 2013
On Tue Feb 5, 2013 3:52 pm, Bill wrote:
> I should warn you: I'm probably not going to actually _do_ the following
> really soon.
It's a shame you can't do it soon. It's really interesting.
On Tue Feb 5, 2013 6:32 pm, Bill wrote:
> I will probably not be able to resist the urge to go ahead and plug it into
> Find_Orb.
Yes, good news!
hahahahaha
Regards!
Néstor
--- In find_orb@yahoogroups.com, Bill Gray wrote:
>
> 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
>