2021-11-15, 10:34 PM
Hello,
During development, the minor planet database evolved continuously, and it continued to do so even during testing. As a result, some years later now, I had forgotten some changes that were made to the final design. The struggle was to make SkyTools work as fast as possible, even when very large numbers of minor planets were loaded.
I have recently been spending time digging around in that code looking for a lingering bug, and was surprised by something that I discovered. In fact, the minor planets don't work they way that I remembered. I apologize for the confusion that this has likely caused. The last time I did this kind of observation myself, for a very close pass, was before the final changes were made, so my suggestions proved to be out of date.
Here is what I discovered:
1. In addition to the main minor planet database, minor planets are also sorted into "Saved Epochs," that are primarily used for plotting on the charts. Each of these is defined for a "standard epoch," covering a period of 200 days.
2. By design, for speed, these "Saved Epochs" can only have one set of elements for each minor planet
3. When you add orbital elements for a minor planet for the first time, these elements are sorted into the appropriate 200-day standard epoch.
4. When you add a new set of elements for this same minor planet, presumably for a more recent epoch, if the new elements still fall into the same period of time as before--the same standard epoch--the new elements will always overwrite the old ones. That is because of (2) above.
This has obvious implications for very close passes of asteroids. For very close passes, the elements may be perturbed (or changed) significantly by the gravitational attraction of the earth and moon. I had previously suggested that you could store three sets of elements, one created for an epoch just prior to the pass, one during the pass, and one after the pass, and SkyTools would use the appropriate set of elements for each of these time periods. But, in fact, adding new sets of elements with epochs that are that close together, will always overwrite the current elements (during the the standard epoch).
Updated Procedure for Very Close Passes of Minor Planets
It is important to recognize that only the very closest passes of asteroids are going to have a significant change in their orbits (one significant enough to affect the accuracy of the predicted positions) and that for the vast majority of asteroids making a close pass, the elements are not very accurate in the first place, so generating different sets of elements for different times of the night is not appropriate. You can't improve on something that isn't accurate in the first place.
What I suggest is to use a single set of elements defined for an epoch near the time of close pass for planning. As the date of the pass approaches, upload new elements regularly, overwriting the ones you have been using, and update your plan. This should be sufficient for 90% of all close passes.
For a very close pass of an asteroid with well-determined elements, I suggest adding a set of elements calculated at an epoch during the start of your observing period. If you will be observing it at a later time, update the elements again, computed for the epoch of that later time. Repeat as needed. In other words, just keep updating the elements in real time during the pass.
I am updating the help to make this behavior clear in the future.
During development, the minor planet database evolved continuously, and it continued to do so even during testing. As a result, some years later now, I had forgotten some changes that were made to the final design. The struggle was to make SkyTools work as fast as possible, even when very large numbers of minor planets were loaded.
I have recently been spending time digging around in that code looking for a lingering bug, and was surprised by something that I discovered. In fact, the minor planets don't work they way that I remembered. I apologize for the confusion that this has likely caused. The last time I did this kind of observation myself, for a very close pass, was before the final changes were made, so my suggestions proved to be out of date.
Here is what I discovered:
1. In addition to the main minor planet database, minor planets are also sorted into "Saved Epochs," that are primarily used for plotting on the charts. Each of these is defined for a "standard epoch," covering a period of 200 days.
2. By design, for speed, these "Saved Epochs" can only have one set of elements for each minor planet
3. When you add orbital elements for a minor planet for the first time, these elements are sorted into the appropriate 200-day standard epoch.
4. When you add a new set of elements for this same minor planet, presumably for a more recent epoch, if the new elements still fall into the same period of time as before--the same standard epoch--the new elements will always overwrite the old ones. That is because of (2) above.
This has obvious implications for very close passes of asteroids. For very close passes, the elements may be perturbed (or changed) significantly by the gravitational attraction of the earth and moon. I had previously suggested that you could store three sets of elements, one created for an epoch just prior to the pass, one during the pass, and one after the pass, and SkyTools would use the appropriate set of elements for each of these time periods. But, in fact, adding new sets of elements with epochs that are that close together, will always overwrite the current elements (during the the standard epoch).
Updated Procedure for Very Close Passes of Minor Planets
It is important to recognize that only the very closest passes of asteroids are going to have a significant change in their orbits (one significant enough to affect the accuracy of the predicted positions) and that for the vast majority of asteroids making a close pass, the elements are not very accurate in the first place, so generating different sets of elements for different times of the night is not appropriate. You can't improve on something that isn't accurate in the first place.
What I suggest is to use a single set of elements defined for an epoch near the time of close pass for planning. As the date of the pass approaches, upload new elements regularly, overwriting the ones you have been using, and update your plan. This should be sufficient for 90% of all close passes.
For a very close pass of an asteroid with well-determined elements, I suggest adding a set of elements calculated at an epoch during the start of your observing period. If you will be observing it at a later time, update the elements again, computed for the epoch of that later time. Repeat as needed. In other words, just keep updating the elements in real time during the pass.
I am updating the help to make this behavior clear in the future.