Some tips for managing minor planets

[theskyhound]

I'd like you guys to know that I am thinking about observing close approaches and how to make SkyTools do that better. Eventually I will improve the code, but until then I can offer some advice. You guys may already know this, but just in case...

Because the number of minor planets has grown so large, I have had to come up with some creative ways of speeding things up for both general use, and plotting on the charts (two very different problems to solve). As a result things got very complicated. I added pre-calculations at the time when the elements are added, so that they will calculate faster later, and separated minor planets into a special database just for plotting, which also unfortunately adds overhead when you add them to the database. In the years that I was developing ST4, I don't think I  spent more time on anything else. I had to go back to it again and again, trying things, and changing the database design, until it seemed to be the right mix. In the process it all got very complex, and that makes it more likely that sneaky little bugs are hiding from me. The fact that some of you "power users" have had trouble with corruption of your database sort of keeps me up at night, so please keep an eye out for any smoking guns when things go wrong. Right now, I don't know where to start looking for the problem.

One thing to always keep in mind: how long anything related to minor planets takes is always a function of the number of minor planets in the database. So to make things move as quickly as possible when you add new element sets, be sure to keep the number of minor planets to a minimum in the database. Presumably you guys aren't interested in faint outer solar system objects, so don't have them in your database. What I recommend is to use the Cleanup / Delete button on the Minor Planet Data dialog often. Remember, it won't delete any minor planets that are "in use:" in an observing list, log entry, have attachments, etc. So, you can even tell it to "Delete all minor planets" and that should be safe, as long as the ones you want to keep show up some place such as an observing list. Tip: some imports automatically create observing lists with all of the imported objects. By default these are found in the Auto Generated lists folder. These objects won't delete as long as they are in these lists, so by deleting these lists before you clean up the database, more minor planets will be deleted.

When adding minor planets I would limit them to NEOs only in order to keep things as nimble as possible. You can do that via the special MPC lists, or via the ASTORB download by checking only the NEO box.

[PMSchu]

Hi Greg,

Thanks for this update. As one of the more troublesome users of the Minor Planet features of ST4, which is fantastic by the way, I've managed to mess things up on many occasions. Sorry for that. I don't mind the time required to update the MP database, as long as I can control when that happens. The suggestion to uncheck the box to update the Current MPs OL is a good one. By doing the update after ST4 has already started, the Splash Screen doesn't stick on the screen during the update. I don't care if ST4 requires several minutes after updating, if I can be running something else during that time.

I do have several duplicate entries for some MPs like (10482) Dangrieser & (10483) Tomburns that I was observing with iTelescopes a few years ago. I was unable to delete the double entries & gave up. A bigger problem is a search for (10482) Dan Grieser returns 1991 RY16 if I search MPN 10482 or (10537) 1991 RY16 if I search 'dangrieser' in the Des Search. Tomburns, works as expected.

My MP DB has ~2x10^6 orbits in 6 epochs, with ~10^6 of them for epoch 2021 July 4 downloaded from the MPC. I'm a pack rat, former researcher & don't like to delete anything, so cleaning up the MP DB will hurt. I also used Sync to transfer many of my old ST3 OLs going back several years. A while back I did wipe out all of the MP OLs & restart from scratch, but it was unpleasant .

I really don't mind the time required to do either the full MPC or Bowell update, since I only do that every week to 10 days & let the update proceed in the background. The NEAs at Today's Epoch updates run much faster - maybe 7 min or less for ~25k NEAs.

One thing that might help would be the ability to input 3-7 sets of elements for a close approach, load them in the DB, then do all of the precalcs. Somethhing along the lines of reading a section of the HORIZONS element output all at once would be great with a header containing the MP designation & the H & G parameter values. Then the precalcs could process them all at one time. If that not feasible, that's OK though.

ST4 already has so much of the functionality needed to calculate the ephemerides of close approaches. Perhaps a special DB for elements of close approachers that can use multiple epochs close in time & plot the position at time t(x) using each of the elements sets to calculate the position & plot it similar to what's already done using the Trace option, but hold time constant & repeat the position calculation with different element sets instead. You instantly see how the changes in elements affect the predicted positions.

Just a thought.
Let me know if there's anything I can do to help out,

Phil S.

[bigmasterdrago]

Greg, Phil has some interesting ideas on separate DB for NEOs. That's your domain. I'm a bit like Phil, a pack rat, so rarely clean/delete MPs. If you work to much on speeding things up, I'll have less time to spread the Mayo. Thanks for the tips, especially on downloading only a subset from Lowell.

One thing I would like to see is a download from JPL. Those guys are the folks really keeping track of these rocks. A way to sub-download Near Earth, Atira, Potentially Hazardous, Aten, Apollo, Armor, and of course all the others, Tojans, Main Belt, etc. You get the drill.

[PMSchu]

Thanks, Greg! I never thought to download only NEA data from Lowell. I always go for the whole enchilada, but it's a lot to digest.

From what BMD's posted in another thread, it looks like Lowell can provide more timely elements than the MPC.

Phil S.

[theskyhound]

I don't understand anyone's reticence regarding the deletion of data that you don't actually need. Remember, these osculating elements are only temporary, like a loaf of bread. If you ate half the loaf, and the rest started to mold, you'd trow it out, right? SkyTools already has measures in place to ensure that you don't delete anything that you have used in an observing list, log entry, or have attached notes, links, or images to. That should cover anything that you actually need to keep. Better elements are always available for observations in the future... so it makes no sense to me to be an osculating element hoarder, especially when you pay a penalty in everything taking longer and longer. I gave you guys the tools to keep your database lean and mean. You should consider using them.

[PMSchu]

Back several years ago you mentioned that the reason to retain old epoch data was in case I wanted to pull up an old observing scenario. In that case elements for that epoch (or at least close) would be needed. Isn't that still the case?

Phil S.

[bigmasterdrago]

Many years ago, I kept old comet elements for historical reasons when using "Dance of the Planets". I understand what Technoking is saying now. To be accurate, any modern element set for an asteroid is going to be good for old dates if it has not been perturbed by a strong influence. If we do a cleanup, we have a choice on orbit age to scrub. Unfortunately, sometimes when I've done a clean/delete in the minor planet database, I get a (Not Responding) and than a close program. Like this: https://vimeo.com/manage/videos/632933910 And then a black splash screen on the reopen for a long, long time.

[bigmasterdrago]

However, if I sometime simply walk away from the PC for a good bit of time, I will come back to the Minor Planet Database screen with no changes being made to the DB - still has old epoch dates showing and the "not responding" notice is no longer showing. I have little way of knowing if the work was done.
   

[theskyhound]

Back several years ago you mentioned that the reason to retain old epoch data was in case I wanted to pull up an old observing scenario. In that case elements for that epoch (or at least close) would be needed. Isn't that still the case?

Phil S.

All you have to do to keep a minor planet and its orbital elements is to add it to an observing list, create log entry, or attach a note, image, or web link to it.

[theskyhound]

However, if I sometime simply walk away from the PC for a good bit of time, I will come back to the Minor Planet Database screen with no changes being made to the DB - still has old epoch dates showing and the "not responding" notice is no longer showing. I have little way of knowing if the work was done.

If you have a large database, the first thing it does is back it up, in case you do something like tell it to close while it is still working... I doubt it had time in that brief interval to even complete that task. We are pretty far off main usage here, and it looks like I don't have the cleanup process threaded yet. When not threaded and doing something intense, Windows can sometimes pop up the not responding error. The best thing to do here is to wait. Remember, it has to go through the process of removing epoch data for every minor planet, and then it has to completely rebuild the database. This could take quite a while if you have a large number of minor planets. I will look into why this process isn't threaded. Maybe I just commented it out or something.