How I set These Up

[theskyhound]

So, I'm wondering something. You guys keep talking about matching HORIZONS as if it is the gold standard. And it is the gold standard, but only because they perturb the elements to whatever epoch you want. That does not mean they are accurate, or even more accurate than the MPC... There are a lot of other reasons for elements to be inaccurate. Ultimately, its how well they predict actual observations that matters. Are you guys comparing positions to HORIZONS in order to ensure that the perturbations are correct, or are you assuming that HORIZONS is always correct in the broader sense?

[PMSchu]

Hi Greg,

What I meant by "speeding up the calculations" was the time to get the new MP DB ready to perform the calculations. Every time I add a new set of elements to the DB all the precalcs are performed. To add elements before, during & after the close approach, requires three passes through the Add Element routine followed by the precacls each time. Afterwards, there's no guarantee that the different elements will be incorporated into the MP DB, either if ST4 doesn't think they're sufficiently different. I don't know what criteria ST4 uses to make this determination, so the time is frequently wasted anyway.

Pareing down the # of MPs to speed up the calcs for close approaches means that functionality for general MP observing is reduced. The close approach stuff is cool, but I'd like to have the large database available, too. Not asking for much am I?  

I'll defer to BMD on how well the HORIZONS elements predict MP positions during observing. I've never been able to get the iTelescopes to pick up any of the MPs that I sent them after using output from ST4i's Scheduler. Not sure if that's due to inaccurate positions or insufficient exposure times. In trying to avoid trailing I think my exposure times are too short, so nothing is detected.

Phil S.

[bigmasterdrago]

Thanks for the clarification BMD. It can certainly be confusing keeping everything straight. Perhaps in the futire you can describe how you get elements at Today's epoch from Lowell. Can you do this for a single MP or a group of them?

An 8.5" error sounds pretty good considering the magnitude of some of the position errors that you've reported in the past. Is the good agreement because we're still some time away from the close approach?

A nice feature would be to be able to read a file with multiple elements sets at the same time & plug them all into the MP database at once. It would speed up the position calculations for close approachs.

Phil S.

Phil,
I sometimes have to force a download from Lowell as ST will say the elements have not changed since the last download. I did the force again today and when looking at the Minor Planet Database, all of the highlighted rocks have epoch dates of Oct. 9, not the 13th. Yesterday I independently downloaded a Lowell set from https://ftp.lowell.edu/pub/elgb/astorb.dat.gz. The epoch was 2459500.5 (13 Oct 2021 0UT). A similar download today gives the same epoch. In my mind, the only way to get an epoch date for any particular day/hour, is to us the Horizons interface and let JPL/Horizons make you a set of osculating elements to input into ST. This is what they do. Especially keeping up with the close approaches. The other software I use will create a daily set of osculating elements, but for SkyTools4v, I always use Horizons to make that set. I've not found a way to get the MPC elements to generate a correct location for a small rock passing inside the Moons orbit using ST although by downloading MPC NEA Today, will help. Only by using Horizons to generate a set of Osculating elements for the time I want to observe. It is the "Gold Standard". I've always used it as not only a sanity check, but to check against other software predictions.

I just noticed this morning in the Horizons Small-Body Database Lookup when searching 2021 TV10, a new link: "Earth Impact Risks"  https://ssd.jpl.nasa.gov/tools/sbdb_look...021%20TV10. I had not seen that addition prior.

Someone at Lowell mentioned, and I'll quote him: "The problem is the osculating elements are changing as a function of time, so one set done for time X and another done for X + 2 days (say) will both be “correct”, but the results downstream will be different.  Nowadays the computing is fast enough that one generates (as does JPL Horizons) elements and thus ephemerides for “now”.  (We do this also for very nearby objects.). In any case, for near-Earth approachers, you do not want to make an ephemeris until just before you need it because new observations are likely to come in and thus the ephemeris can shift a lot as a result of the object being so close (even if the elements per se hardly change).

    We don't update the Lowell database very often, so it would be a secondary source for very near objects.  Use JPL:  they are experts at this, and the system is maintained to a high state.  Part of their mission is to deal with potentially dangerous objects, so the team works on this behind tbe scenes continually."

[theskyhound]

The original purpose of ASTORB was to produce elements every day, updated to that date. But E. Bowell, the original researcher, turned it over to others, and may have even retired.

On the other hand, there really isn't any reason to be updating your ASTORB elements more often than every 40 days for most minor planets. After all, there are the special daily lists for the NEO's you are interested in. I included the upload in ST4 for people with a more casual interest, because the MPC has really fallen down on the job.

[theskyhound]

Hi Greg,

What I meant by "speeding up the calculations" was the time to get the new MP DB ready to perform the calculations. Every time I add a new set of elements to the DB all the precalcs are performed. To add elements before, during & after the close approach, requires three passes through the Add Element routine followed by the precacls each time. Afterwards, there's no guarantee that the different elements will be incorporated into the MP DB, either if ST4 doesn't think they're sufficiently different. I don't know what criteria ST4 uses to make this determination, so the time is frequently wasted anyway.

Pareing down the # of MPs to speed up the calcs for close approaches means that functionality for general MP observing is reduced. The close approach stuff is cool, but I'd like to have the large database available, too. Not asking for much am I?  

I'll defer to BMD on how well the HORIZONS elements predict MP positions during observing. I've never been able to get the iTelescopes to pick up any of the MPs that I sent them after using output from ST4i's Scheduler. Not sure if that's due to inaccurate positions or insufficient exposure times. In trying to avoid trailing I think my exposure times are too short, so nothing is detected.

Phil S.

I have been trying to get this simple idea across about Horizons for quite a while now, but I'm not sure you guys have understood me: please keep in mind that Horizons can still have major errors in it, and it is even possible that the elements from another source could be more reliable, if that source includes more recent, or more carefully selected observations. There is still some art to deriving orbital elements from observations, especially if those observations are limited. Things like weighting the observations by assigning observational errors, and constraining results to be realistic. A computer can't do these things perfectly on its own. Not everyone using the same data is going to derive the same orbit. JPL has the computational power to update elements in real time to "now." That's great. But as far as I know, there is no transparency regarding the observational data that they are including, how it is being weighted, and how much human interaction there is in the process. The test is not: "how well does it match Horizons?" but rather "how well does it match my observations?"

[PMSchu]

Hi Greg,

You're correct the observations are king. Unfortuantely for those hunting the fast movers, like BMD, he needs to be pointed close enough to the true position of the MP to get it into his FOV. These things are so fast that getting a position visually would be close to impossible. Just keeping them in the field is tough. Like trying to track an airliner as it flies overhead, but for something invisible in the finder scope  .

I think BMD uses HORIZONS because it purports to correct for purturbations plus will provide elements over a range of epoch times that can be input into programs like ST4 that make predictions based on the osculating elements. As you said all these program's predictions are only as good as the elements provided and the elements are only as good as the observations used to generate them. Use of HORIZONS is partially down to convenience. That table of elements for every hour or 2 looks so good.

I do understand some of the limitations because as I mentioned I wrote a program to calculate parabolic osculating elements for comets then refine them to ellipses, all using data from the MPC Circulars. Also had an ephemeris program, too.

If I still had that program & access to the MP discovery data, I could try to make those calculations, but alas my modified Atari ST 520 has gone to hardware heaven.

Please don't think that I think there's a problem with SkyTools. The ST4 calculations are accurately performed. I've been struggling with the MP DB, partly because it's so large; however, I'm currently unwilling to discard the old element sets. FYI, it looks like the MPC is starting to use a new standard epoch of 2022 Jan 20, so next time I download the full MPC data set, there'll be another epoch date in there.

Since I don't do visual observations anymore  , I can't make any checks. Wish I could. Don't miss the mosquito bites, though.

Hope this helps,

Phil S.

[theskyhound]

Its easy to know if an object is being predicted correctly, even visually. The best way to observe these things visually is to set up on a field way ahead of time, have a plot of the path of the asteroid, use a wide field eyepiece, and wait. You don't need to do accurate astrometry. Choose a star near the predicted path and note how close it comes. Most of the time the path will be close, but the time will be off. So simply note the time when the asteroid passes the star and compare it to the prediction. Again, the point isn't to do astrometry, its to get a feel for how close these things are so you ca ben better prepared the next time.

The idea I am trying to get across is that that how close it will be depends on much more than just the epoch of the element set. Most of the time, especially for newly discovered asteroids, it is the least of your worries. Better to pick a field, use a very wide field eyepiece, and start looking way early for anything moving, and have the patience to keep looking for a long while after the prediction. I've been doing this off and on for 20 years.

Because you really can't polish a turd!

[PMSchu]

Then I suppose the thing to do is keep searching for close approaching MPs that are bright enough for BMD or others to observe. The latest DBPS of the NEA Today data found 52 objects that will be within 0.05 AU on Oct 17. I only had half of them in the DBPS that I ran on Oct 10. Someone's been very busy hunting MPs in that time.

This could get pricy using an iTelescope. Many of the MPs that turn up only reach 17th mag, if that. Someone with a 24 - 36 inch scope could catch them.

Phil S.

[bigmasterdrago]

Hi Greg,

What I meant by "speeding up the calculations" was the time to get the new MP DB ready to perform the calculations. Every time I add a new set of elements to the DB all the precalcs are performed. To add elements before, during & after the close approach, requires three passes through the Add Element routine followed by the precacls each time. Afterwards, there's no guarantee that the different elements will be incorporated into the MP DB, either if ST4 doesn't think they're sufficiently different. I don't know what criteria ST4 uses to make this determination, so the time is frequently wasted anyway.

Pareing down the # of MPs to speed up the calcs for close approaches means that functionality for general MP observing is reduced. The close approach stuff is cool, but I'd like to have the large database available, too. Not asking for much am I?  

I'll defer to BMD on how well the HORIZONS elements predict MP positions during observing. I've never been able to get the iTelescopes to pick up any of the MPs that I sent them after using output from ST4i's Scheduler. Not sure if that's due to inaccurate positions or insufficient exposure times. In trying to avoid trailing I think my exposure times are too short, so nothing is detected.

Phil S.

I have been trying to get this simple idea across about Horizons for quite a while now, but I'm not sure you guys have understood me: please keep in mind that Horizons can still have major errors in it, and it is even possible that the elements from another source could be more reliable, if that source includes more recent, or more carefully selected observations. There is still some art to deriving orbital elements from observations, especially if those observations are limited. Things like weighting the observations by assigning observational errors, and constraining results to be realistic. A computer can't do these things perfectly on its own. Not everyone using the same data is going to derive the same orbit. JPL has the computational power to update elements in real time to "now." That's great. But as far as I know, there is no transparency regarding the observational data that they are including, how it is being weighted, and how much human interaction there is in the process. The test is not: "how well does it match Horizons?" but rather "how well does it match my observations?"

I may have found one just now.... When attempting to rerun an ephemeris for 2019 XS over at Horizons, I get really out of whack positions for 9 Nov 23:00CST from home. Very very different than those from a week ago even though the epoch date is unchanged - EPOCH=  2457593.5 ! 2016-Jul-24.00 (TDB). Last weeks position for 9 Nov 23:00CST = 02 46 39.35 -04 08 21.9. Run today = 2021-Nov-09 23:00 *  03 11 02.37 -20 53 31.6. Note the * indicates daylight. I can assure that it is not daylight at 23:00CST at my house. I double checked all the settings (time zone, etc) and they are the same as last week. Strange thing is, when I go fetch elements at JPL, MPC & Lowell, the epoch dates are the same that they were last week when I downloaded them - June 30, 2021, July 4, 2021, & October 12, 2021 respectively. It appears to be some sort of failure to incorporate the time zone setting of UT-6 in the table. If I run the table with default times (UT), the position for 10 Nov 5:00UT is correct. This is the position for 9 Nov 23:00CST. Bizarre!