Big, bright fast mover (7482) 1994 PC1

[PMSchu]

That's definitely moving right along! Nice shot.

Thanks,

Phil S.

[bigmasterdrago]

Phil, you had asked about the differences in position with elements at the beginning of this thread and more recently. I took a look and found nothing significant. I think because we are using the same elements from the MPC with the same epoch, in theory they should look the same. But a closer look shows that due to the adjustment caused by the gravity influence when getting near us, software can make a difference. Or in the case of ST4, the need to massage the inputs. I made a table of positions and all use the MPC except one that can only use Lowell. It was very educational to see the 3 positions in ST4 given a bit of correct input. Three choices - MPC, MPC NEA Daily or Osculating Elements created by Horizons. Lesson is to always use Osculating for NEAs. Although the MPC NEA Daily can be a much faster exercise and nearly as accurate.

All errors referenced Horizons from my location:

Date_CST  _HR:MN          R.A.          DEC               Azi    Elev    APmag    Software           Error
2022-Jan-18 19:00       01 39 14.10 +08 21 03.6   211.08  64.96   10.395  (Horizons)         0.0"
                                  01 39 13.7  +08 21 07.1    212.3    65.16    9.52  (AstroGrav)         6.6"
                                  01 39 13.8  +08 21 09      211.08   64.28  10.3   (ST4 Osc Els)       8.1"
                                  01 39 13.5  +08 21 13      211.08   64.28  10.4   (ST4 MPCNEADy) 14.0"
                                  01 39 23.1  +08 19 53      211.5     64.7    10.4    (MegaStar 5)       2.5'
                                  01 39 27.4  +08 17 30      210.9     65.25  10.4    (SkyTools 4)        4.9'

---

I was clouded out last night, being only able to spot the fuzzy moon and a couple of bright stars. Strangely, my buddy 25 miles SSW had partial clearing and was able to shoot a series of 30 second images. I'll send a copy when I get it.

[PMSchu]

Hi BMD,

Aren't all of the programs that use the 6 parameters that describe the shape & orientation of the elliptical orbit using osculating elements to approximate the motion? The question is which elements are they using? When ST4v downloads the MPC's 'NEAs at Today's Epoch' elements, there are ~27,000 element sets in the file. As of today, ST4v is using the epoch 2022 Jan 19 0000 UTC as 'Today's Epoch' for the NEAs & the OI displays the epoch as 2022 Jan 18 because it's the evening of Jan 18. 

Currently MPC's 'standard' epoch is 2022 Jan 21 0000 UTC & that's the epoch ST4v uses when it downloads MPCORB since mid-October 2021. At least that's the way it seems to work, Technoking can confirm this. If I understood what Greg was saying, ST4v will use the elements with the epoch from the MPC that are the farthest into the future, either 'Today's' or the 'Standard' & keep those & ignore the other.

Perhaps I've misunderstood something,

Phil S.

[bigmasterdrago]

Most of the software/programs we use have no clue about the effects of bodies other than the Sun. They use the element in a two-body calculation. I think Horizons does different.

If you or I edit those (to get osculating for a date) or use the daily to get a position for today, the positions begin to approximate Horizons. As they should. But get too far away from those dates and gravity of other bodies interfere again to the chart plot.

I'm thinking ST4 uses the element set closest to the date of requested ephemeris. That's why the positions in my table were much better for the daily and osculating vs the default in the bottom line (standard MPC import).

[theskyhound]

I'm thinking ST4 uses the element set closest to the date of requested ephemeris. That's why the positions in my table were much better for the daily and osculating vs the default in the bottom line (standard MPC import).

Yes, SkyTools keeps multiple sets of osculating elements and chooses the one that is best for the date that a position is being calculated for. But it is very important to remember that the epoch that the osculating elements were calculated for is just one factor in how accurate the elements will be. These close approachers are faint, so they can't be observed except when they come close to the earth. As a result, their orbits are not well known due to inadequate astrometric observations.

HORIZONS may appear to be more accurate during a close pass, but the real determination of accuracy is calculating the orbit using new observations as they become available, and new ones tend to come in just before the pass, so the accuracy of the elements gets better and better as that time comes closer. Always update your orbital elements just prior to the pass.

[theskyhound]

Hi BMD,

Currently MPC's 'standard' epoch is 2022 Jan 21 0000 UTC & that's the epoch ST4v uses when it downloads MPCORB since mid-October 2021. At least that's the way it seems to work, Technoking can confirm this. If I understood what Greg was saying, ST4v will use the elements with the epoch from the MPC that are the farthest into the future, either 'Today's' or the 'Standard' & keep those & ignore the other.

Perhaps I've misunderstood something,

Phil S.

This isn't quite correct.

1. SkyTools accumulates orbital elements over time. The set of elements with an epoch that best matches the date of your calculation will be used.

2. In order to make the database efficient, orbital elements are sorted into different "standard epochs" when they are stored. This is a period of time, 200 days long, that orbits are sorted into. The epoch dates in general that you see from the MPC are typically these same standard epochs.

3. The complicating factor is that SkyTools will only store one set of orbital elements for each standard epoch. This is where it got tricky when it comes to NEOs, because the MPC started publishing elements at a standard epoch date in the future, and prior to the version 4.0j R8 update, SkyTools would only update the elements if the epoch was at a later time than the one already in the database.

In the update I changed how that works. There are now cases when a new set of elements will always overwrite the ones already stored for that epoch.

What this means in practice:

When you download the "MPC NEA Today" or "MPC Daily Update" from within SkyTools, the downloaded elements will always overwrite the current orbital elements for the current epoch. That way, you can always update your elements when a close pass is coming up (and the elements improve).

When you manually enter data, such as that from HORIZONS: if you edit an existing set of elements, this will always overwrite what was there before. If you create a new set of elements, be sure it has an epoch more recent than the one in the database. Otherwise it will not overwrite the one already there. Do not kludge the epoch. It must be accurate.

How do you tell things are ok?

1. Open The Minor Planets Database from the Data menu
2. Enter the designation of the minor planet under Designation and press the Enter key.
3. When it finds the minor planet, it will list all of the orbital elements by epoch. Double-click on any one to see the full data.
4. Ensure that there is no set of orbital elements for a date in the future, beyond the date of closest approach. If there is one, delete it, or replace it manually, by editing the data. To delete it, close the Osculating Elements dialog, right-click on the elements you wish to delete, and select Delete Element Set.

[PMSchu]

Hi BMD,

Currently MPC's 'standard' epoch is 2022 Jan 21 0000 UTC & that's the epoch ST4v uses when it downloads MPCORB since mid-October 2021. At least that's the way it seems to work, Technoking can confirm this. If I understood what Greg was saying, ST4v will use the elements with the epoch from the MPC that are the farthest into the future, either 'Today's' or the 'Standard' & keep those & ignore the other.

Perhaps I've misunderstood something,

Phil S.

This isn't quite correct.

1. SkyTools accumulates orbital elements over time. The set of elements with an epoch that best matches the date of your calculation will be used.

2. In order to make the database efficient, orbital elements are sorted into different "standard epochs" when they are stored. This is a period of time, 200 days long, that orbits are sorted into. The epoch dates in general that you see from the MPC are typically these same standard epochs.

3. The complicating factor is that SkyTools will only store one set of orbital elements for each standard epoch. This is where it got tricky when it comes to NEOs, because the MPC started publishing elements at a standard epoch date in the future, and prior to the version 4.0j R8 update, SkyTools would only update the elements if the epoch was at a later time than the one already in the database.

In the update I changed how that works. There are now cases when a new set of elements will always overwrite the ones already stored for that epoch.

What this means in practice:

When you download the "MPC NEA Today" or "MPC Daily Update" from within SkyTools, the downloaded elements will always overwrite the current orbital elements for the current epoch. That way, you can always update your elements when a close pass is coming up (and the elements improve).

When you manually enter data, such as that from HORIZONS: if you edit an existing set of elements, this will always overwrite what was there before. If you create a new set of elements, be sure it has an epoch more recent than the one in the database. Otherwise it will not overwrite the one already there. Do not kludge the epoch. It must be accurate.

How do you tell things are ok?

1. Open The Minor Planets Database from the Data menu
2. Enter the designation of the minor planet under Designation and press the Enter key.
3. When it finds the minor planet, it will list all of the orbital elements by epoch. Double-click on any one to see the full data.
4. Ensure that there is no set of orbital elements for a date in the future, beyond the date of closest approach. If there is one, delete it, or replace it manually, by editing the data. To delete it, close the Osculating Elements dialog, right-click on the elements you wish to delete, and select Delete Element Set.

Thanks Greg,

I've been avoiding the download of MPCORB because of #2 in your list, but #3 after the R8 update fixes that issue. The number of MPs in the DB has been decreasing & is now down to <700k objects. When the MPC changed to the 2022 Jan 21 standard epoch all of the NEO known were updated to that epoch & didn't get the update for 'Today's Epoch'. I didn't notice that R8 fixed that.

Phil S.

[theskyhound]

For goodness sake, Phil, you were one of the beta testers. I would have thought you, of all people, would have known about this specific update. Maybe I failed to explain it fully? Probably. There was a lot going on at the time.

[PMSchu]

Sorry I missed that. I knew you made some improvements to the MP database operations, but didn't catch the change to how the elements were updated. Sorry. Most of my attention in the recent beta testing was on the RT functionality.

Phil S.

[theskyhound]

I don't honestly recall anymore. I likely failed to explain it until now. This isn't something people are supposed to have to think about! Its supposed to "just work."