Thanks to the kind efforts of
Andrea Pelloni, Roberto Haver, and Fabio Anzellini, an Italian
version of this site is also available
- Level Two Menu
- Specifying attributes of, and executing operations on, the subject minor
planet
For several
operations (e.g., processing visual magnitude data, looking for known bodies
whose positions agree with the observations of the subject minor planet), it is
critical that CODES understand whether the subject minor planet is a comet or
an asteroid.
Thus, this
designation should be made immediately upon creating a new minor planet.
From the Level Two
Menu, simply click on "Designate"; on the resulting frame, select
whether the minor planet is a comet or asteroid, then click on
"Submit".
The designation
being made, CODES will save the data to disk and return to the Level Two Menu.
From the Level Two
Menu, simply click on "Add". From the resulting frame, the user can
then select from the following options:
Simply click on
"Optical". The user will then encounter three successive frames:
The first frame
allows the user to specify the UTC date of the optical observation, the
astrometric right ascension and declination (with uncertainties), the visual
magnitude, and the fundamental catalog/epoch to which the observation refers.
Note: CODES supports observations and predictions for the
range 1900-2200.
The second frame
allows the user to specify either the MPC observatory code, or the geodetic
latitude, east longitude, and altitude, from which the observation was made.
Additionally, the user may check a box telling CODES to generate default Earth
Orientation Parameters; the third frame would then be skipped.
Note: For typical optical observations, where
uncertainties are on the order of 0.1 arc seconds or greater, the default
EOPs generated by CODES are sufficient.
The third frame
allows the user to specify the Earth Orientation Parameters (EOPs) at the time
of the observation. EOPs allow calculation of the ultra-precise location of the
observer. These EOPs include the x and y coordinates of the Celestial Ephemeris
Pole, the values of UT1-UTC, and the Celestial Pole Offsets dPsi and dEpsilon.
(Note that these EOPs are required for four dates surrounding the observation;
Besselian interpolation is then used to approximate the values of the EOPs at
the precise observation time.) Additionally, the user must specify the number
of leap seconds and the Earth's angular velocity at the time of observation.
Note: The option to specify EOPs for optical observations
will allow future support of more precise astrometric techniques.
Note: An excellent source of EOPs is the International
Earth Rotation Service (IERS) web site.
IMPORTANT: Do not leave any data fields blank! This can cause a
run-time error.
IMPORTANT: From either of the three input frames, it is possible to cancel
the input function and return to the Level Two Menu; the new
(and incomplete) observation will be deleted.
When complete,
CODES will save the data to disk and return to the Level Two Menu.
Simply click on
"Radar". The user will then encounter three successive frames:
The first frame
allows the user to specify the UTC time of observation, whether this
observation is a delay or a doppler measurement, the measurement and its
uncertainty, and the transmitter frequency.
Note: CODES supports observations and predictions for the
range 1900-2200.
The second frame
allows the user to specify the location of both the transmitter site and the
receiver site. In each case, the user may either select one of several common
radar sites (in which case the lat/long/alt data fields may safely be left
blank), or select "other" and specify the geodetic latitude, east
longitude, and altitude of the transmitter/receiver.
The third frame
allows the user to specify the Earth Orientation Parameters (EOPs) at the time
of the observation. EOPs allow calculation of the ultra-precise location of the
observer. These EOPs include the x and y coordinates of the Celestial Ephemeris
Pole, the values of UT1-UTC, and the Celestial Pole Offsets dPsi and dEpsilon.
(Note that these EOPs are required for four dates surrounding the observation;
Besselian interpolation is then used to approximate the values of the EOPs at
the precise observation time.) Additionally, the user must specify the number
of leap seconds and the Earth's angular velocity at the time of observation.
Note: For radar data, accuracies of 0.1 microsecond or 30 meters
are typical. My sensitivity analyses indicate that 1 meter accuracy could be
supported without interpolating the published EOPs. However, the
state-of-the-art is advancing so rapidly that I feel it prudent to accommodate
future radar technology (up to 0.1 meter accuracy); thus, second-order
interpolation of the EOPs is used.
Note: An excellent source of EOPs is the International
Earth Rotation Service (IERS) web site.
IMPORTANT: Unless otherwise noted, do not leave any data fields
blank! This can cause a run-time error.
IMPORTANT: From either of the three input frames, it is possible to cancel
the input function and return to the Level Two Menu; the new
(and incomplete) observation will be deleted.
When complete,
CODES will save the data to disk and return to the Level Two Menu.
The Minor Planet
Center (MPC) provides free web-based electronic circulars
containing formatted tables of new observations of recently discovered and
high-interest minor planets. The MPC also provides an Extended Computer Service
called MPCOBS which enables users to extract files containing all observations
of a specific minor planet.
With some help from
the user, CODES can batch-process the entire set of observations contained in
each of these files, thus avoiding the need for manual input.
Simply click on
"MPC". The next frame will ask the user to save the MPEC or MPCOBS
file (from the web browser or text editor) as ''mpec.txt'' in the ''codes''
folder, using file-type "text file" or ''text-only".
IMPORTANT: Some MPECs include observations of many minor
planets. In such cases, the user should edit out the observations of other
minor planets, leaving only the observations of the desired minor planet.
Note: Users will often want to refine computed orbits (and
collision analyses) using additional observations as they become available.
However, MPECs and MPC files list all observations of the subject minor
planet, including those which CODES has (presumably) previously processed. To
avoid the creation of duplicate entries, CODES checks each observation as it is
being processed; if an observation with the same date, observation location,
and measurement already exists, CODES will ignore this observation and skip to
the next.
When ready, simply
click on "Process".
The MPC format
allows CODES to extract the following data for each observation:
- UTC time of observation (receive-time for
radar observations)
- observational measurement plus uncertainty
(right ascension, declination, and visual magnitude for optical
observations, delay and/or doppler for radar observations)
- Observer location (including MPC observatory
code for fixed optical observations, lat/long/alt for roving observers,
x/y/z for satellite observations, and both transmitter and receiver MPC
observatory codes for radar observations)
CODES then
generates default Earth Orientation Parameters and processes the observation.
IMPORTANT: At present, the default EOPs determine observer
position to within about 1 km. While this accuracy is sufficient for current
optical observations whose precision average about 0.1 arc seconds (and
irrelevant for satellite observations, whose observer positions are read
directly from the observation data record), it will not fully support
highly-precise radar delay and/or doppler observations. The user is
therefore strongly urged to edit out any radar observations from MPECs and
MPCOBS files prior to processing, then enter these radar observations manually,
including precise EOPs (available from the IERS web
site).
IMPORTANT: The MPC is constantly certifying new contributing
observatories. If a user were to process an MPEC or MPCOBS file containing observations
from a new observatory that is not on the CODES look-up table, the quality of
derived data would be severely degraded. The user is therefore advised to
periodically either check this web site or contact me for updated copies of the "ObsCode.txt"
file. New versions of the file should overwrite the existing version in the
"codes" folder/directory.
Note: CODES supports observations and predictions for the
range 1900-2200.
When complete,
CODES will save the data to disk and return to the Level Two Menu.
The Near-Earth
Objects Dynamic Site (NEODyS) provides web-based data on every known Near-Earth
Object (NEO). Start at the search page,
and enter the name, number, or designation of an NEO; a web page is dynamically
created providing the user with data on that NEO.
Near the bottom of
the web page, under "Observational Information:", click on the
"ASCII file" link. The user will be provided with a formatted table
containing all known observations of the NEO. With some help from the user,
CODES can batch-process the entire set of observations, thus avoiding the need
for manual input.
Simply click on
"NEODyS". The next frame will ask the user to save the NEODyS file
from the web browser as ''neodys.txt'' in the ''codes'' folder, using file-type
"text file" or ''text-only".
Note: Users will often want to refine computed orbits (and
collision analyses) using additional observations as they become available.
However, NEODyS files list all observations of the subject minor planet,
including those which CODES has (presumably) previously processed. To avoid the
creation of duplicate entries, CODES checks each observation as it is being
processed; if an observation with the same date, observation location, and
measurement already exists, CODES will ignore this observation and skip to the
next.
When ready, simply
click on "Process".
The NEODyS format
allows CODES to extract the following data for each observation:
- UTC time of observation (receive-time for
radar observations)
- observational measurement plus uncertainty
(right ascension, declination, and visual magnitude for optical
observations, delay or doppler for radar observations)
- Observer location (including MPC observatory
code for fixed optical observations, and both transmitter and receiver
MPC observatory codes for radar observations)
CODES then
generates default Earth Orientation Parameters and processes the observation.
IMPORTANT: At present, the default EOPs determine observer
position to within about 1 km. While this accuracy is sufficient for current
optical observations whose precision average about 0.1 arc seconds (and
irrelevant for satellite observations, whose observer positions are read
directly from the observation data record), it will not support highly-precise
radar delay and/or doppler observations. The user is therefore strongly
urged to edit out any radar observations from NEODyS files prior to processing,
then enter these radar observations manually, including precise EOPs
(available from the IERS web site).
IMPORTANT: The MPC is constantly certifying new contributing
observatories. If a user were to process a NEODyS file containing observations
from a new observatory that is not on the CODES look-up table, the quality of
derived data would be severely degraded. The user is therefore advised to periodically
either check this web site or contact me
for updated copies of the "ObsCode.txt" file. New versions of the
file should overwrite the existing version in the "codes" folder.
IMPORTANT: There are currently no "roving observer" or
satellite-based observations of Near-Earth Objects in the NEODyS database.
Should they appear in the future, I believe "roving observer"
observations would be listed in a NEODyS file with observatory code
"247", while satellite observations would be listed with observatory
code "248" (Hipparcos), "249" (SOHO), or "250"
(Hubble Space Telescope). Since there is no fixed position associated with
these observatories, there is no way to accurately calculate the observer
position with the data provided. The user is therefore urged to get the data
for these observations from an MPEC or MPCOBS file.
Note: CODES supports observations and predictions for the
range 1900-2200.
When complete,
CODES will save the data to disk and return to the Level Two Menu.
This option permits
the user to review the observations that exist for the given minor planet, and
to exclude those observations (if desired) which are found to have
exceptionally high residuals.
From the Level Two Menu, simply click "Rev/Del". From the resulting
frame, the user can review observations five-at-a-time. The user can delete one
or more of the displayed observations by checking the box to the left of the
observation(s), then clicking "Delete Checked". When more than five
observations exist, the user can click on the "Next 5" and "Prev
5" buttons to cycle through the entire list.
When done, simply
click on "Done"; CODES will save the data to disk and return to the Level Two Menu.
Simply click on
"Compute". From the resulting menu, select one of the four options:
Once at least three
observations exist for a minor planet, it is possible to calculate an initial
orbit using two-body mechanics (This initial orbit can later be refined by using
integrated n-body mechanics to calculate a best-fit least-squares orbit - see
"Compute an n-body best-fit orbit").
If only two observations exist, an orbit can be estimated based on
additional user-inputs.
Simply click "Initial". On the resulting frame,
use the drop-down menus to select which three observations to use in calculating the initial orbit. (Note: Only the first two selections will be
used in Herget's method.)
Knowing which
observations to use requires some judgment. The objective is to cover a
significant arc of the full orbit. For distant minor planets such as
Trans-Neptunian Objects, it may be necessary to have an arc of data covering
tens or even hundreds of days to get a good initial orbit; conversely, a
Near-Earth Object or a minor planet in the main asteroid belt may require an
arc of just a few days. My best advice is to experiment. If all of the initial
orbit methods diverge or give absurdly high residuals, pick another set of
observations.
Once the user has
made the selections, simply press "Submit". From the resulting menu,
the user must now select which method of initial orbit determination to try.
I have attempted to
make these methods as robust as possible. However, each algorithm has inherent
limits.
- The Gauss method is clearly the very best, and
it is always my first choice. If the iterative algorithm is successful,
the calculated orbit will contain the three observations; thus, you can
immediately accept the orbit (and skip differential correction, since
the residuals will be near zero). However, Gauss is sometimes less
successful for Near-Earth Objects.
Simply click on
"Gauss". The resulting frame will display the calculated state vector
and derived orbital elements for the minor planet at the TDB time of the first
selected observation. The two-body residuals for each selected observation will
be displayed, as well as a message warning if the iterative algorithm has
diverged (in which case the first-approximation to the orbital elements/state
vector is displayed).
The user will have several options.
1.
If satisfied with the
initial orbit, simply click on the "Select" button next to
"Accept This Orbit"; the initial orbit will be saved to disk, and
CODES will return to the Level Two Menu.
2.
If the residuals are
non-zero, the user may elect to click on the "Select" button next to
"Apply Differential Correction". The same frame will appear,
displaying the resulting state vector and derived orbital elements for the
minor planet at the TDB time of the first selected observation. The two-body
residuals for each selected observation will be displayed, as well as a message
warning if the differential correction algorithm has diverged (in which case
the original Gauss method orbital elements/state vector is displayed). When
differential correction converges successfully to zero residuals, the user can
accept the orbit. But when differential correction diverges, it's usually
necessary to try another method, or to select another set of three observations.
3.
If the Gauss method
and/or differential correction have diverged, the user may elect to click on the "Select" button next to
"Try Another Method". In this case, the three selected observations
are retained, and CODES returns to the menu of methods of initial orbit
determination.
4.
If none of the three
methods of initial orbit determination has converged successfully, the user may elect to click on the
"Select" button next to "Try a Different Set of Three
Observations". In this case, CODES returns to the frame with the drop-down
menus to select a new set of three observations, followed by the frame to select one of the three
methods of initial orbit determination.
5.
If the user wishes to
exit the initial orbit determination process, simply click on the
"Select" button next to "Quit"; no initial orbit will be
saved, and CODES will return to the Level Two Menu.
- The conditioned Gauss method requires the user
to initialize the algorithm by providing a guess for the semi-major
axis. Since it is mostly used for Near-Earth Objects, a guess of
"1.0" is a good starting point.
Simply click
"conditioned Gauss". From the next frame, enter a guess for the
semi-major-axis and click on "Submit". The resulting frame will
display the calculated state vector and derived orbital elements for the minor
planet at the TDB time of the first selected observation. The two-body
residuals for each selected observation will be displayed, as well as a message
warning if the iterative algorithm has diverged (in which case the
first-approximation to the orbital elements/state vector is displayed).
The user will have
the same options as in the case of the Gauss Method, with one addition:
1.
If the resulting residuals
are too high and differential correction has diverged, the user may elect to
click on the "Select" button next to "Try Another Value of
Semi-Major Axis". In this case, CODES returns to the frame where the user
can provide another guess.
If the user's guess
for the semi-major axis is close to the correct value, the calculated orbit
will contain the first and second selected observations, with a small residual
(approx. 10 arc seconds or less) on the third selected observation. Use of
differential correction usually improves the fit, and allows you to accept the
orbit.
If the user's guess
for the semi-major axis is not close to the correct value, the residual on the
third selected observation will be large (approx. 10 arc seconds or greater).
In this case, differential correction may diverge. Try different values for the
semi-major axis, attempting to minimize the residual on the third selected
observation.
- The Laplace method is usually the method of
last resort; it is sometimes useful for closely-spaced observations (as
is often the case with TNOs). Differential correction will always be
required here, since the calculated orbit will rarely include any of
the three selected observations.
Simply click
"Laplace method". The resulting frame will display the calculated
state vector and derived orbital elements for the minor planet at the TDB time
of the second selected observation. The two-body residuals for each selected
observation will be displayed, as well as a message warning if the iterative
algorithm has diverged (in which case the first-approximation to the orbital
elements/state vector is displayed).
The user will then
have the same options as in the case of the Gauss Method.
·
Herget's method
requires the user to initialize the algorithm by providing guesses for the
slant range at the time of each selected observation. Testing has shown that multiple solutions may
exist for closely-spaced observations, and for small slant ranges; my current
recommendation would be to apply this method for objects no closer than the
main-belt.
Simply click
"Herget's method". The
algorithm will create an estimate of the state vector at the time of the first
selected observation. If the user
specifies, least-squares will then be applied in an attempt to refine this
state vector by minimizing its residuals for all available
observations. If least-squares converges, the resulting state vector will actually be an
n-body best-fit orbit. If least-squares does not converge, the residuals could be quite large.
The resulting frame
will display the calculated state vector and derived orbital elements for the
minor planet at the TDB time of the first selected observation. The n-body RMS
residuals will be displayed, as well as a message warning if least squares
diverged (in which case the first-approximation to the orbital elements/state
vector is displayed).
The user will then
have the same options as in the case of the conditioned Gauss method, except
that "Apply differential correction" is replaced by "Apply least
squares", and "Try another value of Semi-Major Axis" is replaced
by "Try another value of Slant Range".
Important
Note: The set of initial orbital
elements displayed by each of the above methods will depend upon whether the
user has designated this minor planet as an asteroid or comet. It is therefore
vitally important that the user make
the appropriate selection before
beginning this option.
This option allows
the user to refine the existing orbit for the minor planet (either a calculated
initial orbit, or an orbit specified by the user) in the least-squares sense,
using numerical integration and n-body mechanics. The products are the best-fit
state vector plus covariances (based on the observational uncertainties), the
derived orbital elements plus covariances, the calculated residuals for each
observation, the visual absolute magnitude and slope parameter (if apparent
magnitude observations are available), and an order-of-magnitude estimate of
the minor planet's radius (asteroids only, and subject to whether the visual
absolute magnitude and slope parameter are available). Additionally, if
the minor planet is potentially hazardous, an estimate of the Minimum Orbital
Intersection Distantce (MOID) will be provided.
To calculate the
best-fit orbit, simply click "Best-Fit". From the resulting frame,
select whether to account for cometary thrusting through the use of
non-gravitational thrust parameters, and select whether to exclude any
observations that exceed specified chi or residual thresholds; then click
"Begin".
As noted, these
calculations can take a great deal of time, depending on the computer
processor, the total number of observations, the calendar arc of the
observations, and the number of perturbing asteroids being used in the
calculations.
Some important
notes:
- This option uses n-body mechanics, accounting
for
1.
gravitational
perturbations (including relativistic effects) from the Sun, nine planets,
Earth's Moon, and as many asteroids as the user has specified; as a result, it
is very important that the user select
the desired number of perturbing bodies
from the Level Two Menu before attempting to calculate the best-fit orbit.
2.
solar radiation pressure
(assuming a spherical shape)
3.
solar oblateness (J2
effects)
4.
cometary thrusting, if
the user so specifies.
- Use of non-gravitational thrust parameters in
best-fit orbit determination
The orbits of
nearly all asteroids can be calculated with very high accuracy using a
relativistic gravity model. However, the tails of comets are basically small
rocket engines, propelling them approximately away from the Sun. This
propulsive force must be modeled to enable calculation of cometary orbits with
acceptably small residuals.
The
non-gravitational thrust parameters include both a radial (A1) and a transverse
(A2) component; these components can be calculated by CODES as part of the
least-squares best-fit process if the user selects this option.
The parameters also include a perihelion time offset
(DT), which is sometimes useful in
further reducing residuals. However, DT is not determined as part of the
best-fit orbit. Rather, the value of DT (default = 0) can specified using the
"Specify minor planet's orbit" option from the Level Two Menu; the user should
then recalculate the observational residuals, and iteratively vary DT in
increments of 5 days (up to values of +/- 60 days) to find the value of DT
which minimizes the residuals.
If the user is
studying an asteroid or a comet with few observations, the non-gravitational
thrust parameters are not needed. But if the user is analyzing the motion of a
comet over a long arc, the user may get much lower residuals by electing to
solve for the best-fit orbit using these parameters. (Note also that the orbit
of at least one Near-Earth Asteroid, which may be the stony nucleus of a
now-expired comet, also requires the use of non-gravitational thrust
parameters; thus, the user may elect to use these parameters regardless of
whether they have designated the minor planet as a comet or asteroid.)
- Excluding observations with excessive chi or
residuals
This option allows
the user to set thresholds for chi, or for optical, delay, and doppler
residuals. If enabled, the least-squares algorithm will first converge to a nominal
solution using all observations; it will then continue for one or more
additional iterations, this time excluding any observations exceeding the
specified thresholds. The resulting final orbit will thus not be impacted by
unreliable data (as defined by the user).
Note that the user
could just as easily determine the best-fit orbit using all observations,
manually delete those with excessive chi or residuals, then find the new best-fit
orbit (sometimes having to repeat the process several times as changes in the
best-fit orbit alternately include or exclude some observations); this option
allows CODES to automate the process. Moreover, this option does not
permanently delete excluded observations, but rather simply ignores them; this
will allow these observations to be reconsidered in future runs, should
additional observations change the best-fit orbit enough to make their
departures permissible.
Any excluded
observations are marked with an asterisk in the resulting frames and file
output.
- Determining the best-fit orbit using
observations spanning many years
The least-squares
process often begins by using the initial two-body orbit to calculate the
residual (in the sense of "observed - computed") for each
observation. However, if the date of an observation differs from the epoch of
the two-body orbit by two or more months, it is likely that the residual will
be quite large. For observations spread over several decades, the problem
becomes severe, and it is quite possible that the least-squares algorithm will
diverge.
To address this
problem, I suggest the following procedure:
1.
First, enter only
observations in a one-month period of time. Find the initial orbit, and then
the best-fit orbit for these observations. Note the epoch.
2.
Enter the
observations from the one-year period of time around the epoch. Find the
best-fit orbit for these observations.
3.
Enter the rest of
the observations, and find the final best-fit orbit.
(The suggested
periods of time will vary depending on the perturbations experienced by the
subject minor planet. For observations during close approaches by NEAs, the
initial orbit may only span a few days, and the first attempt at a best-fit
orbit may be limited to a week-long span.)
- Radar observations and the radius of the
subject minor planet
The inherent
precision of radar observations is such that CODES must account for the radius
of the subject minor planet (estimating the "bounce point") when
calculating the orbit of its center-of-mass. If apparent magnitude data is
available, the least-squares algorithm can make an order-of-magnitude estimate
of an asteroid's radius after the first iteration, and refine this estimate on
subsequent iterations. But this is not currently possible for comets, and it is
clearly not possible in the absence of apparent magnitude data. In these latter
cases, it is therefore very important that the user specify
the radius from the Level Two Menu
prior to a best-fit calculation involving radar observations.
- Brightness parameters and asteroid radius
When the best-fit
orbit of the subject minor planet is calculated, CODES uses apparent magnitude
data (if available) to estimate (using different algorithms, depending on
whether the object is a comet or asteroid) the absolute magnitude and slope
parameter. Thus, it is very important that the user select
whether the minor planet is an asteroid or comet before attempting the calculate
the best-fit orbit.
For asteroids, the
slope parameter is subsequently used to estimate the albedo, itself resulting
in an order-of-magnitude estimate of the radius.
- Important Note: The set of best-fit orbital elements
displayed will depend upon whether the user has designated this minor
planet as an asteroid or comet. It is therefore vitally important that
the user make the appropriate selection before beginning this option.
When the best-fit
calculations are complete, the new orbit is saved to disk, and the results are
summarized in the file "(minor planet name)_best_fit_output.txt" in
the "codes" folder.
The resulting
frames successively display the residuals for each observation, the estimated
physical properties of the minor planet (deduced from apparent magnitude data,
if available), and the calculated state vector and orbital elements. To return
to the Level
Two Menu at any point, simply press
"Done".
As noted above,
this option can be useful in determining
the perihelion time offset; it can
also be used to determine the residuals for a completely
user-specified orbit.
The calculations
use the same n-body mechanics described above, so it is very important
that the user select the desired number of perturbing bodies from the Level Two Menu before attempting to
calculate the residuals. Moreover, if A1 and/or A2 have non-zero values in the current
state vector/orbital elements, the contributions from the non-gravitational
thrust parameters (including DT) will also be accounted for.
When the residuals
calculations are complete, the results are summarized in the file "(minor
planet name)_ compute_residuals_output.txt" in the "codes"
folder.
The resulting
frames successively display the residuals for each observation, the estimated
physical properties of the minor planet (deduced from apparent magnitude data,
if available), and the current state vector and derived orbital elements. To
return to the Level
Two Menu at any point, simply press
"Done".
This option can be used
to propogate the current orbit to another epoch.
As noted
previously, the product of initial orbit determination is a state vector (and
derived set of orbital elements) referenced to the TDB time of either the first
or second selected observation.; this option can be used to propogate the
initial orbit to an epoch that is more commonly used or referenced.
If the current
orbit includes covariances in the state vector (e.g., a best-fit orbit), these
covariances are also propogated to the new epoch.
The calculations
use the same n-body mechanics described above, so it is very important
that the user select the desired number of perturbing bodies from the Level Two Menu before attempting to calculate
the residuals. Moreover, if A1 and/or A2 have non-zero values in the current
state vector/orbital elements, the contributions from the non-gravitational
thrust parameters (including DT) will also be accounted for.
When the
calculations are complete, the new orbit is saved to disk, and the results are
summarized in the file "(minor planet name)_
propogate_epoch_output.txt" in the "codes" folder.
The resulting
frames successively display the calculated state vector and derived orbital
elements. To return to the Level Two Menu
at any point, simply press "Done".
Important
Note: The set of orbital
elements displayed will depend upon whether the user has designated this minor
planet as an asteroid or comet. It is therefore vitally important that the user
make the appropriate selection before beginning this option.
This option can be
used to display (but not to change) the current state vector (plus covariances) and
derived orbital elements (plus uncertainties), referred to the currently
specified epoch.
Important
Note: The set of orbital
elements displayed will depend upon whether the user has designated this minor
planet as an asteroid or comet. It is therefore vitally important that the user
make the appropriate selection before beginning this option.
To return to the Level Two Menu at any point, simply press "Done".
In CODES, it is not
necessary that the orbit of a minor planet be calculated from observations.
This option allows the user to directly enter the state vector (plus
covariances) or orbital elements (plus covariances) for the subject minor
planet. The user can also specify the epoch, and enter values for the
non-gravitational thrust parameters A1(plus covariance), A2 (plus covariance),
and DT.
This user-specified
orbit can be used to initialize the best-fit
orbit determination process; or it
can be used directly to calculate an ephemeris or to check
for planetary collisions/near-misses.
Simply type or
paste the desired values into the appropriate data fields. When finished,
simply press "Submit", and the new orbit will be saved to disk; CODES
will automatically return to the Level Two Menu.
Important
Note: The set of classical
orbital elements available for data entry will depend upon whether the user has
designated this minor planet as an asteroid or comet. It is therefore vitally
important that the user make
the appropriate selection before
beginning this option.
IMPORTANT: The user should never leave a relevant data-input
field blank. If no data is available (e.g., the non-gravitational thrust
parameters are not being used), the fields should be filled with zeroes.
IMPORTANT: It is possible to cancel this input
function and return to the Level Two Menu; the
pre-existing orbit will remain unchanged.
o
Import a minor
planet from the MPCORBcr or COMET catalogs
In CODES, it is not
necessary that the orbit of a minor planet be calculated from observations. This
option allows the user to import the orbital elements from the appropriate MPC
database.
This MPC-derived
orbit can be used to initialize the best-fit
orbit determination process;
or it can be used directly to calculate
an ephemeris or to check for planetary collisions/near-misses. Note that,
since the MPC databases do not provide values for the non-gravitational thrust
parameters, the user would either have to specify them manually,
or solve for
them using least-squares.
First, the user
must be sure to have designated
the subject minor planet as either a comet or asteroid. This is vitally important, since CODES will
import orbital elements from the MPCOBScr database for asteroids, and from the
COMET database for comets.
Next, the user must
ensure that the "codes" folder/directory contains a recent
version of the Minor Planet Center database of all comets or asteroids for whom
reasonably reliable orbits exist:
Simply select the
minor planet's MPC designation from the drop-down list, and press
"Import"; CODES will read the minor planet's orbital elements from
the corresponding MPC database, and save them to disk. CODES will then automatically return to the Level
Two Menu.
Important Note:
Due to the size of the MPCOBScr (asteroid) database, the user may notice a lag
associated with selecting and processing this option.
Important Note:
In some JREs, processing the MPCOBScr (asteroid) database may result in a
"java:OutOfMemory" run-time error.
This is caused by the JVM heap exceeding its default 64MB maximum
size. If this occurs, close the CODES
session, and begin a new session with the invocation "java -Xmx200m
GUI"; this will increase the maximum size of the JVM heap to 200 MB, which
should suffice.
This option allows
the user to determine if a known comet or asteroid might correspond to the
observations of the subject minor planet. The reliability of the results depend
upon whether two-body or integrated n-body mechanics are used, how many
perturbers are included in the n-body integrations, the level of integration
accuracy selected, and whether the epoch of the
utilized Minor Planet Center database is near the times of observation. These
same factors also impact the time needed for the calculations, as does the far
larger size of the asteroid database.
First, the user
must be sure to have designated the subject minor planet as either a comet
or asteroid. This is vitally
important, since CODES will seek candidates from among completely different
databases in each case. Too, if integrated n-body mechanics are to be used, the
user should select the desired number of perturbing bodies from the Level Two Menu before attempting this
search.
Next, the user must
ensure that the "codes" folder/directory contains a recent
version of the Minor Planet Center database of all comets or asteroids for whom
reasonably reliable orbits exist:
For comets, the
user can select between two-body and integrated n-body mechanics. The
integrated n-body mechanics account for gravitational perturbations (including
relativistic effects) from the Sun (including J2 oblateness), nine
planets, Earth's Moon, and as
many asteroids as the user has specified;
provision is also made for solar radiation pressure. However, since the MPC
"COMET.DAT" database does not list the cometary thrust parameters A1,
A2, and DT, no use can be made of them here.
For asteroids, the user
can also select between using two-body and integrated n-body mechanics.
However, since the asteroid database is so much larger, and since integrated
n-body mechanics is so time-consuming, I have made the assumption that the user
might be able to use the observed apparent motion of the subject minor
planet to classify it as either a NEA, main-belt asteroid, or Centaur/TNO. Thus, I have given the user the option to narrow the candidate search
accordingly (thus reducing processing time) when using integrated n-body
mechanics. Additionally, I've provided options to narrow the n-body candidate
search based on estimates of the minor planet's absolute magnitude, which can
be determined as part of the best-fit orbit determination process.
For both comets and
asteroids, the user can substantially reduce n-body processing time by
selecting "medium" integration accuracy. Whereas the "high" accuracy option
ensures that the local error in final position will not exceed 0.9 km, the
medium option restricts the local error in final position to 0.1 Earth radii;
however, this larger position error (usually smaller than ignoring the parallax
effect on an Earth-bound observer relative to geocentric) only translates to
0.06 arcseconds at 1.5 AUs, and to 33 arcseconds at 1 lunar distance. Except for very fast-moving (and thus
presumably very close) NEOs, this tradeoff is usually quite feasible,
especially given the substantial reduction in processing time. If necessary, any candidates identified in a
medium accuracy n-body search can be reevaluated at high accuracy by creating a
new MPCOBScr.DAT or COMET.DAT file in which all non-candidates are
removed.
Once the user
clicks "Process", CODES reads each entry in the appropriate database,
extracts the orbital elements, uses either two-body or n-body mechanics to
predict the astrometric position of the catalog object at the TDB time of each
observation of the subject minor planet, and calculates the RMS residual. If
the RMS residual is less than three arc degrees, and if the residual for each
observation is also less than three degrees, the catalog object is classified
as a candidate. An ordered list of all candidates is compiled, and the full
candidate list is reported to the user upon completion in both screen and file
(MPC_compare_output.txt in the "codes" folder/directory) output.
When finished
reviewing the screen output, simply press "Done"; CODES will return
to the Level
Two Menu.
This option allows
the user to create an astrometric ephemeris for the subject minor planet.
For a topocentric
ephemeris, the user must specify an observatory code or the observer's position
(latitude, longitude, altitude); a geocentric option is also available. The
user must also specify the UTC start and end dates, as well as the interval at
which ephemerides should be generated.
In generating the
predicted ephemerides, CODES uses the last saved state vector for the subject
minor planet:
- Integrated n-body mechanics is used, accounting
for gravitational perturbations (including relativistic effects) from
the Sun, nine planets, Earth's Moon, and as many asteroids as the user
has specified; as a result, it is very important that the user select the desired number of perturbing bodies from the Level Two Menu before attempting to
calculate the ephemeris. Provision is also made for solar radiation
pressure. Additionally, if the last saved state vector has non-zero
cometary thrust parameters (A1, A2, DT), their influence will also be
accounted for.
- Finally, if the visual absolute magnitude and
slope parameter are non-zero, CODES will estimate (for phase angles
between zero and 120 degrees) the predicted apparent visual magnitude
for each entry. However, since CODES uses different algorithms in
calculating the visual apparent magnitude for comets and asteroids, it
is very important that the user designate the subject minor planet accordingly from the Level Two Menu before attempting to
calculate the ephemeris.
The following data
are generated for each entry in the ephemeris:
- Astrometric Right Ascension and Declination
- Predicted Visual Magnitude
- The position angle and the semi-major and
semi-minor axes of the 3-sigma error ellipse (assuming covariance data
exists for the orbital elements/state vector of the subject minor
planet)
- The speed and position angle of the minor
planet's apparent motion
- The observer-minor planet distance(delta), the
Sun-minor planet distance (r), and the apparent elongation of the minor
planet from the Sun as seen by the observer.
When calculations
are complete, CODES displays the ephemeris in tabular format. A file version of
the ephemeris is also created at "ephemeris_output.txt" in the
"codes" folder.
Note: CODES supports observations and predictions for the
range 1900-2200.
The user may click
"Done" to return to the Level Two Menu.
Once all available observations have been processed,
and a best-fit orbit has been
calculated, this option allows the user to identify potential collisions
and/or near misses that the subject minor planet may experience with the Sun,
nine planets, or Earth's Moon. Two search methods are available: The linear
method is limited to encounters experienced by the current nominal state
vector, while the nonlinear method is a more exhaustive survey employing a
user-specified number of variant state vectors. The user should select the
radio button next to the desired method.
In each case, the
user must specify the threshold (in A.U.s) for a near-miss, as well as the
desired integration accuracy. When the user clicks "Select" next to
the desired search timeframe, CODES begins searching for collisions and/or
near-misses from the epoch of the last-saved state vector to the desired
endpoint.
In the linear
method, CODES begins propogating the nominal state vector and covariance matrix
from the current epoch to the desired endpoint. Integrated n-body mechanics is
used, accounting for gravitational perturbations (including relativistic
effects) from the Sun, nine planets, Earth's Moon, and as many asteroids as the
user has specified; as a result, it is very important that the user select
the desired number of perturbing bodies
from the Level Two Menu before attempting to calculate the ephemeris. Provision
is also made for solar radiation pressure. Additionally, if the last saved
state vector has non-zero cometary thrust parameters (A1, A2, DT), their
influence will also be accounted for.
At the end of each
integration time-step, CODES checks whether the distance between the subject
minor planet and a solar system body (Sun, nine planets, Earth's Moon) is less
than the radius of that solar system body; if so, CODES assumes a collision has
occurred, uses bisection to determine the precise moment of collision, and uses
the state vector covariances to estimate the probability of collision. If no
collision is detected at the end of the integration time-step, CODES looks for
sign changes in the first derivative of the distance to each solar system body
that might indicate a relative minimum in distance; if found, bisection is used
to determine the precise minimum distance, and this minimum distance is
compared to the radius of the solar system body to determine whether a
collision (distance < radius) or near-miss (distance < near-miss
threshold) has occurred. Again, if a collision is predicted, CODES uses
bisection to determine the precise moment of collision, and uses the state
vector covariances to estimate the probability of collision. If a near-miss is
predicted, CODES again uses the state vector covariances to estimate the
probability of collision.
Important: Multiple close encounters can significantly magnify
the growth of state vector covariances with time, and substantially reduce the
reliability and relevance of long-term forecasts. Indeed, once state vector
covariances grow to 0.05 AUs or more, predictions as to collisions/near-misses
are of dubious value. Ultra-precise radar observations can mitigate this
problem somewhat. Nevertheless, for recently-discovered minor planets with
relatively large state vector covariances, users may want to limit the search
for collisions/near-misses to relatively short timeframes, until additional
observations help refine the trajectory and make distant forecasts more
meaningful.
Note: Linear collision analysis does not require the prior
processing of all available observations; in fact, so long as the user has entered a state vector or set
of orbital elements (plus covariances), linear collision analysis can be
performed.
In the nonlinear
method, CODES creates a user-specified number of variant state vectors;
depending on user selection, these variant state vectors are either distributed
normally (in observation space) about the nominal epoch state vector, or
distributed uniformly along the Line-of-Variations (roughly corresponding to
the major axis of the epoch state vector uncertainty ellipse). Each of these
variant state vectors is propogated forward from the current epoch to the
desired endpoint, and its collisions and/or near-misses are noted precisely as
in the first method. These events are compiled and sorted into
dynamically-distinct trails by target body, date, semi-major axis, and miss
distance. If a reversal is noted (in
which successive VAs march toward a target, then reverse direction and begin to
recede), a Monte Carlo sampling is performed around the point of reversal to
ensure that the point of closest approach (or point of collision) has been
determined. Otherwise, differential
correction is applied to the nearest VA of each trail to iteratively reduce the
miss distance; if the variant state vector can be adjusted (within 5 sigma of
the nominal state vector) so as to cause a collision, it is termed a Virtual
Impactor (VI), and linear techniques are used to estimate the probability of
collision. Even when the differential correction process does not force a
collision, we will very often identify near-miss encounters unique to the
particular variant trajectories. In short, by thoroughly sampling the
uncertainty region surrounding the nominal epoch state vector, the user can
increase the degree of confidence that all statistically-significant
collision/near-miss events have been identified.
Important:
Whether the variant state vectors are distributed normally or along the Line of
Variations, least squares techniques are employed to ensure that the resulting
variant state vector has the smallest possible residual. As a result, it is vitally important that the user input all
available optical and radar observations prior to attempting nonlinear collision analysis. Simply specifying
a nominal state vector is not sufficient; CODES must have processed
and stored the actual observations before nonlinear collision analysis is
possible. Ideally, the user will have
also used CODES to calculate the initial and best-fit
state vectors; since the observations are then consistent with the nominal
state vector, the least-squares-driven collision analysis algorithm should be
quite stable.
Important: The use of multiple variant state vectors and
iterative differential correction results in a great deal of numerical
integration; as a result, the user should be aware that this method requires
significant processing capacity. Since the variety of user platforms makes
it difficult to offer universal guidance, I would suggest that users run a
benchmark test using 5 variant state vectors over a 25 year timeframe; knowing
the time required to process this small survey, users should then be able to
judge the realistic number of variant state vectors that their platform can
support over the full range of survey timeframes.
The decision as to
which method to select is sometimes not immediately obvious. For a
newly-discovered minor planet with large covariances in the epoch state vector,
the variant trajectories can cover much of the inner solar system; predictions
based on such uncertain data are thus of dubious value. Once a sufficiently
large arc of the orbit has been observed, or if radar observations are
obtained, the state vector covariances can become quite small; and although
there are theoretically still an infinite number of "virtual
trajectories" which the asteroid could follow, they are so similar to the
nominal trajectory that there seems little point in following them. However, a
particularly close planetary encounter can "disperse" the variant
trajectories; subsequent events can then become chaotic and dependent on the
exact path taken, making studies of the variant trajectories again
worthwhile. When in doubt, I'd suggest selecting the linear method, and
using the covariances at the time of each nominal event as a guide. If
the covariances grow large (especially in comparison to the miss distances),
consideration of variant trajectories is likely worthwhile; if the covariances
stay small, the "virtual trajectories" are still tightly bound to the
nominal trajectory, and there's little benefit to be gained from considering
them.
The processing
demands can be somewhat mitigated by reducing the integration accuracy. "High" accuracy ensures that the
local error in the final position will not exceed 0.9 km; however, in
determining whether a collision has occurred with a planet 6378 km in radius,
this level of accuracy is not always necessary.
"Medium" accuracy ensures that the local error in the final
position will not exceed 0.1 Earth radius; this option can reduce processing
time by a factor of 5 (or more) over a 50-year search period, and should
capture most of the same events as the "high" option (though with
less precision). My recommendation would
be to search initially with the "medium" option; if any Virtual Impactors
or particularly close near-misses are observed, the search can be repeated at
"high" accuracy using the VI's state vector.
Very Important: An exception to this recommendation would be the case of a NEO such
as 2000 SG344, which has multiple successive near-miss encounters over the next
100 years. Unless the cumulative
perturbations of these encounters are accurately modeled with high integration
accuracy, predictions are of dubious value.
I
have spent a great deal of time testing the non-linear collision analysis
algorithms, and I believe CODES' predictions are now comparable to those of
Sentry or NEODyS. Note that I said "comparable". There
are at least four reasons why our predictions could differ:
-
The systems may begin with slightly different state vectors;
- CODES collision analysis occurs in 3-dimensional
space, while Sentry and NEODyS collision analysis is performed in the impact
plane;
- The differential correction scheme employed by CODES
differs from that outlined by Andrea Milani in his series of papers on Virtual
Impactors.
- CODES
assumes that the uncertainties in optical ra/decs are approximately 1.0 arc
seconds, while Sentry often uses smaller values; as a result, the width of the
event covariance regions and the impact probabilities may differ by as
much as a factor of 10.
Far from rationalizing these differences, I believe it
is extremely useful to independently check the predictions made by each system.
In evaluating high-risk asteroids, I would suggest the
following settings:
- For
Line-of-Variations analyses
Nonlinear Collision analysis - Consider 1201 variant
trajectories
Sample Line-of-Variation
Set near-miss threshold 0.05 AUs
High integration accuracy
- For Monte
Carlo analyses:
Nonlinear Collision analysis - Consider 1201 variant
trajectories
Sample normal distribution
Set near-miss threshold 0.05 AUs
High integration accuracy
Because
of processing time limitations, I would suggest that the timeframe generally
not exceed 100 years. As more distant future events are greatly affected
by even very small changes in the epoch state vector, I would suggest that only
asteroids observed by radar (and thus with very small state vector covariances)
should be considered for analyses beyond 2100.
When calculations
are complete, CODES displays the predicted collision/near-miss events in
tabular form, with UTC date, nominal and minimum distance of closest approach,
3-sigma width of the event covariance ellipse, probability of collision, and
the largest multiple of sigma for the components of the (variant) state vector.
A file version of the output is created at "[minor planet]_collision_output.txt" in the "codes"
folder; this file also provides the coordinates of each VI epoch state vector
and the sigma for each VI component.
Note: CODES supports observations and predictions for the
range 1900-2200.
The user may click
"Done" to return to the Level Two Menu.
This option allows
the user to specify the number of perturbing bodies to be used in integrated
n-body mechanics. Since integration is used extensively in
CODES (e.g. determination
of best-fit orbit, checking
for collisions/near-misses), this selection should be made
prior to attempting any operation.
In most cases
(e.g., orbit determination using optical observations, especially over only a
short time arc), the (default) second selection is acceptable. This provides
high-accuracy perturbations due to the Sun, nine planets, Earth’s Moon,
and the three largest asteroids (Ceres, Pallas, and Vesta).
If very high
accuracy is required (e.g., careful analysis of a possible planetary impact,
availability of optical observations over a long time arc, or availability of
radar observations), I would recommend using the third selection (all asteroids
with reliable mass estimates). Note that this will greatly increase the number
of calculations per integration step, so expect much slower
processing with this setting.
Experience has
shown that, when analyzing the multiple close encounters (i.e. near-misses and
collisions) of a minor planet with major solar system bodies, the accuracy of
predicted events depends more on the accuracy of the epoch state vector than on
the ultra-precise modeling of the later perturbations. Thus, in high-accuracy
cases, I would emphasize using the third selection (all asteroids with reliable
mass estimates) in the determination of the minor planet's best-fit orbit.
Note: The positions and velocities of the Sun, nine
planets, and Earth's Moon are calculated using the JPL DE405 ephemeris.
The radius, visual
absolute magnitude, and slope parameter are used by CODES in several
operations, such as creating an ephemeris or processing radar observations.
When the best-fit
orbit of the subject minor planet is
calculated, CODES uses visual apparent magnitude data (if available) to
estimate (using different algorithms, depending on whether the object is a
comet or asteroid) the visual absolute magnitude and slope parameter. For
asteroids, the slope parameter is used to estimate the albedo, itself resulting
in an order-of-magnitude estimate of the radius.
However, if the
user has instead imported
or manually entered the last-saved state vector/orbital
elements, then the radius, visual
absolute magnitude and slope parameter are unknown. This option can thus be
used to specify these parameters. Additionally, if a best-fit
orbit has already been calculated,
the user can specify only the slope parameter, and ask CODES to calculate the
resulting visual absolute magnitude and (for asteroids only) radius; since
different algorithms are used for comets and asteroids, however, it is very
important that the user designate
the subject minor planet as a comet or asteroid before attempting this calculation.
The default radius
is 1 km. However, using this value for a large comet, for instance, could
seriously degrade the results of radar calculations. For comets, use the best
available estimate of the radius of the coma (from which radar signals can be
expected to deflect).
When the correct
values have been entered into the data fields, simply click "Set".
CODES will save the data to disk, and return to the Level Two Menu.