Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
2021 RG19
#11
Over the years, I've avoided magnitude estimates at Horizons. Horizons now appears to be getting better. In the new format, I would use T-mag for comets, APmag for asteroids. Those from the MPC seem to be more consistently correct vs true visual estimates. I've found the list at https://cometchasing.skyhound.com/ to be very helpful or to simply run an ephemeris in SkyTools. If I run the ephemeris using elements from the MPC for 2021 RG19, I get magnitudes brighter roughly a full magnitude - 14.9 vs 16.1.

The new format at Horizons has far more info than that from a week ago and the columns will not fit on my 27" 4k monitor. I've got to scroll to the bottom and then slide the columns and then scroll back up.
Reply
#12
Hi BMD,

Yes the new GUI at HORIZONS is an improvement. Regarding the Data Table not fitting on your monitor, have you tried to use the 
Ctrl-'-' key combo on the Number pad to reduce the screen magnification? To restore to 100% Zoom use Ctrl-0. To be clear, hold the Ctrl key & press the '-' key on the number pad simultaneously. That reduces the Zoom level, while Ctrl-'+' increases it.

Regarding the estimated apparent magnitude of the MPs, ST4 calculates that in the ephemeris, but I'm not sure that it includes atmospheric extinction in the Mag calculation. However, I think that extinction is included in the 'Quality' calculation because I've seen 'Quality' drop from 'Fair' to 'Poor' through a night as the object approaches the horizon.

The elements that I used to calculate the ephemeris for 2021 RG19 were from 2021 Sep 27 according to the OI.

The OL for close MPs for October 1 is attached.

Hope this is useful,

Phil S.
Reply
#13
Thanks Phil. The keyboard trick works up to the point when the text is too small. But it brings the important columns into view. Thanks again.

Every piece of software or online source I use generally gives different magnitudes. I use Horizons to get the general idea, it lets me know if moon, or twilight is a factor quickly. I then import and do the ephemeris in ST or AG depending on what I'm looking for.

Thanks for the OL. I'll compare it with mine later.

Do you do a complete MPC download or just the Daily and NEA. I sometimes find the MPC full has to be fetched because one or two close pass rocks (listed in CNEOS) might be skipped in the Daily.
Reply
#14
Hi BMD,

Generally I download the full MPC data file every week-10 days. The epoch of the elements here is for their 'standard' epoch date, currently July 4. To get the close approaching objects, I download the NEAs at Today's Epoch file every 2-3 days. Sometimes I miss a good one though because the close approarch has already occurred, often because the detection occurred on the way back out. Calculating the ephemeris a few days in the past will show this. I don't bother with the Daily Update because the time for the file download is short compared to the time required to do the ST4 MP database calculations - might as well download the full MPC. After the full MPC download, I think that the epoch dates are set to the 'Standard' epoch again, so I need to do the NEAs at Today's Epoch after that anyway to get the epoch date close to the current date again.

CNEOS doesn't show 2014 TM for some reason.

Hope this helps,

Phil S.
Reply
#15
That's weird about 2014 TM not being in CNEOS. I rooted it from the MPC and it shows closest to me on Oct 3 12:24CDT at mag 16.7 altitude -14° moving 54"/min. The ephem at Horizons does not agree. I'm going to take the original discovery elements and run it later today to see what is going on.
Reply
#16
I found the only set of elements that give the same positions as Horizons seem to come from https://ssd.jpl.nasa.gov/dat/ELEMENTS.UNNUM where the epoch date is 2021 July 1. Those at Horizons are epoch 2456933.5 2014-Oct-03.00 (TDB) but when running ephems, I get the same positions for the month of Oct. 2021. Even the elements directly from the MPC (epoch 2021 July 5) gave very erroneous position compared to Horizons. Over 41° to the NE!! So something is very screwed up. The Lowell position is 32° to the SW (Epoch 2021 Oct. 13).

Just maybe the CNEOS does not include it because the uncertainty is so high. I think I saw 6 on the discovery page - 1 day arc 23 observations.

Someone reminded me that I can edit the columns at Horizons to get only those I want by editing #5 (Table Settings). Helps make it fit on my display and remain readable Cool
Reply
#17
I've been reading the HORIZONS documentation (and of course, I had to try the telnet interface, it's been 20+ years since I last used telnet with a public system and it felt nice, like a trip to my youth) and have a question. 

I get that the ephemeris is calculated by successive integrations, with the initial conditions given by the osculating elements. What I didn't find in the documentation so far is how often the osculating elements are themselves calculated. They must be as correct as possible, otherwise they'd be useless as a base for integration. The closest thing in the documentation is the section at https://ssd.jpl.nasa.gov/horizons/manual.html#limits but it doesn't address the frequency of updates to the osculating elements. BTW, I loved the warning in capitals: "IF YOUR CAREER OR SPACECRAFT DEPENDS ON A NON-LUNAR NATURAL SATELLITE OR SMALL-BODY EPHEMERIS, CONTACT JPL BEFORE USING IT. YOU MUST HAVE ADDITIONAL INFORMATION TO CORRECTLY UNDERSTAND EPHEMERIS LIMITATIONS AND UNCERTAINTIES.".
Reply
#18
Hi razvan,

I'm not certain, but I think that when an object is discovered, osculating elements are all that can be determined. Then the orbit is refined with more observations & finally perturbations can be taken into account. The folks at JPL have the info needed to do the perturbation calculations. Those can only be done iteratively. There are also nongravitic (is that the term?) effects, like light pressure & jetting that can change the Keplarian orbital motion.

That warning is quite impressive. I wonder what the limitations & uncertainties are.

Phil S.
Reply
#19
I think this paragraph will shed some light: "Output for asteroids and comets can include formal +/- 3-standard-deviation statistical orbit uncertainty quantities. There is a 99.7% chance the actual value is within given bounds. These statistical calculations assume observational data errors are random. If there are systematic biases (such as measurement timing, reduction, or star-catalog errors), results can be optimistic. Because the epoch covariance is mapped using linearized variational partial derivatives, results can also be optimistic for times far from the solution epoch, particularly for objects having close planetary encounters."
Reply
#20
Too many years ago to even count, I used "Dance of the Planets". Whenever you added any new comet or asteroid, You had to always make sure to do it at the epoch date. I had no idea why back then. It was rather well refined for the date of the software and the machines we ran it on. Today, stand alone software can easily take a rock with an epoch date back 5 or more years ago and generate an ephemeris that is the same as the ones generated at Horizons. They match in current dates. Rocks generally have no non-gravs, so it work well. Comets not so much. Processors are so fast today that the software makes a new set of elements at each step b4 calculating the next step. I'm fairly sure that is what Horizons does also.

As for 2014 TM, I asked about the uncertainty of locating it on amastro and got this answer from Brian Skiff at Lowell Observatory:

…it has only the 1-day arc from 2014, so this is an object that won’t get re(dis)covered except by chance some time downstream. The actual ephemeris uncertainty is ± 360 degrees (at least!). If it was actually near Earth on the one night (and not an artificial satellite, and not simply a bad detection), picking up such an object even one _week_ downstream would have been difficult, much less seven years away.


\Brian

The observation is simply a straight line!

I think it works very similarly to the stand alone software I've used for over 14 years. The initial conditions, integration, and final results are all done using 3D position and velocity vectors. They're only converted to osculating elements for the convenience of the user, who would much rather see osculating elements than 3D position and velocity vectors.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)