Laurent Zimmermann Apr 29, 2007
> Laurent Zimmermann wrote:
>
> "...On the other hand, it could be a good idea if Guide itself had
> a built-in option to make the same job. Bill, what's your opinion?"
>
> Guide does have something of this ilk, but Denis' comments are
> making me think I may want to do a better job of it.
>
> Right now, when Guide has to draw asteroids from MPCORB for a
> particular date, it first computes the location and magnitude of each
> asteroid at the start and end of that date. It stores all of this in
> a file called 'mpcorb.lim' ("limits" file for mpcorb). Subsequent
> draws of asteroids for that date tend to be quite fast, because
> Guide can look through 'mpcorb.lim' and say, "this asteroid isn't
> bright enough on this day" or "this asteroid doesn't appear in the
> current chart area on this day." As a result, Guide will usually
> consider just those asteroids that really matter, and it can run
> briskly, even on old computers.
>
> The problem arises when you specify a different day. Guide has
> to recompute everything, and you get a long wait.
>
> Denis now has me contemplating a few revisions to this idea. First,
> the 'mpcorb.lim' file would indicate the area covered by an asteroid,
> and its maximum magnitude, over a fifty-day period, not a one-day
> period. And Guide would be able to create several of these files,
> perhaps up to ten of them, so that over a 500-day range, it would
> run briskly.
>
> There would still be a slowdown when (for example) using an updated
> 'mpcorb.dat', because when you do that, new 'mpcorb.lim' files would
> be needed. And they'd be created on an as-needed basis, so when you
> decided you wanted to look at where an object will be next year, there
> would be a pause as Guide created the necessary .lim file. But such
> pauses would be far less frequent than they are now. Something for me
> to work on...
>
> -- Bill
>
>