Hi Greg,
Sorry I tried 2 different approaches to update the elements. The Read File method was clearly the wrong approach to input elements from HORIZONS. I was trying to do too much at once. There are 2 issues.
#1) The dialog for the Read File is: [attachment=2087]
The Help says this: [attachment=2088]
It looks like the Help needs a revision unless the MPCORB & ASTORB formats are the same. It confused me.
#2) I tried to update the DB directly here: [attachment=2089]
When I pasted the HORIZONS elements from BMD's 5:13PM post yesterday into the edit elements dialog, the DB wasn't updated with the elements from Oct 25. The elements from Oct 28 were retained instead. This has happened before when the elements aren't sufficiently different. The original elements are retained.
Sorry I got you mixed up. Hope this helps clear things up,
Phil S.
Ok, I see now that the Help page for the Read File dialog doesn't even work.... I will verify winch formats it reads. The Read File dialog is mostly there because it was left over from previous versions. There is very little reason for anyone to ever use it, given that there are ways to automatically update the elements.
The Read File option would be very handy if it could read several elements sets from HORIZONS like BMD does. It would then be possible to enter elements from before, during & after a close approach & SkyTools could select the appropriate elements depending on the time.
Perhaps this isn't feasible.
Phil S.
Just copy and paste into a rock edit
As noted in post #11 above, I tried that & the new elements weren't saved to the DB. Sometimes it works for me & sometimes (usually) it doesn't.
Phil S.
As noted elsewhere, the only reason I know for this to happen, would be if the orbital elements are not sufficiently different, such that they are essentially the same. Doesn't that make the matter moot?
Yes, it certainly would. I suppose it would be difficult to chose which element set to use if the results are the same. Can't remember how different the elements that wouldn't update were from the new values.
Since I download the NEAs at Today's Epoch every few days, I suppose they don't change much unless there's a close pass in the mean time.
Phil S.
Elements of a close pass rock change dramatically over a several day period. Seven hour spread below.
B4 close approach:
2459518.208333333 = A.D. 2021-Oct-30 17:00:00.0000 TDB
EC= 5.554180849871738E-01 QR= 7.728843232226568E-01 IN= 2.151737393348603E+00
OM= 2.192267917965804E+02 W = 2.456103113929897E+02 Tp= 2459563.008166347630
N = 4.299916426052014E-01 MA= 3.407364462138501E+02 TA= 2.922182215196866E+02
A = 1.738452008783036E+00 AD= 2.704019694343415E+00 PR= 8.372255744759567E+02
after close approach
2459518.500000000 = A.D. 2021-Oct-31 00:00:00.0000 TDB
EC= 5.571756495095399E-01 QR= 7.744850453165959E-01 IN= 2.205544477332441E+00
OM= 2.191775859892586E+02 W = 2.453017716344408E+02 Tp= 2459562.814084406011
N = 4.261198455187150E-01 MA= 3.411168891985262E+02 TA= 2.928962821033297E+02
A = 1.748966705328642E+00 AD= 2.723448365340687E+00 PR= 8.448327478429751E+02
Try plotting these to see the positional difference. To find these small, faint, fast movers, we need the closest elements to the observation using ST.
Sorry, for 2021 UW1
bigmasterdrago you've lost the proper context. Phil is complaining that for some elements that he inputs they don't show up in the database. My explanation for this is that you have to input sufficiently different elements for it to recognize them as being worth adding to the database. There was a thread on this elsewhere. Obviously, if the elements do change, as in your example, then the elements should be added.
If you have evidence that elements are not being added when they should be, that's another matter, but to my knowledge you have''t made that case, and I have not seen such a problem myself.
I've not seen the issue Phil has. I'm only adding a single set from the Horizon Osculating list very close to the times I expect to attempt a sighting. And I'm finding that STv does a great job of keeping an ephemeris well within a few arc second error of those published by Horizons. BTW, I'm finding all sorts of uses for ST. Thanks again for a powerful program.
Back when Phil first posted this thread, I had already played with this rock just b4 his post. At the time, I had run the ephemeris with what I had available and had accidentally clicked on the date 2021 Oct 24 22:00 to make an IA, not looking at the elevation output. Which was -64°, not +64°. I ran a short trails and discovered that the asteroid nearly crossed a 5.3 magnitude star.
After discovering that it was way, way below my horizon, I thought where would I need to be in order to see it occult that star (HR 4219, HIP 52678). I had to correspond with one of my math genius friends to have him work out the lat & long in the southern hemisphere where I might observe it from. I did not have time to follow up. Getting that info, I finally made a large number of tweaks to get a time and viewing location to observe the 16th magnitude asteroid occult the 5.3 magnitude star.
I had to observe from 80° 32' 37.80" S 79° 52' 35.95" W (Antarctica) at approximately 3:06:07.5245UT (big estimate based on track points). The rock was moving so fast that the drop in brightness would have been so short that I doubt my brain would have registered it.
I'm unable to now duplicate this as the elements have changed a lot. Current epoch Oct 30 and even getting the osculating elements for Oct 24 from Horizons. When I go to make the Interactive Atlas, I get a fail as below. The Atlas does open blank as I get the Fatal Error message.
[
attachment=2096]