How I set These Up

[bigmasterdrago]

Cut and paste of the full text output at Horizons no longer works as the units are different for some of the values. In particular q and Semi-major axis being in Km at Horizons with the input field at ST in AU. You'll need to convert and then enter by hand. I had been having numerous fails and did not understand why until just now. I reported it in the Problem thread.

[theskyhound]

I would not just assume this is a universal change. It is more likely just for close approcahers. That, or you can configure it somewhere in the settings, and it somehow got changed, or the default has changed.

[razvan]

I would not just assume this is a universal change. It is more likely just for close approcahers. That, or you can configure it somewhere in the settings, and it somehow got changed, or the default has changed.

That's probably it! I went into the Horizons' table settings and you can change the "output units" to be "km and seconds", "AU and days" or "km and days".

   

[bigmasterdrago]

Works now. I did not see what was going on behind the scene. Something we need to watch closely. Thanks all.

---

Km and seconds appear to be default.

---

Just to illustrate that this process is working well, I ran a 7 hour position ephemeris on 2019 XS beginning at 22:00CDT on November 9. That ephemeris agree with the one I ran at Horizons to within 10 arc seconds thru 7 hours.

   

[PMSchu]

Hi BMD,

What was the epoch of the elements that gave this excellent agreement between ST4 & HORIZONS? How close to the time of close approach? 2019 XS is predicted to approach within 0.0038 AU according to CNEOS. 

Good luck,

Phil S.

[bigmasterdrago]

I believe the starting was EPOCH = 2457593.5 ! 2016-Jul-24.00 (TDB)

When I let Horizons run the Ephemeris Type: Osculating Orbital Elements and chose the observation time prediction of 10 Nov 04:00 TBD for my elements, it works very good.

Horizon output 2021-Nov-09 23:00 02 46 39.22 -04 08 20.9 14.107

SkyTools output in Blue in pix above

2459528.666666667 = A.D. 2021-Nov-10 04:00:00.0000 TDB
EC= 3.275893602889850E-01 QR= 6.756285030923646E-01 IN= 4.442717261799435E+00
OM= 4.949146951721723E+01 W = 2.502600118000444E+02 Tp= 2459457.239789425861
N = 9.785747249051677E-01 MA= 6.989653674673680E+01 TA= 1.078524463360184E+02
A = 1.004785562855954E+00 AD= 1.333942622619544E+00 PR= 3.678819724624372E+02

---

It's closest about 24 hours before (22:00 CST Nov 8) and moving much faster (228"/min) but below my horizon.

[PMSchu]

I believe the starting was EPOCH =  2457593.5 ! 2016-Jul-24.00 (TDB)

When I let Horizons run the Ephemeris Type: Osculating Orbital Elements and chose the observation time prediction of 10 Nov 04:00 TBD for my elements, it works very good.

Horizon output 2021-Nov-09 23:00    02 46 39.22 -04 08 20.9  14.107

SkyTools output in Blue in pix above

2459528.666666667 = A.D. 2021-Nov-10 04:00:00.0000 TDB
EC= 3.275893602889850E-01 QR= 6.756285030923646E-01 IN= 4.442717261799435E+00
OM= 4.949146951721723E+01 W = 2.502600118000444E+02 Tp=  2459457.239789425861
N = 9.785747249051677E-01 MA= 6.989653674673680E+01 TA= 1.078524463360184E+02
A = 1.004785562855954E+00 AD= 1.333942622619544E+00 PR= 3.678819724624372E+02

---

It's closest about 24 hours before (22:00 CST Nov 8) and moving much faster (228"/min) but below my horizon.

I'm surprised that you got agreement this good using elements with an epoch from 2016 or do I misunderstand? OK, the elements used were for 2021 Nov 10 04:00:00. The results look spot on.

Maybe this is a good target for Dennis in Brisbane.

Phil S.

[bigmasterdrago]

The original elements were in 2016 showing in Horizons when doing the search only.

If I let Horizons make the set of osculating elements to choose a date, it makes what I need for editing into SkyTools (10 Nov 04:00 TDB) or UTC or 9 Nov 22:00 CST.

The epoch used when getting the elements directly from JPL are JD 2459396.5 (July 1, 2021), or from MPC are JD 2459400.5 (July 5, 2021) or from Lowell JD 2459500.5 (Oct 13, 2021). Positions with those elements have a position difference of from 1.7" to 8.5". Any of those elements can be imported into the other software I use to come up with similar positions as Horizons and SkyTools. using any of those 3 elements.

Hope that helps. I know it can sound confusing but when applied a few times, it becomes just time consuming but trivial to implement.

[PMSchu]

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.

[theskyhound]

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.

While this might speed up adding elements, I don't see how it would speed up position calculations during the close approach?