Re: Checking for asteroid perturbers

Néstor D. Díaz Feb 6, 2013

Hi Bill!

Thanks for the explanation. It's much more clear to me now.
This looks like an interesting approach.

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
>