Horizons System
Introduction
Version 4.94 (September 6, 2022)
Purpose and Scope
The JPL Horizons on-line ephemeris system provides access to solar system data and customizable production of accurate ephemerides for observers, mission-planners, researchers, and the public, by numerically characterizing the location, motion, and observability of solar system objects as a function of time, as seen from locations within the solar system.
Available objects include 1,229,000+ asteroids, 3822 comets, 211 natural satellites, all planets, the Sun, 202 spacecraft, and several dynamical points such as Earth-Sun L1, L2, L4, L5, Earth-Moon L1, L2, L4, L5 and planetary system barycenters. Ephemerides, lighting, and visibility for points on the surface of distant bodies may also be generated.
Aberrated sky location angles and angular rates can be characterized using right-ascension and declination in three coordinate systems, along with azimuth and elevation, sky-motion rates, and position angle, as a function of time and observer location. For comets and asteroids, corresponding statistical uncertainties and plane-of-sky error ellipse parameters can be generated as a function of time.
Target visibility in the sky can be assessed with magnitude, extinction, airmass, and visual signal-to-noise ratio (SNR) relative to background sky brightening caused by atmosphere-scattered moonlight, with Sun and Moon sky-presence and twilight-dawn indicators.
Target-body rise, maximum elevation, transit, and set may be identified along with eclipse circumstances for non-Earth natural satellites.
Sub-observer and sub-solar cartographic latitude and longitude can be returned for targets (or sites on targets) having defined rotational models.
Close-approaches by asteroids and comets to planetary bodies (and sixteen of the largest asteroids) can be rapidly and automatically identified, along with their encounter uncertainties and impact probabilities.
Tables of vectors or osculating orbital elements of one body with respect to another can be produced to characterize relative motion and orbit geometry as a function of time.
SPK binary file output can be plugged into user programs to reproduce the numerically integrated time-continuous state of small-body targets at any instant for remote usage. The SPK files can be used by existing visualization, animation and mission-design software that incorporate appropriate SPICE Toolkit readers.
In total, more than 100 different observational and physical aspect quantities can be requested at intervals for both topocentric and geocentric situations in one of 9 coordinate systems and 4 time scales (TDB, TT, UT, Civil).
Users may conduct parameter searches of the comet/asteroid database, searching for objects based on combinations of up to 42 different parameters, or define their own objects by specifying heliocentric IAU76/80 osculating elements, then use the system to accurately integrate the trajectory. Geocentric SGP4/SDP4 Two-Line Element (TLE) format data can also be specified and propagated by users to define an Earth-orbiting artificial satellite.
Over 2300 predefined Earth station locations are available, along with sites on other major bodies, in addition to being able to use spacecraft as “observing sites” from which to generate relative ephemerides. Users may define their own topocentric observing site coordinates on any planet or natural satellite having a known rotational model, if the desired site is not predefined.
The underlying solar system data from which output is derived is kept current to reflect the latest measurements, models, and solutions. It is typically the same data used at JPL for radar astronomy, mission planning, and spacecraft navigation.
Results are suitable for tracking systems, observers, mission planners, and other researchers, although such determination is ultimately the users’ responsibility.
The information is grouped into five general types of customizable output requests:
- Observables (plane-of-sky angles, rates, visibility, physical aspect)
- Osculating orbital elements
- Cartesian state vectors
- Close approaches to planets and 16 largest asteroids
- SPK binary trajectory files (asteroids and comets only)
The first four are ASCII tables containing output at user-specified discrete time-steps. SPK requests return time-continuous binary files. Output is returned to the user via screen display, API query, e-mail, or FTP protocols. Table types 1-3 can be requested in a format suitable for spreadsheet import.
Overview of Usage
There are four supported ways to access the program. All can be automated:
- Browser (passive interactive GUI interface):
- Point your browser to https://ssd.jpl.nasa.gov/horizons/app.html
- API (GET and POST programmatic interface)
- See documentation at https://ssd-api.jpl.nasa.gov/doc/horizons.html
- Command-line (full access, active interactive prompt-based interface):
- Connect keyboard directly to the system
telnet ssd.jpl.nasa.gov 6775.
No account or password is required. - Specify an object to get a summary data screen.
- Follow prompts. At any prompt, type
?or?!for short or long explanations of the prompt. - Transmit results to your system by e-mail or FTP
- Connect keyboard directly to the system
- E-mail (full access, except for SPK file production, batch interface):
- Send e-mail to
horizons@ssd.jpl.nasa.govwith subject “BATCH-LONG”. - An example command file will be mailed back to you.
- Edit this text file, then mail it back with the subject header “
JOB” - Results of your request are mailed back to you.
- Send e-mail to
The Horizons system was intended to be easy to use and should have a step-function learning curve. The main requirement to get started is understanding how connect to the system and then select “target” objects.
The remainder of this documentation summarizes details of system capabilities and interpretation of the output. Check the end of each ephemeris generated for a specific explanation of what was returned.
This document often describes “typing” certain things, presupposing the interactive command-line interface is being used. If one is instead using the browser interface, these operations are typically done by using a pull down menu or check-box. The e-mail and API interfaces typically involve setting an appropriate command-file variable to accomplish the same thing.
While using the command-line interface, type “?” or “?!” at any prompt for an explanation of options. Type ‘-‘ at any prompt to move backward to the previous prompt. ‘x’ exits the system immediately.
See the Acknowledgements section for contact information.
To be actively alerted to major changes such as new capabilities and operational changes, subscribe to the announcements list. It is generally low-traffic and has historically been used once or twice a year:
https://ssd.jpl.nasa.gov/email_list.html
A more frequently updated ‘system news’ is also available by typing “news” within the command-line interface, or from the URL below. ‘News’ reports all significant changes, not just major changes, and can include supplementary information on system usage, but you have to actively check it:
https://ssd.jpl.nasa.gov/horizons/news.html
Connecting to the System
Command-line
The Horizons on-line ephemeris and data system is available as a command-line terminal service. This is intended for people who want quick access to all program features with an interactive keyboard-type interface. User response to a series of guided-prompts sets up the desired output.
From a telnet-capable machine, running a “VT100”-type terminal model,
connect to “ssd.jpl.nasa.gov 6775”:
-
From UNIX/LINUX/MacOSX command line:
telnet ssd.jpl.nasa.gov 6775… where
6775is a required port number. -
Alternatively, from within a web-browser that supports telnet, enter a URL of this form:
telnet://ssd.jpl.nasa.gov:6775However, few modern browsers may recognize this form without additional configuration by the user.
The system will start a terminal session automatically. No user-ID or password is required. If the connection is refused, the two most likely causes are:
- The port number was not specified or passed along by software:
- A few PC-type telnet programs do not to fully implement the telnet protocol and may not pass the port number to the network, or may need to be reconfigured to function properly, or may have a different syntax for specifying port numbers. Check your users’ guide for information.
- There is a firewall security restriction at your end
- Contact your local computer system administrator in this case. Since no password or security information is exchanged, you may be able to request a firewall exception from your institution (“poke a hole”).
The command-line interface can be automated. However, this is no longer recommended given the APIs introduced in 2021. Deprecated example scripts may be found in the FTP directory <fhttps://ssd.jpl.nasa.gov/ftp/xfr/SCRIPTS/> and will be supported indefinately.
Command-line capability can be restored to recent MacOS systems if necessary using these two commands from within a Mac terminal window connected to the Internet:
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install inetutils
This installs ‘telnet’ and ‘ftp’ commands used for Mac terminal connections. However, file retrieval can be done without FTP using the already-available ‘curl’ terminal command:. For example,
curl -s "https://ssd.jpl.nasa.gov/ftp/ssd/SCRIPTS/README"
Web
Point your browser to: https://ssd.jpl.nasa.gov/horizons/app.html
This graphical interface is intended for the more casual user or general public but offers access to program features using pull-down menus, fill-in boxes and clickable buttons.
Users should verify default settings such as timescale, coordinate system, and desired output quantities are appropriate and as intended for the run.
API
An API designed for direct programmatic access and automation (“machine-to-machine”) is available. Query parameters are specified either on a URL (GET), or in a file provided to the API when it is called (POST).
Documentation specific to the API interface is here:
GET (URL encoded requests):
https://ssd-api.jpl.nasa.gov/doc/horizons.html
POST (file-based requests) :
https://ssd-api.jpl.nasa.gov/doc/horizons_file.html
Horizons can also be controlled by sending e-mail messages to the address
horizons@ssd.jpl.nasa.gov
System action is determined by the e-mail “subject” set by the user.
The e-mail “programming-like” interface is generally for those who want access to most program features without the overhead of answering prompts or manipulating graphical interfaces; generally those already familiar with what the program does and who know what they want, and who might have local firewall problems with other interfaces.
You might set up an input file that does what you want once, and then make only minor changes to it thereafter, such as specifying a different object for a new run.
An example usage-case for the e-mail interface might be generation of rise-transit-set times for an object over decades. The request (or series of requests) can be submitted by email. Results will be returned when complete without the user having to be present, keep a connection open, or monitor a potentially lengthy process; a “fire and forget” mode of operation.
It offers the additional ability of allowing users to specify up to 10000 discrete times (to aid astrometric reduction) and up to 200 objects at once, although results are returned as a separate e-mail for each object. The e-mail interface does not currently allow the SPK file production available using the command-line interface or API.
IMPORTANT: Please be sure your email client is sending content as plain ASCII text. Not doing so may result in no response from the system or an error message, even when your command-file appears perfectly normal from within your email client.
E-mail requests to Horizons may be most practical for those working in a UNIX/Linux/MacOS terminal or command-line environment, with plain-text programming-type editors available such as vi, emacs, atom, sublime, and with mailers like mailx, or similar.
Modern graphical e-mail systems (gmail, Outlook, etc.) often assume they are communicating with other e-mail systems like themselves and insert hidden font and formatting codes that Horizons cannot currently interpret. There can also be issues with 8-bit character sets, such as generated by keyboards set up for use with non-US languages.
A helpful (if dated) guide to suitably configuring some email clients for plain-text is available via this link:
https://ssd.jpl.nasa.gov/dat/Configuring_Mail_Clients_to_Send_Plain_ASCII_Text.pdf
… but, in general, consult your mailer’s documentation on how to activate any plain-text mode that might be available.
To get started with the e-mail interface, send e-mail to the above address with the subject “BATCH-LONG”. The latest, fully-commented example command-file will be mailed back. Edit this file to produce the results you want, then mail back with the subject “JOB”.
Note that the e-mail command file that is returned returned defines the identical settings used by the API interface, so is relevant there also.
Recognized e-mail commands in the “Subject:” line are:
SUBJECT HEADER MEANING -------------- ----------------------------------------------------------- JOB Horizons run-stream DOC-TEXT Request ASCII (plain-text) version of current documentation DOC-PS Request PostScript version of current documentation BATCH-LONG Request latest fully commented example batch file BATCH-BRIEF Request latest example batch file without comments QUESTION Message forwarded to cognizant engineer
Those automating e-mail interactions with Horizons should take a prudent approach for best results. For example, space requests at 1-2 seconds before sending the next. This reduces the chance of requests getting categorized as spam and diverted at some point along the route, which can happen if a script tries to send 1000 e-mail requests in 0.1 seconds.
Incoming e-mail requests are queued and processed in the order received, one at a time. Results will typically be returned within a few seconds, depending on the request, but can also be delayed minutes or even longer if there are a number of requests to process ahead of yours, or if the specific request is a time-consuming by nature, or the receiving mail agent only checks for incoming at some preset interval.
Separate tools (for example, ‘procmail’) can be used automatically extract Horizons output from incoming e-mail and deposit in a local file.
General Definitions
The remainder of this document will use some terms and abbreviations defined below:
Reference Frame
The set of three axes at right angles to each other that define the cartesian (x, y, z) basis directions. The x and y axes define a reference plane from which declination or latitude is measured. The z-direction is at right angles to that x-y plane and defines the “pole”. The x-direction defines the origin from which right ascension or longitude is measured.
Horizons may use – depending on circumstance and sometimes user-request – the following reference frames:
- ICRF (International Celestial Reference Frame, equatorial-aligned radio frame)
- Earth true-of-date (IAU76/80)
- Earth ecliptic of-date (IAU76/80)
- Earth ecliptic at J2000 epoch (IAU76/80)
- IAU body-frame of-date (equatorial)
- Lunar mean Earth (DE421)
- FK4/B1950 (equatorial)
- Earth ecliptic at B1950 epoch
Ecliptic
In this reference frame, the x-y plane is based on the orbit of the Earth around the Sun. Since the Earth’s orbit plane fluctuates slightly due to gravitational perturbations, the ecliptic chosen can be at a fixed standard time (such as the J2000.0 epoch 2000-Jan-1.5) providing an inertial frame, or instead the time of interest (“of-date”), providing a dynamic frame, depending on the purpose. Both amount to adopting a standard due to definitional ambiguities caused by the Earth and Moon’s mutual motion affecting the Earth’s orbit plane.
When transforming between the underlying ICRF reference frame, Horizons uses the IAU76/80 fixed obliquity of 84381.448 arcsec at the J2000.0 standard epoch, and an associated time-varying model for “of-date” ecliptic.
When transforming between FK4/B1950, a fixed obliquity of 84404.8362512 arcseconds is used at the standard epoch, with an associated time-varying model for other instants.
North
For planets and natural satellites, the spin-pole direction extending to the positive side of the plane defined by the solar systems’ positive angular momentum vector.a For asteroids and comets, north is along the body’s spin-axis positive angular momentum direction
East
The counter-clockwise direction around the north-pole of rotation.
RA
Right ascension; the angular distance on the celestial sphere counter-clockwise (eastward) along the celestial equator from the reference equinox to the meridian of the object. RA is analogous to longitude, with the plane containing the equinox defining zero RA much as the Greenwich meridian defines zero longitude. There are different types of RA, described below, depending on what coordinate system and aberrations are requested. Values are expressed in sexagesimal time units of hours, minutes, and seconds OR decimal angular degrees, as requested.
DEC
Declination; the angular distance on the celestial sphere north (positive) or south (negative) of the reference frame equator. It is analogous to latitude. As with RA, there are different types of DEC, described below, depending on what coordinate system and aberrations are requested. Usually expressed in decimal angular degrees.
AZ
Azimuth; the angle measured clockwise from the north along the horizon defined by the plane perpendicular to the local zenith to the point where the meridian passing through local zenith and the object intersects the horizon plane.
EL
Elevation; the angular distance above or below the plane perpendicular to the local zenith. Note this plane is not necessarily the visible horizon, due to station elevation – the “horizon dip” effect.
Geometric Coordinates
The instantaneous (“true”) position of a body at a particular instant. These coordinates are referred to the x-y basis of a particular reference frame (ICRF or FK4/B1950 or their standard ecliptic variations) and primarily of interest to those doing dynamical modeling.
Astrometric Coordinates
Positions or values (such as RA and DEC) which account for the finite but varying amount of time it takes light to travel from the target to the observer, expressed with respect to the x-y basis definitions of a particular inertial reference frame, such as ICRF or FK4/B1950.
When an object is at some position, an observer far away will still see it at a prior position that depends on how far away the observer is, due to the finite speed of light
Astrometric coordinates are generally used when comparing positions to nearby stars in a star catalog. Nearby catalog stars experience essentially the same aberrational position shift due to observer motion such that stellar aberration is not considered when comparing to nearby stars.
Apparent Coordinates
Positions or values (like RA and DEC) which take into account factors that appear to change the target position with respect to the background coordinate system: light-time, the deflection of light due to large or nearby masses, and stellar aberration.
Apparent coordinates can be with respect to an inertial frame such as ICRF or FK4/B1950, such as for space-based observers (spacecraft) or, for observers on a rotating surface, with respect to some “of-date” coordinate system, involving precession-nutation to the Earth’s true-equator and equinox-of-date (or that of a non-Earth body associated with the observer location).
Apparent positions are usually of interest to telescope systems on the surface of rotating body that are aligned with the pole at each instant and carried along as that pole precesses and nutates.
For space-based systems not linked to a rotating surface, the ICRF or FK4/B1950 inertial reference frame is used, and the aberrations that change apparent positions relative to that background reference frame are included.
Refracted Coordinates
Apparent coordinates can additionally be corrected for atmospheric refraction. Available only for Earth-based sites, this ultimately is a function of the local atmosphere and weather between target and observer, which can only be approximately known. Some observatories have developed their own local refraction tables.
Small Body
Refers to a comet or asteroid for which the trajectory is numerically integrated on demand from an initial set of previously statistically estimated orbital elements in the JPL database. Typically, no cartographic coordinate system is available for these objects, but there are a growing number of exceptions.
Major Body
Refers to planet, natural satellite, spacecraft, Sun, barycenter, or other objects having pre-computed trajectories.
Only major bodies can be coordinate centers (observing sites) in Horizons. Their state vectors are obtained by interpolating previously defined ephemerides, such as DE441. Interpolation generally recovers the state to the millimeter level.
In some special cases, an asteroid or comet can be defined as a major body. An example might be a particular asteroid solution used for a spacecraft mission flyby or other historically “fixed” purpose, such as the Eros solution for the NEAR mission.
In such cases, the particular trajectory is precomputed and stored as a “major body”, while the objects’ ground-based solution otherwise continues to be updated in the JPL small-body database as new observations are reported. Therefore, it may be possible to use either the fixed (historical) major-body trajectory solution or the “latest” small-body solution. Details for the specific cases are given in the object’s data-sheet summaries.
Target Body
Refers to the object of interest for which an ephemeris is to be created. Selected by the user. It can be a major-body or small-body.
Center (or coordinate origin, or observering location)
This is the point to which output quantities for the target (such as coordinates) are referred: (0,0,0). It is typically where the observer is located.
An observation point is “topocentric” if on the surface of a body with a known rotational state.
If at the center of a physical body, the observing point is “bodycentric” (with “geocentric” referring to the particular case of origin at the Earth’s center).
If at the center-of-mass of some dynamical system, the center or observer is “barycentric”.
Primary Body
Refers to closest body about which a target body orbits. For natural satellites, this would be a planet, although they orbit the Sun as well. For planets and small-bodies, the primary body is the Sun.
Interfering Body
Refers to the largest body in a system other than the one the observer is on, or the target.
For example, for an observer on the Earth, the “interfering body” is the Moon. If the observer is on the Moon, the interfering body is the Earth.
The location of the interfering body can be of interest because it can affect local sky brightness due to its reflectivity and closeness in the sky to the target.
Deflecting Body
Refers to the largest mass in the observers’ system; it can be used to estimate the gravitational bending (deflection) of light, in addition to that of the Sun. This can change the apparent position of an object slightly with respect to the background coordinate system.
Object Selection
When connecting by command-line, the primary thing one must know to use Horizons effectively is how to select objects. Once the user gets things started by selecting an object, everything else is prompted.
Selecting an object can amount to just typing in its name or designation or IAU number and pressing return, but it is helpful to understand a few more things to avoid confusion in some situations.
There are two categories of objects in Horizons:
-
Major Bodies (planets, natural satellites, spacecraft, special cases):
Major bodies are represented in pre-computed trajectory files which are interpolated to very accurately retrieve position and velocity at any instant.
-
Small Bodies (comets and asteroids):
Small-bodies have their statistically estimated position and velocity at one instant compactly stored in a database as initial conditions and are then numerically integrated on-demand by Horizons, to other times of interest, using the necessary physics.
These two categories partly result from the objects being stored differently and partly from the historical overlap in the numbering and naming of bodies.
For example, since there is a natural satellite named Io as well as an asteroid named Io, there has to be some way to distinguish between them and it might as well be possible to do that immediately when formulating the look-up instead of always getting a list back asking “which one?”
When an object is specified, the request is first examined for optional “keywords” or a semicolon symbol that tells the system more about what is wanted.
If there aren’t any keywords, the system will then try to match against the major body list. If a match is found among the list of major bodies, it will be displayed. If no match is found among the major bodies, it will then continue on and match against the small-body database.
For example, if you simply input “Io”, it will return a list of matches from among the major bodies, including the moon of Jupiter, and then stop, waiting for the user to clarify by uniquely specifying one object. To uniquely specify Io, enter its unique ID number, “501” (which was displayed on the previous list of multiple matches).
To instead select the small-body named Io immediately, provide more information by specifying it one of these ways:
-
Horizons> Io;(Semi-colon tells Horizons its a small-body look-up) -
Horizons> 85(No match on major body, so search “falls through” to small-body number look-up) -
Horizons> 85;(Semi-colon tells Horizons its a small-body look-up) -
Horizons> NAME= Io;(Keyword “NAME” tells Horizons its an asteroid or comet small-body look-up) -
Horizons> ASTNAM= Io;(Keyword “ASTNAM” tells Horizons its an asteroid name)
Further details, discussion, and examples follow.
Major Bodies
Type MB to get a list of all major-body strings that can be used to search
on. To select a major body, enter one of the following:
- A string to search on (
MarsorTrit). Case insensitive. - A JPL ID integer code or fragment
- An IAU number
Examples (at the main prompt):
Horizons> mars bary(uniquely select Mars barycenter; ‘4’ does the same)Horizons> mars(list all major bodies with ‘mars’ in an ID field)Horizons> 501(uniquely select Io)Horizons> N*(list all major bodies with ‘n’ in an ID field)
Once a major-body is uniquely identified, a screen of data will be displayed for confirmation purposes. This display generally consists of various measured parameters for the body, drawn from published literature and displayed for informational purposes.
Note that there is often more than one determination in the literature for many of the displayed parameters, and that they are subject to revision as more data are accumulated.
Such display values in major-body data sheets are NOT used in the subsequent ephemeris calculations. This differs from the small-body confirmation data screens, which are extracted from a JPL database and ARE what is used to initialize a Horizons small-body integration.
Planetary systems may have two associated integer ID numbers assigned. Those greater than 100 and ending in 99 (199, 299, 399, 499, 599, 699, 799, 899, 999) refer to the planet CENTER only.
To instead select planetary (system) BARYCENTERS, use the numeric ID codes less than 10 and greater than or equal to 0: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. This selects the center-of-mass the objects in the planetary system move with respect to, including the planet itself and its natural satellites.
For example, 399 is the Earth’s center, 3 is the Earth-Moon Barycenter
point about which the Earth and Moon both move, and 301 is the center of the
Moon.
For Mercury and Venus, there is no difference between planet-center and
system barycenter (1=199, 2=299) as far as Horizons selection is
concerned because there is only the planet: no satellites, so no offset
between planet center and planetary system center-of-mass.
-
0andssbrefer to the solar system barycenter (SSB). -
10andsunrefer to the center of the Sun.
If a planet name is entered, it may not be considered unique if a distinct
system barycenter is available. For example, if Saturn is entered, a list
containing “Saturn” and the “Saturn Barycenter” will be returned. To specify
Saturn (the planet-center), you must use its unique ID code, 699.
A unique ID code will be displayed whenever there are multiple matches, to help users select between objects and unambiguously specify the desired object. If you can remember the unique ID codes, it is always best to specify them instead of a name immediately followed by having to enter the code anyway to resolve the name ambiguity.
System barycenters are available over longer time-spans than planet-centers because planet-centers are defined by satellite solutions. These satellite solutions are based on shorter data arcs than the entire system and can therefore be extrapolated only over shorter time-spans.
For example, the planet Jupiter 599 might be available over the interval
1600-2500, while the Jupiter system barycenter 5 is available over 9999 B.C.
to A.D. 9999.
Note that if youintend to generate an osculating orbital element ephemeris, you may want to specify barycenters to avoid having high frequency local system orbital motion aliased into the results.
For example, if you request orbital elements of the Earth (399) with respect
to Sun (10), the resulting elements will contain short-period oscillations due
to the Earth’s motion with respect to the Earth-Moon barycenter, as well as the
Sun’s motion with respect to the solar system barycenter. Unless these short
period motions are desired, you might want to instead request 3 with respect
to 0 (Earth-Moon barycenter with respect to solar system barycenter).
Surface Targets:
Horizons can also compute ephemerides for targets that are on the surface of extended, rotating target bodies (generally, “major bodies”): Moon, Sun, planets, natural satellites, or other bodies with a defined rotational model.
Example targets might be specific craters, topographic features, or spacecraft landing sites.
To specify a target on the surface of a major body that has a defined shape and rotation model, the most general form of input allows two types of coordinates, both in units of degrees and km:
-
Geodetic/planetodetic coordinates:
{g: E.Long, latitude, h @ } BODY -
Cylindrical coordinates:
{c: E.Long, DXY, DZ @ } BODY
… where the brackets {} indicate optional components of the general specification.
For example, while 301 specifies the target to be the center of the
Moon, and Apollo-11 @ 301 specifies the Apollo-11 landing site as target,
the following …
g: 348.8, -43.3, 0 @ 301
… specifies an ephemeris for the crater Tycho on the Moon (body 301), at geodetic (planetodetic) coordinates 348.8 degrees east longitude, -43.3 degrees latitude (south), and zero km altitude with respect to the Moon’s mean-Earth reference frame and ellipsoid surface.
To input cylindrical coordinates using the “c:” prefix. DXY is distance from the spin axis in the body equator plane in km. DZ is distance above (+) or below (-) that plane, also in km.
When a surface target is specified, two new markers are placed in observer table output. They indicate if the target point on the surface is lit by the Sun and if it is on the near or far-side of the target body relative to the observer.
Altered descriptions are printed at the end of the output ephemeris tables as warranted to describe the output.
Small Bodies
To select an asteroid or comet, enter one or more parameters to search on, separated by a semi-colon, “;”.
Type SB for a list of 42 field keywords that can be used to search, or see
the list later in this document. Match symbols are from the set
{ >, <, <>, = }.
The most direct and unambiguous way to look up a small-body is to specify its unique designation (and use a keyword to be sure). For example:
DES= 1990 MU;DES= 2015 HM10;
The keyword can typically be dropped and the designation alone entered, along with a semi-colon:
1990 MU;2015 HM10;
… however, if the desired or unique response is not obtained, try the full keyword specification using “DES=”. If the small-body has a permanent IAU ID number, that can also be used for direct look-up without a keyword:
1;(retrieves “1 Ceres”)433;(retrieves “433 Eros”)4179;(retrieves “4179 Toutatis”)
Designation is only one of the small-body look-up keywords available, as indicated by the ‘SB’ list mentioned above and discussed in more detail later in this document.
For example, “A < 2.5; IN > 7.8; STYP = S, GM <> 0; “ searches for all S-type small-bodies with semi-major axis less than 2.5 au and inclination greater than 7.8 degrees with a known (non-zero) GM.
Spaces in the look-up command are not considered, nor are upper/lower-case distinctions. Exceptions are object names and designations. Name searches consider spaces. Designation searches consider spaces AND upper/lower-case.
If you want to match a fragment of a name or designation, end it with an asterisk (*). For example, DES = 1993*). Otherwise, it is assumed a complete name or designation is specified and the search must match exactly and completely.
The ‘*’ symbol is NOT a positional wildcard match but only a switch that activates matching on the preceding sub-string. Horizons searches do not support UNIX regular expressions or pattern matching syntax.
For example:
NAME = CERES;(matches only if object name is “Ceres”)NAME = CER*;(match “Ceres”, “Lucerna”, “Cicero”, etc.)
The same keyword can be used more than once in a search command.
For example, IN >10; IN < 20; will list those objects possessing an
inclination between 10 and 20 degrees. If the directive LIST; is in the search
request, the matched parameters will be displayed. For example, IN > 150; LIST
will display the inclination of each object with inclination greater than 150
degrees.
Once a small-body is uniquely identified, a screen of data will be displayed. This data display shows the parameters retrieved from the JPL small-body database and are what will be used in subsequent ephemeris calculations (unlike the situation with major bodies, whose confirmation screen values are drawn from published literature for information purposes only and generally will not be used in subsequent calculations).
If more than one small-body matches the parameters, a list of matching objects is instead displayed. Individual objects from the matched list can then be requested by giving the displayed “record number”, followed by a semi-colon. This record number is not necessarily permanent and is valid only for the immediately prior search.
The semi-colon is used to indicate a small-body request and resolve number ambiguities. For example, entering ‘1’ will select Mercury Barycenter. Enter ‘1;’ to retrieve the small-body in record 1 (Ceres).
Osculating elements for more than one comet apparition may be listed (“apparition” refers to a particular perihelion passage), since out-gassing near perihelion can alter the orbit for each passage. Select an apparition from the list with the closest epoch prior to the date of interest for the ephemeris, or add the “CAP” directive to the search to automatically select the closest apparition of interest:
CAP;(return last apparition before current date)CAP < JD#;(return last apparition before specified Julian Day Number)CAP < YEAR;(return last apparition before given integer year)
If the number after a < in a CAP; specification is less than 10000, it is
interpreted as a year integer. Otherwise, the number is taken to be a Julian
Day Number. If CAP; is specified, the search is automatically recognized as
being a comets-only search.
The record (or file) number of unnumbered asteroids and comet apparitions should NOT be considered constants; they WILL change as the database is updated.
To enter your own heliocentric ecliptic elements, type ; within the
command-line interface. This capability is described in more detail in a later
section. Web-interface, API, and e-mail interfaces have settings or menus
to specify user-input objects.
Example queries follow. Where more than one example is given, the first is most likely to complete as intended.
For example, ASTNAM = Vesta; will always return the asteroid. However, if you
use the convenient form Vesta, which is allowed, it is possible that a future
natural satellite or spacecraft name will someday include that string and there
will no longer be a unique match. A good habit might be to include at least one
semi-colon in all small-body searches so as to be unambiguous.
Search for objects matching a set of parameters:
Horizons> A < 2.5; IN > 7.8; STYP = S; GM <> 0;(asteroid & comets)Horizons> A < 2.5; IN > 7.8; STYP = S; GM <> 0; AST;(asteroids only)Horizons> A < 2.5; IN > 7.8; STYP = S; GM <> 0; COM;(comets only)
Match by name:
Horizons> ASTNAM= Vesta;Horizons> Vesta;Horizons> Vesta
Match by name fragment:
Horizons> NAME= mua*;(Objects with names containing ‘mua’)Horizons> mua*;
“Wildcard” match designation:
Horizons> DES = 1993*;(Objects with designations containing 1993)Horizons> 1993*;Horizons> 1993*
NOTE: The
*must be at the end and is NOT a true positional wildcard. It instead toggles searches on sub-strings of characters. For example,19*3;is not a recognized search.
Match exact designation:
Horizons> DES= 1990 MU;Horizons> 1990 MU;Horizons> 1990 MU
Select numbered asteroid:
Horizons> 1;(Object in database record #1, “1 Ceres”)
Define an arbitrary object not in database
Horizons> ;
Comet searches:
Horizons> COMNAM= HER*;(Comet names (only) containing “her”)Horizons> DES= 73P;(Request comet 73P apparitions, including fragments, if any)Horizons> DES= 73P; NOFRAG(Request apparitions of comet 73P, excluding fragments)Horizons> DES= 73P; CAP(Request comet 73P apparition solution closest to present date, including any fragments)Horizons> DES= 73P; NOFRAG; CAP(Request comet 73P apparition solution closest to present date, excluding any fragments)Horizons> COM; NOFRAG; CAP(List the apparition solutions closest to to the present date for all comets, excluding fragments)Horizons> NAME=Halley;CAP<1690;(Request last Halley apparition prior to the year 1690)
Spacecraft Trajectories in Horizons
Horizons was generally intended to make the natural-body dynamics work of the JPL Solar System Dynamics Group accessible to astronomers and mission planners. However, it is often convenient to make spacecraft trajectory information available through the same mechanism, especially for use by space-based telescopes as observing sites.
Sources of the spacecraft trajectory data in Horizons include navigation teams at JPL, flight projects at other NASA centers, ESA, as well as TLE-based orbits from the Joint Space Operations Center (JSpOC). Trajectories provided by navigation teams reflect the full dynamical model, including thruster firings, solar pressure, extended spherical harmonic gravity fields, atmospheric drag, and whatever other dynamic model is used for navigation.
While Horizons will always have the latest comet, asteroid, planet, and natural satellite solutions, keeping current with the externally produced spacecraft trajectories is problematic; there is no mandate or funding or staff for this, and maneuvers and mission planning changes can occur without notification, making a trajectory obsolete after some point in time.
Some flight projects do set up a regular delivery schedule to keep Horizons current (some mission science teams use Horizons for planning). More typically, a spacecraft is added if its inclusion is requested by a researcher with a specific need.
A flight project might provide an initial planning trajectory prior to launch and a final historical trajectory after end of mission. This is often sufficient for spacecraft in interplanetary trajectory phases, since the spacecraft are maneuvered to maintain such reference trajectories, which are often designed years in advance.
However, spacecraft trajectories can get orphaned in Horizons if updates stop happening. Always check the revision date in the upper left corner of the Horizons spacecraft data-sheet to determine the last time the spacecrafts’ trajectory was updated, and read the data-sheet comments for mission status information.
Spacecraft in low Earth orbit in particular (such as ISS, HST, Swift, GALEX) need frequent updates to maintain high accuracy. Predictions more than a few days into the future can have 10s or 100’s of km of error, especially since maneuvers are not anticipated in the TLE-based predicts. Users can input their own TLEs to define an artificial satellite and propagate its trajectory, as described elswehere in this documentation.
For interplanetary missions, users having high-precision applications (such as mission data reduction) should contact JPL Solar System Dynamics to verify the status of the specific trajectory in Horizons if there is doubt as to the available trajectorys’ revision status:
Jon.D.Giorgini@jpl.nasa.gov (SSDG analyst)
Some archival mission trajectories are available. These spacecraft trajectories are often expressed relative to older, target-body trajectories such that multi-km offsets can appear if output is instead requested relative to a modern target-body trajectory. This is because the modern solutions are derived from different measurement datasets and dynamical models (planetary ephemerides), introducing inconsistencies.
To avoid this, Horizons usually includes the original mission-target ephemeris to permit consistent reconstruction with the archived spacecraft trajectory.
For example, the NEAR spacecraft trajectory during the Eros mapping phase was expressed relative to the asteroid Eros within the dynamical system of the DE200 planetary ephemeris, and has not been updated, while Eros’ trajectory is now expressed in Horizons relative to the Sun in the system of the DE441 planetary ephemeris.
To obtain the historically accurate position of NEAR with respect to Eros as it was during the mission, select the archived Eros trajectory along with the archived NEAR trajectory. How to do this is explained in the Horizons data-sheet for NEAR, but amounts to specifying the SPK ID of the archived target body instead of integrating it from the database of orbital elements.
For example, to obtain ….
-
NEAR wrt historical Eros orbit solution (#80):
Specify target as
NEARwith observing center@ 2000433 -
NEAR wrt current Eros orbit solution: Not available
-
Eros historical orbit solution (#80) wrt to NEAR:
Specify target as
2000433with observing center@ NEAR -
Eros current orbit solution wrt NEAR (offset wrt to historical):
Specify target as
Eros;or2000433;, observing center@ NEAR
Coordinate Center (Observing Site) Selection
Once a target is specified, the next step is to specify the origin of the coordinate system, or the “observing point”, relative to which the ephemeris output quantities should be expressed.
While osculating element tables may be generated with respect to a major body center only, vector and observer tables may produce output with respect to an arbitrary observing site defined with respect to a major body center.
Earth Sites
For the Earth, a list with the locations of 2300+ sites is predefined. The
list generally matches that of the Minor Planet Center while providing an
expanded list of radar/radio sites (which have negative ID numbers). Station
500 is the geocenter.
Non-Earth Sites
For non-Earth major bodies, station 500 also represents the body center. For those major bodies with IAU rotational models, additional topocentric sites may be defined. Spacecraft landing sites are typically predefined on non-Earth bodies.
Specifying a Predefined Observing Site
There are several equivalent ways of specifying an observing location. The most general form that always works is …
site @ body
… where “site” is a numeric code or name fragment of an observatory to match, and “body” is a numeric major body code or name fragment to match.
A list of such major body codes follows later in this document, or type MB at
the main Horizons prompt in the command-line interface, or send “COMMAND= MB”
via API or e-mail interfaces. For the web interface, see
https://ssd.jpl.nasa.gov/horizons/time_spans.html
Here are four equivalent ways of searching for and specifying the same Earth site location:
Code Meaning
----------- -------------------------------------------------------------
675@399 Site #675 on Earth (Palomar Mountain)
palomar@399 "
675@ "
Palomar " (observer table only)
Observer & Vector Tables
If an observer or vector table has been requested, the @ symbol may be
dropped; the Earth will be assumed if only an integer like 675 or a name
fragment like Palom is input.
However, if you are trying to specify an observing site not on Earth, you MUST
use the @ symbol for correct interpretation. For example, if an observer table
as seen from the Sun is desired, it must be specified as @10 or @sun.
Specifying 10 only will select the Caussols site.
Element Tables
For an osculating element table, the different assumption (for abbreviated
input of specified center) is made that a coordinate center request lacking
a @ symbol is a major body. For example, 10 would mean the Caussols site
for an observer or vector table, but Sun for a vector table. 10@ or
10@399 would mean the Caussols site for both table types.
The different assumptions are meant to be efficient for the particular types of
output requested, expediting “typical” usage, especially in the command-line
interface. However, the full form site @ body can always be used to avoid
having to remember “quirks”.
If your specification returns more than one possible match, the list of matched sites is returned. Refine your site request to be more specific, by using the unique numeric codes listed for example, and try again.
While one can spell out the names of the bodies and sites, it is possible unique matches won’t be returned. Thus, use the unique ID numbers when known.
For example, 675 @ Earth will first look for the body, match both the Earth &
Earth-Moon barycenter, thus have to quit before finding specific Palomar site
coordinates. 675 @ 399 is unique and avoids this problem. Spaces & upper/lower
case are ignored.
Here are examples for sites on bodies other than the Earth:
Code Meaning
------------ -------------------------------------------------------------
Viking@499 List all defined Viking lander sites on Mars
Viking-1@499 Select Viking-1 landing site on Mars
1 @301 Site #1 on the Moon
500 @ 501 Io body center
3 @ 499 Site #3 on Mars
The asterisk (‘*’) can be used to generate lists:
Code Meaning
------------ -------------------------------------------------------------
*@301 List all predefined sites on the Moon
*@Phobos List all predefined sites on the Martian moon Phobos
*@399 List all predefined sites on Earth
*@ List all predefined sites on Earth (observer/vector table)
* List all predefined sites on Earth (observer/vector table)
* List all major bodies (element table only)
There are a several ways to request a body-centered site for a major body.
Code Meaning
------------ -------------------------------------------------------------
500@601 Mimas body center
geo@601 "
g@601 "
g@Mimas "
500@Deimos Deimos body center
geo Earth Geocenter
g@399 Earth Geocenter
User-Defined Topocentric Site Coordinates
Many small or recently discovered natural satellites do not have defined rotation models, thus do not support topocentric site definition. Only body-centered observers can be defined.
However, for sites with rotation models, topocentric sites may be input by the user as follows (command-line interface only; API, web, and e-mail specify with query settings or filling in boxes):
Code Meaning
------------ -------------------------------------------------------------
c @ Europa Request prompting for user location on satellite Europa
coord @ 502 (same thing)
After coordinate input is requested, the site location may be entered as either geodetic or cylindrical coordinate triplets, separated by commas:
GEODETIC (generally this means map coordinates)
E-long - Geodetic east longitude (DEGREES)
lat - Geodetic latitude (DEGREES)
h - Altitude above reference ellipsoid (km)
CYLINDRICAL
E-long - Angle eastward from XZ plane (DEGREES)
DXY - Distance from Z axis (KM)
DZ - Height above XY equator plane (KM)
For Earth, observing site coordinates should be specified relative to the ITRF93 (or WGS-84 GPS) reference ellipsoid. The two systems differ by about 0.1 meters, but are currently treated as interchangeable in Horizons.
Altitude specifications should be with respect to the reference ellipsoid, not “mean sea level”. There can be more than 100 meters of difference between MSL and ellipsoid altitudes of a site. Separate on-line tools can help convert from MSL to ellipsoid altitude:
https://geographiclib.sourceforge.io/cgi-bin/GeoidEval
For other bodies, Horizons uses planetodetic/geodetic IAU coordinates (or mean Earth of DE421 for the Moon). This is typically the one used on maps, such as those by the USGS, unless the map says otherwise. In these coordinates, the rotational pole of the body that lies on the positive (north) side of the invariable plane of the solar system (the plane perpendicular to the solar systems’ angular momentum vector) is called the “north pole”.
Northern latitudes are positive, southern are negative. The planetodetic latitude takes into account body oblateness and, for a point on the surface, is the angle between the body equatorial plane and the normal to the reference surface at that point. For a point not on the reference surface, the geodetic latitude is the latitude of the point on the reference surface where the normal passes through the point at some altitude (h) above the reference surface.
Prograde (or direct) rotation of a body is rotation eastward, or counter- clockwise, as seen from the north pole. For such bodies (with the exception of the Earth, Moon, and Sun discussed next), positive longitude values are taken to mean west and so the equivalent longitude eastward is specified negatively from the prime meridian (i.e., west-longitude - 360). For example, if you have a site on Mars at 12 degrees west, and Horizons asks you to enter the eastward longitude, enter -348 degrees. The negative sign is used in place of an “E” symbol to ensure proper input.
Exceptions are the Earth, Moon and Sun, where longitude has historically been measured both east and west of the prime meridian. Though these bodies are direct rotators, positive longitude values are assumed to be eastward in this system due to historical precedence.
If starting with the positive west-longitude of an observing site on Earth, Moon, or Sun, it should be input here as an equivalent positive east-longitude, which would be (360 - given west-longitude). For example, if a site is at 23 degrees west on Earth, and Horizons asks you to specify the east-longitude (as it will), enter 337 degrees.
If a negative “east-longitude” value (“meaning westward”) is instead available for a location on these three bodies, one can input the negative value. However, it will be converted to a positive east-longitude on output, as (360 + value). For example, if Horizons asks for the east-longitude of an observing site on Earth and a “-5” is entered, it will be taken to mean the equivalent 355 degrees east-longitude.
Retrograde rotation is rotation westward, or clockwise as seen from the north pole. Positive numeric longitudes for these bodies are taken to mean “eastward from the prime meridian” in Horizons. If you are given a west-longitude for a site on a retrograde rotator, specify its equivalent longitude eastward to Horizons as (360 - west longitude). For example, if given a site on Venus at 78 degrees west, specify the eastward longitude to Horizons as 282 degrees.
The following major bodies are either retrograde or exceptions and require site input with positive east-longitude:
Retrograde (+ east-longitude):
------------------------------
Venus (299), Arial (701), Umbriel (702), Titania (703),
Oberon (704), Miranda (705), Cordelia (706), Ophelia (707),
Bianca (708), Cressida (709), Desdemona (710), Juliet (711),
Portia (712), Rosalind (713), Belinda (714), Puck (715),
Uranus (799), Triton (801)
Also + east-longitude (prograde exceptions):
--------------------------------------------
Sun (10), Earth (399), Moon (301)
The other major bodies are prograde rotators and must be input with negative longitudes, indicating eastward relative to the prime meridian. Since such sites are usually expressed in terms of positive west-longitude on maps, the equivalent east-negative value would be (west-longitude - 360), as described above.
To verify proper interpretation, check the ephemeris output header which reports the user-input site coordinates used in the body’s native system.
Interpreting non-Earth Observer Tables
When selecting a site on a body other than the Earth, some definitions and quantities slightly shift in meaning:
Visually interfering body
The largest other body in the system. Such a body may visually complicate observations at the site due to its brightness or by covering up the target. On the Earth, the “interfering body” is the Moon. On Io, it would be Jupiter. On Mars, it would be Phobos (largest body, though unlikely to genuinely interfere). Mercury and Venus have no interfering bodies.
Observer tables provide some optional quantities that can be used to characterize the effect of the interfering body (or IB): how far is the target from the IB in the plane-of-sky, is it obscured by the IB, what fraction of the IB is lit by the Sun as seen from the observing site, and so on.
For observation points located on Earth, the estimated visual signal-to-noise ratio (SNR) of the target relative to atmosphere-scattered moonlight is available as an optional output.
Deflecting body
Currently, only the Sun’s mass is used to compute the relativistic deflection of light that can change the apparent position of the target body.
Other changes
-
REFRACTION
No refraction effects are modeled for non-Earth sites. Any request for refraction is ignored and the refraction angle will be zero. This applies to rise-set determinations on non-Earth bodies as well.
-
AIRMASS
There is no airmass model or airmass cut-off available for non-Earth sites. Any request for airmass computation is ignored, and output as “n.a.” (not available).
-
APPARENT RA & DEC
The origin of right-ascension for apparent coordinates on NON-EARTH sites with rotational models is the meridian containing the ICRF +x-axis. Apparent declination is with respect to the particular body’s true equator-of-date. This allows an observer to align axes with the pole and use the angle output as “local apparent sidereal time” output by this system to set the RA origin and acquire the target.
For objects lacking a pole & prime meridian rotational model (spacecraft and certain asteroids that may have been redefined as “major bodies”), the inertial reference frame (ICRF or FK4/B1950) coordinate system is used to compute apparent places.
-
TIME
Time tags refer to the time-scale conversion from TDB on Earth regardless of observer location within the solar system, although clock rates may differ due to the local gravity field and no analogous time-scales are locally defined.
Limitations of non-Earth/Moon Rotation Models
For bodies other than the Earth and Moon, precession and nutation effects are not usually known to high accuracy. The IAU rotation and cartographic models used to determine surface sites may be accurate at only the ~0.1 degree or greater level in the present era for such cases.
For the gas giants Jupiter, Saturn, Uranus and Neptune, IAU longitude is based on the “Set III” prime meridian rotation angle of the magnetic field. By contrast, pole direction (thus latitude) is relative to the body dynamical equator. There can be an offset between the magnetic pole and the dynamical pole of rotation.
For many satellites, the official pole direction adopted for the IAU model was simply assumed perpendicular to the body’s mean orbit plane, lacking better information. For many satellites in the IAU model, the rotation rate was assumed equal to the mean orbital period.
Some small satellite rotational models are strictly valid only at the time of the Voyager spacecraft flyby; extrapolation to other times is problematic. Topocentric results for such bodies (610-614, for example) should be used cautiously if at all. Results in these cases reflect only the best available model, which is known to be deficient.
As rotation models are refined through observation of surface features by visiting spacecraft (Cassini, etc.), Horizons will be updated to use the best generally sanctioned models available.
Other Commands
Program information:
MB .............. Show planet/natural-satellite (major-body) ID fields
SB .............. Show small-body search-field names & meanings
NEWS ............ Display program news (new capabilities, updates, etc.)
?! .............. Extended help ('?' for brief help)
Program controls:
LIST ............ Toggle display of small-body match-parameter values
PAGE ............ Toggle screen paging (scrolling) on or off
EMAIL {X} ....... Set your email address to {X} for output delivery
TLE ............. Enter Two-Line Elements input mode (artificial sats)
/GREGORIAN ...... Turn on Gregorian calendar only input/output ("/G")
/MIXED .......... Turn on mixed Julian/Gregorian calendar mode ("/M")
TTY {R} {C}...... Check or reset screen size; "tty" or "tty 24 79" to set
; ............... Enter asteroid/comet heliocentric orbital element
input mode
X ............... Exit JPL on-line system (also "QUIT" or "EXIT")
- ............... Return to the previous prompt (back-up!)
Storing format default settings:
LOAD {macro} .... Load previously SAVED output-format {macro}.
SAVE {macro} .... Save/replace output-format macro with current settings.
DELETE {macro} .. Delete previously saved output-format macro.
Short-cuts:
- Move backward through the prompts by typing
-. - Quit from ANY prompt by entering
q. - To use a default (or previously entered value), press return.
- After selecting an object, enter
e+to produce an ephemeris format like the last one, without additional prompting.
Saving Program Settings (command-line interface only)
Command-line interactive users may go through program options once, then save all settings for recall during future sessions. This can save time, if you find yourself always changing certain defaults or routinely defining the same output format each time you connect. Others in your organization may load and use the same pre-defined format settings by name.
To save program settings, go through the prompts and define the settings as you require. Then return to the main “Horizons>” prompt.
- Type
SAVE {NAME}, where{NAME}contains 1-12 characters. - Input a password that allows you to later DELETE or REPLACE the macro
- Next time you telnet to Horizons, type
LOAD {NAME}.
Your output preferences will then be loaded in as the new defaults.
If you make a mistake or want to change a setting later, two commands are
relevant: DELETE and SAVE
DELETE a macro with command DELETE {NAME}. Alternatively, change specific
settings manually, then replace the stored macro with a SAVE to an existing
name. Delete and replace operations require input of a confirming password.
LOAD does not. Thus, anyone can use your settings if they know the macro name.
Only those who know the password can change or delete a macro.
Start/stop dates are also saved in the macro, as is observing location. You need only load the macro and select the target. Remaining defaults will be as defined in the format macro. If the macro is for an individual (personal use), you may want to set the e-mail address prior to saving. Otherwise don’t, so users of the macro will be prompted for it in the future.
A macro may be loaded, then specific settings overruled by responding to the program prompts. For example, if your last table prior to saving the macro was a “vector” table, that table type will be saved as the default.
Settings for the other table types are saved as well so, to access them, manually respond to the prompt requesting table type, over-riding the macros’ “vector” default on that issue. Start and stop times are also macro settings that may commonly be overruled as necessary.
Ideally, macro names would be something memorable:
“OBS670-1” for macro #1 for Observatory Code 670, etc.
… but the name is up to you.
The use of macros may make it less likely to stumble upon new capabilities as they are added, though they will described here and in the system news, as appropriate.
Integrator Display (command-line interface only)
Comet and asteroid ephemerides are integrated from initial conditions called “osculating elements”. These describe the 3-dimensional position and velocity of the body at a specific time. The integrator starts with this state and takes small time steps, summing the perturbing forces at each step and assessing error before taking another step. A variable order, variable step-size integrator is used to control error growth. In this way, the gravitational attraction of other major solar system bodies on the target body trajectory is taken into account.
The integrator starts at the epoch, or time, of the osculating elements. It then integrates forward or backward, as necessary, to the start of the requested table. Once it reaches the table start time, it may have to reverse direction and go forward in time to generate the table.
Every 50th step will be displayed so the user can get some sense of the progress of the ephemeris. Direction reversals are also displayed. If output is requested at small time intervals, the integrator may proceed rapidly to the start of the table. There may then be long (apparent) pauses, as numerous interpolations within a given integration step are performed to compute states at closely spaced print times.
The last number on the integrator display line is the most recent step size in days.
Specification of Time
Accepted Formats
Time may be specified many ways in addition to the primary form
YYYY-MMM-DD HH:MM:SS.fff. Of particular note are Julian Day Number and
day-of-yearforms. Examples are shown below. Input start times may be
specified to 1/1000th of a second if the default output setting is changed
from “minutes”.
Generally, if the input start time has more digits of precision specified than the selected output format, start time will be truncated to the appropriate level. For example, if a start time of 23:45:12.4 is specified, but the output format is only set to minutes, start time will automatically be changed to 23:45(:00.000).
YOUR INPUT PROGRAM INTERPRETATION
------------------------ ---------------------------
Recommended: 2027-May-5 12:30:23.3348 ( 2027-May-5 12:30:23.334 )
Acceptable:
Calendar formats:
1965-Jan-27.47083333 ( 1965-Jan-27 11:18:00.000 )
2028-05-04 18:00 ( 2028-May-04 18:00.00.000 )
04-05-2028 18:00 ( 2028-May-04 18:00.00.000 )
2 jan 1991 3:00:12.2 ( 1991-Jan-02 03:00:12.200 )
2017 MAR 10 12:00:00 ( 2017-Mar-10 12:00:00.000 )
29 February 1976 3:00 ( 1976-Feb-29 03:00:00.000 )
278bc-jan-12 12:34 ( B.C. 278-Jan-12 12:34:00.000 )
99ad-Aug-30 12:34 ( A.D. 99-Aug-30 12:34:00.000 )
bc 2417-Jul-22 12:34 ( B.C. 2417-Jul-22 12:34:00.000 )
Julian Day Number:
JD 2451545. ( 2000-Jan-01 12:00:00.000 )
JD2451545. ( 2000-Jan-01 12:00:00.000 )
JD 2433282.42345905 ( 1949-Dec-31 22:09:46.862 )
Day-of-year (DOY):
2016-365 // 12:00 ( 2016-Dec-31 12:00 )
2022-117//11:15 ( 2022-Apr-17 11:15 )
2005-276// ( 2005-Oct-03 00:00 )
45bc-35//09:30:34.241 ( 45bc-Feb-04 09:30:34.241)
YYYY--DOY//hh:mm:ss.fff
YYYY--DOY hh:mm:ss.fff
YYYY--DOY
The program will interpret other forms as well, but if you get too casual, you may end up with a surprise interpretation.
The program’s time-span prompts indicate the earliest & latest dates that may be used for the selected target/center combination, as well as the timescale assumed being input (UT, TDB, or TT). For API or browser interfaces, see https://ssd.jpl.nasa.gov/horizons/time_spans.html
For observer tables, output may be in either UT or TT timescale. For vector tables, any of three scales may be used (TDB, TT, UT). For osculating element tables, only the TDB timescale may be used.
To change the UT default for observer tables, append a “TT” when entering START time. To switch back, append a “UT” to the start time.
The three time systems are described as follows:
-
TDB (“Barycentric Dynamical Time”); typically for cartesian, osculating element, and close-approach tables. A uniform relativistic timescale and independent variable of the planetary ephemeris dynamical equations of motion.
-
TT (“Terrestrial Time”), called TDT prior to 1991, used for observer quantity tables. This is proper time as measured by an Earth-bound observer and is directly related to atomic time, TAI. TT periodically differs from TDB by, at most, 0.002 seconds.
-
UT is Universal Time. This can mean one of two non-uniform time-scales based on the rotation of the Earth. For this program, prior to 1962, UT means UT1. After 1962, UT means UTC or “Coordinated Universal Time”. Future UTC leap-seconds are not known yet, so the closest known leap-second correction is used over future time-spans.
Time Zone Corrections
Output time-tags may also be in local civil time. When specifying start time, enter your time-zone correction in the format:
YYYY-Mon-Dy HH:MM UT{s}HH{:MM}
… where
{s} ... optional sign (+ or -). If unspecified, it is assumed "+".
HH ... integer hours time-zone difference from UT
{:MM} ... optional minutes offset (usually 0)
North American standard time (winter) zone corrections are as follows:
- Atlantic Standard Time (AST) = UT-4 hours
- Eastern Standard Time (EST) = UT-5 hours
- Central Standard Time (CST) = UT-6 hours
- Mountain Standard Time (MST) = UT-7 hours
- Pacific Standard Time (PST) = UT-8 hours
If daylight savings is in effect (summer), add one hour to the above negative offsets.
For example, 1999-Jun-2 12:30 UT-8 produces a table in Pacific Standard
Time. A -7 would provide Pacific Daylight Time (or MST, if it is winter).
Gregorian and Julian Calendar Dates
Calendar dates input by users and output by the program can be set to either use the modern Gregorian calendar only, or a mixed calendar that automatically switches between the historical Julian and modern Gregorian calendars.
The Julian calendar was adopted on January 1, 45 BC. It was widely used until Oct 5, 1582, when the new Gregorian calendar began with Oct 15, 1582. The ten skipped calendar day labels restored correspondence with Earth seasons that had gradually drifted due to accumulated error in the Julian calendar.
Since the modern Gregorian calendar more accurately corresponds to physical Earth seasons and orbital motion, it is an appropriate calendar to use when analyzing such dynamical events as solstices and equinoxes.
However, historical events prior to 1582 are most likely recorded with the Julian calendar in use at that time.
If the mixed calendar mode option is active, input calendar dates 1582-Oct-15 and after are assumed to be in the Gregorian calendar system. Prior dates are assumed to be in the Julian calendar (which for earlier ancient dates is extended even prior to its 45 BC adoption).
Historically, not all regions switched between Julian and Gregorian calendars in 1582, or even in the same century. Thus, the user must be aware of which calendar was in effect for a particular historical record. It should NOT be assumed this systems’ calendar automatically correlates with a date from an arbitrary historical document.
Here is the progression near the Julian/Gregorian calendar switch point in mixed mode:
Input Julian
Calendar Type Calendar Date Julian Day Number Interpreted as
------------- ------------- ----------------- --------------
Julian 1582-Oct-03 2299158.5
Julian 1582-Oct-04 2299159.5 --> 1582-Oct-04 (J)
(skipped) "1582-Oct-05" 2299160.5 | (1582-Oct-15) (J)
(skipped) "1582-Oct-06" 2299151.5 | (1582-Sep-26) (J)
(skipped) "1582-Oct-07" 2299152.5 | (1582-Sep-27) (J)
(skipped) "1582-Oct-08" 2299153.5 | (1582-Sep-28) (J)
(skipped) "1582-Oct-09" 2299154.5 | (1582-Sep-29) (J)
(skipped) "1582-Oct-10" 2299155.5 | (1582-Sep-30) (J)
(skipped) "1582-Oct-11" 2299156.5 | (1582-Oct-01) (J)
(skipped) "1582-Oct-12" 2299157.5 | (1582-Oct-02) (J)
(skipped) "1582-Oct-13" 2299158.5 | (1582-Oct-03) (J)
(skipped) "1582-Oct-14" 2299159.5 | (1582-Oct-04) (J)
Gregorian 1582-Oct-15 2299160.5 <-- 1582-Oct-15 (G)
Gregorian 1582-Oct-16 2299161.5
Gregorian 1582-Oct-17 2299162.5
Note that “Julian dates” refer to the Julian calendar. By contrast, “Julian Day Numbers” are a different concept, a uniform counting of days that is calendar-independent aside from the count beginning at Noon mean solar time on January 1st, 4713 B.C. in the proleptic Julian calendar.
Examination of the above table shows that the date labels from Oct 5, 1582 through Oct 14, 1582 don’t exist when transitioning between calendars. Of course, the days themselves do, as is shown in the continuous Julian Day Number column; it is just a matter of what they are labeled.
If you specify a non-existent calendarlabel that was “skipped”, this program will automatically use a day number that maps into the previous Julian calendar system, as shown above in the right-hand column. For example, requesting a date of 1582-Oct-14 (skipped) is the same as requesting the Julian calendar date 1582-Oct-04.
Ancient Dates
Objects 0-10, 199, 299, 301, and 399 (planet barycenters, their equivalents
and the Sun & Moon) are available over a 9999 B.C. to A.D. 9999 interval. When
specifying ancient calendar dates, this system requires input in the “BC/AD”
system. If no BC marker is input with a calendar date, it is assumed to be
AD. Exceptions are AD years less than 100 which must have an AD symbol in
the date in order to be recognized as a valid year. For example, 66ad-jan-27
will be accepted, but 66-Jan-27 cannot be parsed.
In this system, there are no negative years. The progression is as follows:
Julian Day Number Labeling-convention
(Jan 1 00:00) BC/AD Arithmetical
----------------- ----- ------------
1720327.5 3bc -2
1720692.5 2bc -1
1721057.5 1bc 0
1721423.5 1ad 1
1721788.5 2ad 2
From this, one can see that no days (in the arithmetical year “0”, for example) are skipped in the BC/AD scheme, but they do have a different label than in the corresponding arithmetical system.
Output observer-table lines begin with a ‘b’ in column 1, to indicate B.C. dates, and a space (“ “) to indicate A.D. dates.
Output Stepping
There are three different ways of specifying when observer-table output should be generated
1. Fixed time steps
Output time steps are specified as integers with some associated units from the set {days, hours, minutes}. Example responses to the prompt include “30 days”, “1 day”, “10 min”, and so on. To get half day steps, specify “12 hour”.
It is possible to obtain output at less than 1 minute intervals. After specifying a start and stop time, give a positive integer as the “time-step”, without giving units, such as “10”. This will divide the time span into 10 parts. For example, if start and stop times are one hour (3600 seconds) apart, specifying a step of “240” will produce output every 15 seconds (3600/15 = 240 intervals). “3600” will produce output every second.
Rise/set and satellite eclipse circumstances may not be accurate to less than a minute since factors such as the primarys’ oblateness and atmosphere are not currently modelled.
2. Calendar steps:
If a step-size in units of “years” or “months” is specified, output steps will follow the calendar based on the starting date.
For example, if the start is 2008-Feb-29, and output is requested at “1 year” steps, output will be returned only for Feb 29 calendar days in those leap years having 29 days in Februrary.
If output is requested at “1 month” intervals, output will occur for every successive month on the 29th of that month. If a start date on the 31st is requested, output will only occur for months having 31 days.
3. Time-varying angular-shift steps:
Output is typically at fixed time intervals. However, observer tables may additionally be requested at time-varying steps based on an angular shift specification. That is, “output only if the object has moved at least X arcseconds in the plane-of-sky”.
When specifying step-size, with the command-line or e-mail interfaces, respond
with something like VAR ####, where #### is an integer from 60 to 3600
arcseconds. This will trigger output whenever the objects’ position is
predicted to be #### arcseconds different from the current output step
in the observers’ plane-of-sky.
To preserve system performance, the time-varying output mode uses a simple linear extrapolation to predict the time when the object should have moved the requested distance. Due to non-linearities in the objects’ actual motion in the plane-of-sky, this projection can be off by .1 to 5 (or more) arcsecs. Thus the angular-motion print criteria you give should be considered approximate.
Computed quantities will be exact for the given time in the output, but the particular output time may not be exactly that required for the requested angular change.
Reference Frames
Reference frames are used to describe the position and velocity of an object in three-dimensional space. Horizons uses several references frames, depending on the purpose and user-specification.
International Celestial Reference Frame (ICRF)
The primary reference frame is the ICRF. It is based on thousands of remote extragalactic radio sources (mostly quasars) to specify three fixed reference directions: the ICRF pole direction (+Z) and right ascension origin (+X), along with the orthogonal +Y direction.
The ICRF was constructed to closely align with the older FK5/J2000 dynamic reference frame – within the uncertainties of that system – while replacing dynamical definitions based on intersecting and moving planes with ones based on the more precisely determined and fixed radio source positions. The ICRF has no associated standard epoch and, while it was aligned closely with the original FK5/J2000 equatorial system, is not itself equatorial, just ICRF.
The JPL planetary ephemeris solution (currently DE440/441) is closely aligned with the ICRF-3 realization, and is thought to differ by at most 0.0002 arcseconds, while the ICRF is thought to differ from the previous FK5/J2000 dynamical system by at most 0.02 arcseconds.
All underlying calculations in Horizons are done in the reference frame of the planetary ephemeris (DE440/441), taken to be indistinguishable from the ICRF using currently available measurements. They are then transformed to other frames if necessary for final output.
Other reference frames developed relative to the ICRF in Horizons include:
Earth true equator and equinox of date (TOD)
This moving reference frame is defined by the Earth’s “true” pole at any instant, which defines the +z-axis, and moves due to luni-solar precession and nutation. The slowly changing intersection of the equator plane and orbit plane at any instant defines an x-axis direction called the “equinox of-date”.
Horizons currently uses the IAU76/80 precession-nutation theory, corrected daily by GPS measurements over the modern era, to transform from ICRF to the “true-of-date” reference frame. Due to different adopted ecliptics, the origin of RA (x-axis) in this intermediate reference frame differs by about -53 mas from the IAU2006/00A of-date system.
International Terrestrial Reference Frame (ITRF93)
This is the Earth body-frame to which Earth station coordinates are referred, and is produced from the Earth TOD frame with additional small GPS-derived polar motion corrections.
Lunar Mean-Earth Frame of DE421
Like the lower precision IAU lunar model, the mean Earth/polar axis model uses a +Z axis aligned with the north mean lunar rotation axis, while the prime meridian contains the mean Earth direction. This system is also sometimes called the “mean Earth/mean rotation axis” system or just “mean Earth” system, and is a rotation by a fixed offet from the DE440 principal axis (or PA) system sometimes also used in lunar studies to the standard DE421 mean Earth frame. The lunar PA frame is not currently available in Horizons.
The high precision lunar rotational-pole model is available only over the timespan A.D. 1550 - 2650. Outside that span, Horizons will automatically transition to use the low-precision IAU model. The models used are given in the output header.
For example, output involving the lunar cartographic model over 1500-2700 would contain the following summary line in the header:
Target pole/equ : IAU_MOON, MOON_ME, IAU_MOON {East-longitude positive}
… indicating output begins with the IAU_MOON model, transitions to MOON_ME at 1550, then switches back to IAU_MOON after 2650.
If the output is entirely within the 1550-2650 interval of the high-precision model (typical usage), the label would instead be:
Target pole/equ : MOON_ME {East-longitude positive}
Body equator and node of date
Rotational models for the planets, natural satellites, and some asteroids are periodically published by the IAU Working Group on Cartographic Coordinates and Rotational Elements. These specify body spin-pole direction in ICRF coordinates. Body rotation is specified relative to the intersection (node) of the body’s equator plane with the fixed ICRF fundamental plane, which defines the x-axis for the reference frame.
This is analagous to (but different from) the equinox direction used for Earth, whose of-date +x-axis is defined by intersection of an orbit and equator.
Since some bodies have poles with fixed spin directions in the IAU system, “of-date” body coordinates may actually refer to a fixed node direction. Other bodies have moving poles such that the node reference direction can shift over time.
Ecliptic of Standard Epoch (J2000 or B1950)
This fixed reference frame was nominally based on an adopted model of the Earth’s mean heliocentric orbit plane, but is now produced by rotating around the ICRF x-axis by a standard fixed obliquity angle (epsilon) of 84381.448 arcseconds.
Asteroid and comet orbit solutions at JPL and elsewhere continue to store and transfer solutions using this IAU76/86 standard ecliptic plane at the J2000 epoch.
The ecliptic concept, being based on adopted definitions of a “mean orbit plane”, is ambiguous at high-precision levels due to the mutual motion of the Earth and Moon. Consistent usage is most important. If doing physics such as orbit propagations at high precision levels in a different ecliptic (not recommended), use the given epsilon to transform back to ICRF, then into the desired ecliptic frame.
Given FK4/B1950 ecliptic output from Horizons, an obliquity epsilon of 84404.8362512 arc-seconds should be used to recover the original FK4/B1950 coordinates.
FK4/B1950
This older dynamical reference frame option is based on the Earth mean-equator and FK4 optical catalog equinox of the epoch B1950.0, the Julian Day Number at the start of the Besselian year B1950.0 (2433282.42345905). The Fricke equinox correction at epoch is applied. It can be described as:
- xy-plane: plane of the Earth’s mean equator at the reference epoch (B1950.0)
- x-axis : out along ascending node of the instantaneous plane of the Earth’s orbit and the Earth’s mean equator at the reference epoch
- z-axis : along the Earth mean north pole at the reference epoch
Ecliptic of date
Used for some observer table quantities, this dynamic frame uses the IAU76/80 time-varying Earth obliquity model to construct the ecliptic x-y plane of-date over modern eras and the long-term IAU76/80-compatible model of Owen, a long-term integration of Kinoshita’s polar equations of motion, for times more than 200 years from the year 2000.
Searching for Small-Bodies
Search for small-bodies with following keywords (Type R=real, I=integer,
C=char). Use comparisons from the set { <, >, <>, = }.
Separate each field with a semi-colon. Example search formulation:
A < 2.5; IN > 7.8; STYP = S; GM <> 0;
The first group of keywords are common to asteroids AND comets:
Type Keyword Description ---- ------- ----------- C NAME ...... Asteroid OR comet name fragment C DES ....... Object designation R EPOCH ..... Julian Date of osculating elements R CALEPO .... Calendar date of osc. elements; YYYYMMDD.ffff R A ......... Semi-major axis (au) R EC ........ Eccentricity R IN ........ Inclination of orbit plane (DEG) wrt ecliptic R OM ........ Longitude of Ascending Node (DEG) wrt ecliptic/equinox R W ......... Argument of Perihelion (DEG) wrt ecliptic/equinox R TP ........ Perihelion Julian Date R CALTP ..... Perihelion calendar date; YYYYMMDD.ffff R MA ........ Mean anomaly (DEG) R PER ....... Orbital period (YRS) R RAD ....... Object radius (KM) R GM ........ Object GM (KM^3/S^2), only a few are known R QR ........ Perihelion distance (au) R ADIST ..... Aphelion distance (au) R ANGMOM .... Specific angular momentum (au^2/DAY) R N ......... Mean motion (DEG/DAY) R DAN ....... Heliocentric dist. (au) of ascending node R DDN ....... Heliocentric dist. (au) of descending node R L ......... Ecliptic longitude of perihelion (DEG) R B ......... Ecliptic latitude of perihelion (DEG) I NOBS ...... Number of astrometric determinations in solution C SOLN ...... Solution ID
The next parameters are ASTEROID SPECIFIC. If one or more is used, the search
will conclude faster by examining asteroids only. For example, including
something like H > -10; will limit the search to asteroids only:
C ASTNAM .... Asteroid name fragment (designation if unnamed) R B-V ....... B-V color (asteroid) R H ......... Absolute magnitude parameter (asteroid) R G ......... Magnitude slope parameter; can be < 0 (asteroid) R ROTPER .... Rotational period, hrs (asteroid) R ALBEDO .... Geometric albedo (asteroid) C STYP ...... Spectral type, Tholen scheme (asteroid)
The next parameters are COMET SPECIFIC. If one or more is used, the search
will conclude faster by examining comets only. For example, including something
like M1 > -10; will limit the search to comets only:
C COMNAM .... Comet name fragment (designation if unnamed) I COMNUM .... Comet number R M1 ........ Total absolute magnitude (comet) R M2 ........ Nuclear absolute magnitude (comet) R K1 ........ Total magnitude scaling factor (comet) R K2 ........ Nuclear magnitude scaling factor (comet) R PHCOF ..... Phase coefficient for k2=5 (comet) R A1 ........ Radial non-grav accel (comet), au/DAY^2 R A2 ........ Transverse non-grav accel (comet), au/DAY^2 R A3 ........ Normal non-grav accel (comet), au/DAY^2 R DT ........ Non-grav lag/delay parameter (comet), days
Only 1 of the 4 keywords ASTNAM, COMNAM, NAME or DES can be
specified on a given search.
Directives
There are 5 special directives that may be used to limit or control searches:
Directive Description
--------- -----------
COM ..... Limit search to comets only
AST ..... Limit search to asteroids only
LIST .... Display parameter values for matched objects. (This may be
set as a default for all subsequent searches by typing "LIST"
at the main system prompt, "Horizons>".)
For example,
"A < 2.5; IN > 10; AST;" (match parameters against
asteroids ONLY)
"A < 2.5; IN > 10; AST; LIST;" (match AND display values
of the parameters)
NOFRAG .. Exclude/skip comet fragments
CAP ..... A filter that guarantees only one comet apparition will be
returned for each comet. It may be used three ways:
CAP; (returns last apparition before the current date)
CAP < JD#; (returns last apparition before the specified
Julian Day Number)
CAP < YEAR; (returns last apparition before the given integer
year)
If the number after a '<' is less than 10000, it is assumed
to be a year integer. Otherwise, the number is taken to be
a Julian Day Number. If "CAP;" is specified, the search is
automatically recognized as being a comets-only search.
Contents of Small-body Database & Update Frequency
Excluded from the database are single opposition asteroids with observational data arcs less than 30 days, unless they are NEOs, PHAs or radar targets (which ARE included). Everything else is in.
Except for “PHAs” and NEOs, which are usually included within a couple hours of announcement, there can be a delay of a few days to a couple weeks before newly discovered objects (that meet the filter criteria) are added. Users can input their own objects, as described in the next section. The database is updated hourly with new objects and orbit solutions.
User-Specified Small-Bodies
It is possible to define an object not in the database by manual input of HELIOCENTRIC IAU76/J2000 ECLIPTIC elements and some other optional parameters. One could also display a database entry Horizons, then “cut-and-paste” elements back into the program, varying parameters (such as magnitude), as needed. Cut-and-paste is a function of your local terminal capability.
From the command-line interface, type ‘;’ at the main prompt.
Enter the required data as described below.
Press return on a blank line when done. Input format is:
LABEL= VALUE LABEL= VALUE ...
LABEL= VALUE ...
.
.
… where acceptable label strings are defined as follows:
EPOCH .. Julian Day Number of osculating elements (TDB timescale, JDTDB)
EC ..... Eccentricity
QR ..... Perihelion distance (au)
TP ..... Perihelion Julian Day Number
OM ..... Longitude of ascending node (DEGREES) wrt IAU76/80 ecliptic
W ...... Argument of perihelion (DEGREES) with respect to IAU76/80 ecliptic
IN ..... Inclination (DEGREES) with respect to IAU76/80 ecliptic
Instead of {TP, QR}, {MA, A} or {MA,N} may be specified (not both):
MA ..... Mean anomaly (DEGREES)
A ...... Semi-major axis (au)
N ...... Mean motion (DEG/DAY)
Note that if you specify elements with MA, {TP, QR} will be computed from
them. The program always uses TP and QR internally.
Optional Inputs
RAD ...... Object radius (KM)
AMRAT .... Area-to-mass ratio (m^2/kg). Setting to a non-zero value
activates calculation of solar radiation pressure
acceleration. Total absorption is assumed, so scale the
value to account for reflectivity. For example, if 15%
of light is reflected, specify a value for AMRAT for
which the actual value is multiplied by 1.15.
For asteroids, additional OPTIONAL parameters can be given:
H ........ Absolute magnitude parameter (asteroid)
G ........ Magnitude slope parameter; can be < 0 (asteroid)
For comets, additional OPTIONAL parameters can be given:
M1 ........ Total absolute magnitude (comet)
M2 ........ Nuclear absolute magnitude (comet)
K1 ........ Total magnitude scaling factor (comet)
K2 ........ Nuclear magnitude scaling factor (comet)
PHCOF ..... Phase coefficient for k2=5 (comet)
Non-gravitational models (allowed for comets OR asteroids)
A1 ........ Radial non-grav accel (comet), au/d^2
A2 ........ Transverse non-grav accel (comet), au/d^2
A3 ........ Normal non-grav accel (comet), au/d^2
R0 ........ Non-grav. model constant, normalizing distance, au [2.808]
ALN ....... Non-grav. model constant, normalizing factor [0.1112620426]
NM ........ Non-grav. model constant, exponent m [2.15]
NN ........ Non-grav. model constant, exponent n [5.093]
NK ........ Non-grav. model constant, exponent k [4.6142]
DT ........ Non-grav lag/delay parameter (comets only), days
AMRAT ..... Solar pressure model, area/mass ratio, m^2/kg
If {R0, ALN, NM, NN, NK} are not specified, but the non-gravitational
model is activated with a non-zero A1, A2, or A3, the default values
shown are assumed, as described in “Cometary Orbit Determination and
Nongravitational Forces”, in Comets II, University of Arizona Press (2004),
pp. 137-151. They specify a semi-empirical water-ice sublimation dynamical
model appropriate for the COMETARY A1, A2, and A3 data-fit solutions
at JPL.
If ALN= 1.0, NK= 0.0, NM= 2.0, NN= 5.093, R0= 1.0 are specified
instead, the A1-A3 scaling terms from the orbit solution indicate a
non-gravitational acceleration that goes as 1 au/r^2, where r is heliocentric
distance. This simple inverse square model is useful for modeling ASTEROID
solar radiation pressure (in the A1 radial component) and/or approximating
thermal re-radiation (Yarkovsky) and other cumulative accelerations in the
transverse A2 component.
For the AMRAT solar pressure model, total absorption is assumed. Scale the
value to account for reflectivity. For example, if 15% of light is reflected,
specify a value for AMRAT for which the actual value is multiplied by 1.15.
You may enter each value on a separate line or several on one line. If you
make a mistake, re-entering the label on another line will over-write the
previously specified value. To erase a value, enter something like H=,
where no value is given. To cancel all input, enter - as the first character
on a line. To log-out, enter a q or x as first character on a line.
When done, after having pressed return on a blank line, you will be
asked whether the reference frame of the elements is J2000/ICRF or FK4/B1950.0.
You will also be asked to supply a name for the object.
Example input:
EPOCH= 2450200.5
EC= .8241907231263196 QR= .532013766859137 TP= 2450077.480966184235
OM= 89.14262290335057 W = 326.0591239257098 IN= 4.247821264821585
A1= -5.113711376907895D-10 A2= -6.288085687976327D-10
User-Specified Two-Line Elements (TLEs)
Geocentric SGP4/SDP4 Two-Line Element (TLE) format data can be specified by users to define an Earth-orbiting artificial satellite. Such data is primarily available from Space-Track.org and CelesTrak.com.
Horizons maintains trajectories for only a small subset of Earth-orbiting satellites, so this user-input option allows specification of other objects not in Horizons. These add-ins can then be used as targets (to observe) and coordinate origins (observing sites from which to observe).
The standard TLE format can be cut-and-pasted into Horizons here. For example:
SC-1 1 87820U 11053A 11273.79990913 .00099611 00000-0 64461-3 0 9991 2 87820 042.7843 189.7738 0014383 039.8647 002.5266 15.74868665 196 1 87820U 11053A 11273.86983630 -.00085102 +00000-0 -55758-3 0 9998 2 87820 042.7804 189.3478 0014258 040.7498 038.5752 15.74826749000204
-
Press
returnon a blank line when done. -
Type ‘-‘ alone on a line to abandon TLE input (discard)
-
The first line can be the objects’ name (“SC-1”), as can every 3rd line. Names are a maximum of 24 characters in length.
-
Name is optional, but if no name is provided, you will be prompted for an optional name after TLE data input is complete.
-
Multiple TLE sets can be input, up to some system limit which may change but is nominally 600 sets (1200 data lines … name lines are not counted)
-
Input TLEs can be extrapolated over a limited time-span before and after the first and last TLE epochs. This limit may change, but is nominally +/- 14 days. Extrapolation errors outside the TLE epoch bounds grow at perhaps 1-3 km per day, but this is highly variable and could be much worse if there is thruster activity. If there are large gaps in the data, ephemeris results could be heavily degraded (i.e., worthless … passing through the Earth, etc.).
-
The data does not have to be in chronological order, though that would be a normal thing to do.
-
Once a TLE object has been defined, you can go off and do other things in Horizons (when using it interactively via telnet), then come back later and select the previously input dataset as a target by typing “TLE” at the main Horizons prompt.
-
An input TLE object can be also used as a coordinate origin (an observing point) at any time, as explained below.
Local TLE ID Number:
Internally, the TLE ID (columns 3-7, so 87820 in the example above) is
prefixed with a -8 such that the temporary Horizons ID would be -887820.
This internal ID is displayed on the output, and can be used if you need to specify an observing point with respect to a user-input artifical satellite.
User-Defined TLE Objects as Observatories
Once defined, a TLE object can be used in the same way as other objects available from this system.
To generate an ephemeris of the Moon with respect to the TLE object, one
would input TLEs such as those above, then select the Moon as a target, then
specify a coordinate origin of @ -887820.
The output lunar ephemeris would then be with respect to the user-input TLE object.
Equivalently, one can specify the observing center with @ TLE notation.
This will use the last TLE object input as the coordinate origin. Only one
such TLE object can be defined at a time; new TLE input deletes the prior
specification.
Since Horizons maintains trajectories for some Earth-orbiting satellites, this capability means one can produce satellite-to-satellite ephemerides and generate relative position data for them.
Examples of satellite-to-satellite specification:
-
To observe the input TLE object from the already-in-Horizons International Space Station (ISS), request target
TLE(or-887820, for the example above), then set observing point as@ -125544. -
To instead observe ISS from the input TLE object, request target
-125544, then set the observing point as@tle(or@ -887820, for the example above).
Customizing Output
There are four types of output tables users can request and customize:
- Cartesian state vectors
- Osculating orbital element tables
- Observer tables
- Close-approach tables
Keys are embedded in output ephemerides to assist with automated reading of the output by users’ own software. The keys are:
$$SOE Start of ephemeris
$$EOE End of ephemeris
The ‘*’ symbols below denote login defaults.
Tables types 1-3 may be optionally output in a “comma-separated-value” format for import into spreadsheets.
1. Cartesian state vector table
Overview and usage:
This type of table provides the position and velocity at an instant of any object with respect to any major body or specified point on its surface. Such output would be of interest to those working on dynamical studies or needing the motion described in 3-dimensional space as a function of time.
Note that for comets and asteroids, SPK binary files can be generated by users. Such files continuously represent this same state vector information in a way that can be interpolated by user software at any intermediate instant. SPK files for major bodies, such as planets and natural satellites, must be obtained separately, such as from the Solar System Dynamics group:
https://ssd.jpl.nasa.gov/ftp/eph/planets/bsp
https://ssd.jpl.nasa.gov/ftp/eph/satellites/bsp
… or from the NAIF node of the NASA Planetary Data System (PDS),
https://naif.jpl.nasa.gov/naif/data_generic.html
… but not through Horizons, which creates and distributes SPK files for asteroids and comets only.
Reference plane
* frame ("equatorial" ICRF)
ecliptic
body (central body equator and node of date)
Reference frame:
* ICRF
B1950 (FK4/B1950)
Aberration corrections:
* NONE (geometric state vectors)
LT (light-time)
LT+S (light-time & stellar aberration)
Units:
KM and seconds
KM and days
AU and days
Quantities Output:
Format Output
------ ------
1 Position components {x,y,z} only
(with optional statistical uncertainty output)
2 State vector {x,y,z,vx,vy,vz}
(with optional statistical uncertainty output)
* 3 State vector + 1-way light-time + range + range-rate
4 Position + 1-way light-time + range + range-rate
5 Velocity components {vx, vy, vz} only
6 1-way light-time + range + range-rate
Specify one of the basic vector table output types by its numeric code (1-6).
The DEFAULT is table type 3 (with no statistical uncertainties).
Statistical uncertainties can be requested on table types 1 and 2 by adding
coordinate system code(s) x, a, r, or p after the integer, where
x refers to XYZ, a to ACN, r to RTN, and p to POS.
For example, 1xa returns position components with their uncertainties
in XYZ and ACN coordinate systems; 2ap returns position and velocity, with
their uncertainties in ACN and POS coordinates.
If no statistical data is available for a given target but uncertainty output is requested, “n.a.” symbols will appear in output (meaning “not available”).
2. Osculating orbital elements table
Overview and usage:
The instantaneous osculating orbital elements of an object with respect to a planet or barycenter.
Orbital elements encode the position and velocity (the state vector) at one instant in a geometrically meaningful way and can be used to initialize comet and asteroid numerical integrations. They should be used cautiously for any other purpose.
Reference plane:
* frame ("equatorial", ICRF)
ecliptic
body (central body equator and node of date)
Coordinate system:
* ICRF
FK4/B1950
Units:
KM and seconds
KM and days
AU and days
* Output quantities (fixed):
JDTDB Epoch Julian Date, Barycentric Dynamical Time
EC Eccentricity
QR Periapsis distance
IN Inclination w.r.t. xy-plane (degrees)
OM Longitude of Ascending Node (degrees)
W Argument of Perifocus (degrees)
Tp Periapsis time (user specifies absolute or relative date)
N Mean motion (degrees/DU)
MA Mean anomaly (degrees)
TA True anomaly (degrees)
A Semi-major axis
AD Apoapsis distance
PER Orbital Period
3. Observer table
Overview and usage:
The output values in observer tables are “as seen” by an observer, being compensated for aberrations such as light-time and other significant perspective-dependent effects.
Observer tables may be produced for any target object as seen by an observer from topocentric coordinates on or at the center of a major body (planet, natural satellite, spacecraft, and some asteroids) with a defined rotation model.
Targets can also be specified as surface coordinates on another major body, such as a crater.
Default quantities that are always present in an observer table: include
-
Time Universal Time (UT) or Terrestrial Time (TT) output timescales can be selected
-
Solar-presence symbol Indicates dawn and twilight conditions, and if the Sun’s limb is above or below the local horizon)
-
Lunar-presence Indicates if the Moon’s limb is above or below the local horizon
Additional user-selectable quantities are output in the order selected. The desired output quantities must be specified at least once. No initial default output exists in telnet or e-mail interfaces.
A detailed explanation of the user-selectable output quantities is given later, but are briefly listed here along with their selection integer:
1. Astrometric RA & DEC
* 2. Apparent RA & DEC
3. Rates; RA & DEC
* 4. Apparent AZ & EL
5. Rates; AZ & EL
6. Satellite X & Y, position angle
7. Local apparent sidereal time
8. Airmass and Visual Magnitude Extinction
9. Visual magnitude & surface Brightness
10. Illuminated fraction
11. Defect of illumination
12. Satellite angle of separation/visibility code
13. Target angular diameter
14. Observer sub-longitude & sub-latitude
15. Sun sub-longitude & sub-latitude
16. Sub-Sun position angle & distance from disc center
17. North pole position angle & sistance from disc center
18. Heliocentric ecliptic longitude & latitude
19. Heliocentric range & range-rate
20. Observer range & range-rate
21. One-way down-leg light-time
22. Speed of target with respect to Sun & observer
23. Sun-Observer-Targ ELONGATION angle
24. Sun-Target-Observer ~PHASE angle
25. Target-Observer-Moon/Illumination%
26. Observer-Primary-Target angle
27. Position Angles; radius & -velocity
28. Orbit plane angle
29. Constellation Name
30. Delta-T (TDB - UT)
* 31. Observer-centered Earth ecliptic longitude & latitude
32. North pole RA & DEC
33. Galactic longitude and latitude
34. Local apparent SOLAR time
35. Earth->Site light-time
> 36. RA & DEC uncertainty
> 37. Plane-of-sky (POS) error ellipse
> 38. Plane-of-sky (POS) uncertainty (RSS)
> 39. Range & range-rate sigma
> 40. Doppler/delay sigmas
41. True anomaly angle
* 42. Local apparent hour angle
43. PHASE angle & bisector
44. Apparent target-centered longitude of Sun (L_s)
* 45. Inertial frame apparent RA & DEC
46. Rates: Inertial RA & DEC
* 47. Sky motion: angular rate & angles
48. Lunar sky brightness & target visual SNR
… or select a pre-defined alphabetic macro below:
A = All quantities
B = Bodycentric observer -> Any target
C = Body-center observer -> Small-body target
D = Topocentric observer -> Small-body target
E = Bodycentric observer -> Spacecraft target
F = Topocentric observer -> Spacecraft target
The alphabetic short-cut macros specifically include these quantities:
A = 1-48
B = 1-3, 6, 9-33, 36-41, 43-46, 47
C = 1-3, 9-11, 13, 18-29, 33, 36-41, 43-46, 47
D = 1-5, 8-10, 11, 13, 18-29, 33-34, 36-48
E = 1-3, 8, 10, 18-25, 29, 41, 43-47
F = 1-5, 8, 10, 18-25, 29, 41-48
… with the macros for small-body cases (C and D) primarily skipping cartographic dependent quantities. Note that some small bodies (such as Ida, Gaspra, Eros, etc.) are exceptions, having IAU-defined mapping grids. For such special cases, options C & D won’t provide all available data.
“n.a.” is output in the ephemeris if a requested quantity is not available for a selected target object. The alphabetic macro codes are intended to help reduce the appearance of “n.a.” symbols in the final output. For example, when azimuth and elevation are requested for a geocentric ephemeris, or orbital uncertainies for an object without a covariance, these quantities will always be undefined and return an “n.a.” if requested.
Some quantities, such as apparent visual magnitude (#9), may display values in the ephemeris output, but then switch to “n.a.” if moving outside the range of valid calculation. For example, if the phase angle becomes high enough that the magnitude model ceases to be accurate, numeric values will not be output and the “n.a.” marker will be output instead.
The ‘*’ symbols in the quantity list above indicate quantities affected by user selection of airless or refraction-correction. Refraction correction, if requested, is available only for Earth (or body-centered observers, for which the refraction is zero since all directions are zenith). “n.a’ will be returned for all other observers.
The ‘>’ symbol above marks small-body statistical quantities computable when a covariance matrix is available in the database or supplied by users. If such a quantity is requested but no statistical propagation is available for the object, the “n.a.” symbol will be output.
In the list below, ‘*’ indicates initial program default for observer table OPTION settings:
Reference coordinate frame:
* ICRF
B1950 (FK4/B1950)
Time scale:
* UT (Universal Time)
TT (Terrestrial Time)
Time zone correction (used for UT-based tables only)
Time format
* Calendar
JD (Julian date)
Both
Time output precision (calendar format only)
* MINUTES (HH:MM)
SECONDS (HH:MM:SS)
FRACSEC (HH:MM:SS.fff)
Right-ascension format
* Hours, minutes, seconds of arc (DEC degrees, minutes, seconds)
Decimal degrees
Extra-precision on RA/DEC output
* No (~ 10^-1 arcsec; HH MM SS.ff DD MM SS.f)
Yes (~ 10^-5 arcsec; HH MM SS.ffffff DD MM SS.fffff)
Apparent coordinate corrections
* Airless
Refracted
Range units
* au
km
Suppress range-rate output (when requesting range)
* No
Yes
Minimum elevation (integer value)
* -90 degrees (turns filter OFF)
Maximum airmass (real value)
* 38.0 (Turns filter OFF, 38 is value for refracted elevation = -0 deg)
Rise/Transit/Set print ONLY
* No
TVH -- True visual horizon. Includes dip and refraction (Earth only).
GEO -- Geometric horizon. Includes refraction (Earth only).
RAD -- Radar horizon. Geometric horizon, no refraction.
Skip Daylight
* No (No cut-off, turns filter OFF)
Yes
Solar elongation cut-off (specify minimum and maximum angles for output)
* 0,180 (No cut-off, turns filter OFF)
Hour angle cut-off (-12 >= LHA >= 12, in units of decimal hours)
The absolute value of the optional input is used to temporarily turn
off output when local hour angle of the target seen from an Earth
topocentric location (only) is greater than the specified value.
* 0 (No cut-off, 0 value corresponds to transit, turns filter OFF)
RA/DEC angular rate cut-off
Output will be suppressed for those times when the user-specified
value is exceeded. The plane-of-sky angular rate is defined to be
the root-sum-of-squares (RSS) of the orthogonal linear RA*cos(DEC)
and DEC rates:
* 0 (No cut-off)
Comma-separated-value (CSV) spreadsheet output
* No
Yes
4. Close-approach table (small-bodies ONLY)
Overview and usage:
Requesting this table type (via telnet or e-mail) activates monitoring of close-approaches by the small-body target to the planets and 16 most massive asteroid perturbers. This table is not available for major body targets, only comets and asteroids numerically integrated by Horizons.
Each time an encounter minimum distance with one of the 25 objects is detected, one-line of information is generated to summarize the encounter conditions.
- Close-approach detection limits that trigger output can be changed by users, but the default values are:
Other small-bodies (i.e., the set of 16 large perturbing asteroids)
0.10 au
Planetary bodies
Merc Venu Eart Mars Jupi Satu Nept Uran Plut Moon
---- ---- ---- ---- ---- ---- ---- ---- ---- -----
0.10 0.10 0.10 0.10 1.00 1.00 1.00 1.00 0.10 0.003
To change these values, input a comma-separated list of values (when
prompted) up to the last one of interest. For example, to change the
Earth encounter limit from 0.1 au to 0.2 au, enter:
0.1, 0.1, 0.2
The values of Mercury and Venus will remain 0.1 au, but the value for
the third entry, Earth, will be changed to 0.2 au.
-
Table generation will be automatically cut-off early if the 3-sigma statistical uncertainty in the time of the encounter exceeds a default value of +/- 14400 minutes (+/- 10 days). Users can change this limit.
-
Users may also toggle output of extended output lines for detected encounters. This provides additional statistical information on the encounter. See the section on “Close Approach Tables” below, for a detailed explanation of the output.
Definition of Observer Table Quantities
The detailed description of the selectable observer table quantities follows. “Labels” refers to column headings at the start of the output table.
Time
One output line for each step. The line begins with a ‘b’ if the date is BC, a blank (“ “) if AD. This is followed by the date and time, which is either UT or TT, in calendar or JD format (or both), depending on user defaults.
Time tags refer to the time-scale conversion from TDB on Earth regardless of observer location within the solar system, although clock rates may differ due to the local gravity field and no analogous time-scales are locally defined.
Solar Presence
Time tag is followed by a blank, then a solar-presence symbol that indicates twilight and dawn conditions also:
'*' Daylight (refracted solar upper-limb on or above apparent horizon)
'C' Civil twilight/dawn
'N' Nautical twilight/dawn
'A' Astronomical twilight/dawn
' ' Night OR geocentric ephemeris
Lunar/Interfering Body Presence
The solar presence symbol is immediately followed by an “interfering body” presence symbol (which will indicate the Moon for Earth observers):
'm' Refracted upper-limb of Moon (or interfering body, 'i') is on or above
apparent horizon
' ' Refracted upper-limb of Moon (or interfering body) is below the
apparent horizon, or geocentric ephemeris
The lunar/IB presence marker (an ongoing state) can be over-ridden by a target
event marker if an event has occurred since the last output step:
'r' Rise (target body on or above cut-off RTS elevation)
'e' Elevation max (target body maximum elevation angle has occurred)
't' Transit (target body at or passed through observer meridian)
's' Set (target body on or below cut-off RTS elevation)
The ‘rets’ codes will be displayed under two conditions only: if the print interval is less than or equal to 30 minutes or the RTS-only print option has been selected.
For non-Earth observing sites, no twilight/dawn codes (C, N, or A) are output, refraction is not modeled and the interfering body marker is ‘i’ instead of the ‘m’ reserved for Earth’s Moon.
Statistical Uncertainties
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.
NOTE: “n.a.” is output if a requested quantity is not available for selected object. For example, azimuth and elevation for a geocentric ephemeris, or uncertainties for an object with no covariance in the database.
Specific Quantities
1. Astrometric RA & DEC
Adjusted for light-time aberration only. With respect to the reference
plane and equinox of the chosen system (ICRF or FK4/B1950). If the
FK4/B1950 frame output is selected, elliptic aberration terms are added.
Astrometric RA/DEC is generally used when comparing or reducing data
against a star catalog.
Labels: R.A._____(ICRF)_____DEC (HMS/DMS format)
R.A.__(FK4/B1950)___DEC (HMS/DMS format)
R.A.___(ICRF)___DEC (degree format)
R.A_(FK4/B1950)_DEC (degree format)
2. Apparent RA & DEC
Apparent right ascension and declination of the target with respect to
the specified observing center/site. "Apparent" can have three different
meanings, depending on where the observer is located:
A) For EARTH-BASED sites
Apparent coordinates are with respect to the true-equator and Earth
equinox of-date coordinate system (EOP-corrected IAU76/80 precession
and nutation of the spin-pole) and adjusted to model light-time, the
gravitational deflection of light, and stellar aberration, with an
optional (approximate) correction for atmospheric yellow-light
refraction.
Apparent RA/DEC for Earth-based sites is generally used when physically
aligning a telescope on the surface with the equator and pole of-date.
B) For NON-EARTH SITES WITHOUT ROTATIONAL MODELS
Apparent RA and DEC are with respect to the REFERENCE FRAME coordinate
system (ICRF or FK4/B1950), but still adjusted for light-time, the
gravitational deflection of light and stellar aberration.
C) For NON-EARTH SITES WITH ROTATIONAL MODELS
The origin of RA is the meridian containing the reference frame Earth
equinox (ICRF or FK4/B1950) with the X-Y equator plane defined by the
IAU rotational model. Adjusted for light-time, gravitational deflection
of light, and stellar aberration. No refraction model is available.
Labels: R.A._(a-apparent)__DEC. (airless, HMS-DMS format)
R.A._(r-apparent)__DEC. (refracted, HMS-DMS format)
R.A._(a-appar)_DEC. (airless, decimal degrees format)
R.A._(r-appar)_DEC. (refracted, decimal degrees format)
3. Rates: RA & DEC
The angular rate of change in aparent RA and DEC of the target. This is with respect to the non-inertial IAU76/80 Earth true equator and equinox of-date reference frame. d(RA)/dt is multiplied by the cosine of declination to provide a linear rate in the plane-of-sky. Units: ARCSECONDS PER HOUR. Labels: dRA*cosD d(DEC)/dt
4. Apparent azimuth & elevation (AZ-EL) :
Apparent azimuth and elevation of target. Adjusted for light-time,
the gravitational deflection of light, stellar aberration, precession and
nutation. There is an optional (approximate) adjustment for atmospheric
refraction (Earth only). Azimuth is measured clockwise from north:
North(0) -> East(90) -> South(180) -> West(270)
Elevation angle is with respect to plane perpendicular to local zenith
direction. TOPOCENTRIC ONLY.
Units: DEGREES
Labels: Azi____(a-app)___Elev (airless)
Azi____(r-app)___Elev (refracted)
5. Rates: azimuth and elevation (AZ-EL))
The rate of change of target apparent azimuth and elevation (airless). d(AZ)/dt is multiplied by the cosine of the elevation angle. TOPOCENTRIC ONLY. Units: ARCSECONDS PER MINUTE Labels: dAZ*cosE d(ELV)/dt
6. X & Y satellite offset & position angle
Satellite apparent differential coordinates in the plane-of-sky with respect to the primary body along with the satellite position angle. Differential coordinates are defined in RA as: `X= ((RA_sat - RA_primary) * cosine(DEC_primary))` ... and in DEC as: `Y= (DEC_sat - DEC_primary)` Non-lunar satellites only. "SatPANG" is the counter-clockwise (CCW) position angle from the reference-frame of-date north-pole to a line from the primary center to the satellite center. Units: ARCSECONDS (X & Y) and DEGREES (position angle) Labels: X_(sat-primary)_Y SatPANG
7. Local Apparent Sidereal Time
The angle measured westward in the body true-equator of-date plane from the meridian containing the body-fixed observer to the meridian containing the true Earth equinox (defined by intersection of the true equator of date with the ecliptic of date). TOPOCENTRIC ONLY. Units are HH MM SS.ffff or decimal hours (HH.ffffffffff) Labels: L_Ap_Sid_Time
8. Airmass & visual magnitude extinction
_RELATIVE_ optical airmass with visual magnitude extinction. Airmass is the ratio of the absolute optical airmass at the targets' refracted elevation angle with the absolute optical airmass at zenith. Also output is the estimated visual magnitude extinction due to atmosphere, as seen by the observer. _VALUES ARE OUTPUT ONLY FOR TOPOCENTRIC EARTH SITES WHEN THE TARGET IS ABOVE THE HORIZON_. Units: None (airmass) and magnitudes (extinction) Labels: a-mass mag_ex
9. Visual magnitude & surface brightness
Approximate airless visual magnitude & surface brightness, where surface
brightness is the average airless visual magnitude of a square-arcsecond
of the illuminated portion of the apparent disk.
Planets & satellites: Value for Pluto includes Charon. The Saturn rings
are included when phase angle is less than 6.5 degrees and effective
inclination less than 27 degrees. When the Moon is at phase angles < 7
degrees (within 1 day of full), the computed magnitude tends to be ~ 0.12
too dim.
Asteroids & comets: Surface brightness is returned for asteroids only if a
radius is known. Magnitudes are, in principle, accurate to about +/- 0.1
magnitude. However, measurement and calibration issues mean values should
be considered uncertain at the +/- 1.0 magnitude level. In practice, for
solar phase angles > 90 deg, the error could exceed 1 magnitude. Reduced
precision values are output for phase angles greater than 120 degrees,
since the errors could be large and unknown. Some comets have custom
magnitude laws that are described at the end of the requested ephemeris
output.
Units are (none) and VISUAL MAGNITUDES PER SQUARE ARCSECOND.
Magnitude laws:
Sun
APmag= M - 5 + 5*log10(d), where M=4.83, d=distance from Sun (parsecs)
Asteroids
APmag= H + 5*log10(delta) + 5*log10(r) -2.5*log10((1-G)*phi1 + G*phi2)
Comets
T-mag=M1 + 5*log10(delta) + k1*log10(r)
N-mag=M2 + 5*log10(delta) + k2*log10(r) + phcof*beta
Non-standard comet magnitude laws may be noted at the end of the output
ephemeris for some cases.
Surface brightness:
S-brt= V + 2.5*log10(k*PI*a*b')
Labels: APmag S-brt (Non-comet)
T-mag N-mag (comets total & nuclear magnitude)
10. Illuminated fraction
Percent of target objects' assumed circular disk illuminated by Sun (phase), as seen by observer. Units: PERCENT Labels: Illu%
11. Defect of illumination
The maximum angular width of the target body's assumed circular disk diameter NOT illuminated by the Sun. Units: ARCSECONDS Labels: Def_illu
12. Angular separation/visibility
The angular separation between the center of the target object and the
center of the (remote) primary body it revolves around, as seen by the
observer, with target visibility code. The observer cannot be on the
primary body.
Visibility codes (refers to limb-to-limb):
/t = Transiting primary body disk /O = Occulted by primary body disk
/p = Partial umbral eclipse /P = Occulted partial umbral eclipse
/u = Total umbral eclipse /U = Occulted total umbral eclipse
/- = Target is the primary body /* = None of above ("free and clear")
The radius of both primary and target body is taken to be the equatorial
value (maximum, given a triaxial shape). Atmospheric effects and oblateness
aspect are _NOT_ currently considered. Light-time is considered.
Labels: ang-sep/v
13. Target angular diameter
The equatorial angular width of the target body full disk, if it were fully illuminated and visible to the observer. If the target body diameter is unknown, "n.a." is output. Labels: Ang-diam
14. Observer sub-longitude & sub-latitude
Apparent planetodetic longitude and latitude of the center of the target disc seen by the OBSERVER at print-time. This is not exactly the same as the "nearest point" for a non-spherical target shape (since the center of the disc might not be the point closest to the observer), but is generally very close if not a very irregular body shape. The IAU2009 rotation models are used except for Earth and MOON, which use higher-precision models. For the gas giants Jupiter, Saturn, Uranus and Neptune, IAU2009 longitude is based on the "System III" prime meridian rotation angle of the magnetic field. By contrast, pole direction (thus latitude) is relative to the body dynamical equator. There can be an offset between the magnetic pole and the dynamical pole of rotation. Down-leg light travel-time from target to observer is taken into account. Latitude is the angle between the equatorial plane and perpendicular to the reference ellipsoid of the body and body oblateness thereby included. The reference ellipsoid is an oblate spheroid with a single flatness coefficient in which the y-axis body radius is taken to be the same value as the x-axis radius. Whether longitude is positive to the east or west for the target will be indicated at the end of the output ephemeris. Units: DEGREES Labels: ObsSub-LON ObsSub-LAT
15. Solar sub-longitude & sub-latitude
Apparent sub-solar longitude and latitude of the Sun on the target. The apparent planetodetic longitude and latitude of the center of the target disc as seen from the Sun, as seen by the observer at print-time. This is _NOT_ exactly the same as the "sub-solar" (nearest) point for a non-spherical target shape (since the center of the disc seen from the Sun might not be the closest point to the Sun), but is very close if not a highly irregular body shape. Light travel-time from Sun to target and from target to observer is taken into account. Latitude is the angle between the equatorial plane and the line perpendicular to the reference ellipsoid of the body. The reference ellipsoid is an oblate spheroid with a single flatness coefficient in which the y-axis body radius is taken to be the same value as the x-axis radius. Uses IAU2009 rotation models except for Earth and Moon, which uses a higher precision models. Values for Jupiter, Saturn, Uranus and Neptune are Set III, referring to rotation of their magnetic fields. Whether longitude is positive to the east or west for the target will be indicated at the end of the output ephemeris. Units: DEGREES Labels: SunSub-LON SunSub-LAT
16. Sub-solar position angle & distance from disc center
Targets' apparent sub-solar point position angle (counter-clockwise with respect to direction of true-of-date reference-frame north-pole) and angular distance from the sub-observer point (center of disc) at print time. A negative distance indicates the sub-solar point (center of disc) is on the hemisphere hidden from the observer. Units: DEGREES and ARCSECONDS Labels: SN.ang SN.ds
17. North pole position angle & distance from disc center
Targets' apparent north-pole position angle (counter-clockwise with respect to direction of true-of-date reference-frame north pole) and angular distance from the sub-observer point (center of disc) at print time. A negative distance indicates the north-pole is on the hidden hemisphere. Units: DEGREES and ARCSECONDS Labels: NP.ang NP.ds
18. Heliocentric ecliptic longitude & latitude
Geometric heliocentric (J2000 or B1950) ecliptic longitude and latitude of target at the instant light leaves it to be observed at print time (print time minus down-leg light-time). Units: DEGREES Labels: hEcl-Lon hEcl-Lat
19. Solar range & range-rate (relative to target)
The Sun's apparent range ("r", light-time aberrated) and range-rate
("rdot") relative to the target, as seen by the observer. A positive "rdot"
means the target was moving away from the Sun, negative indicates
movement toward the Sun.
Units: {AU,KM} and KM/S.
Labels: r rdot
20. Target range & range rate (relative to observer)
Target apparent range ("delta", light-time aberrated) and range-rate
("delta-dot") relative to the observer. A positive "deldot" means the
target is moving away from the observer, negative indicates movement
toward the observer.
Units are AU and KM/S.
Labels: delta deldot
21. Down-leg light-time
Target one-way down-leg light-time, as seen by observer. The elapsed time since light (observed at print-time) left or reflected off the target. Units: MINUTES Labels: 1-way_down_LT
22. Speed with respect to Sun & observer
Magnitude of the targets' velocity with respect to the Sun center and the observer at the time light left the target to be observed (print time minus down-leg light-time). These are absolute values of the velocity vectors (total speeds) and do NOT indicate direction of motion. Units: KM/S Labels: VmagSn VmagOb
23. Sun-Observer-Target (apparent solar elongation) angle
Sun-Observer-Target apparent SOLAR ELONGATION ANGLE seen from the
observers' location at print-time.
The '/r' column provides a code indicating the targets' apparent
position relative to the Sun in the observers' sky, as described below:
Case A: For an observing location on the surface of a rotating body, that
body rotational sense is considered:
/T indicates target TRAILS Sun (evening sky: rises and sets AFTER Sun)
/L indicates target LEADS Sun (morning sky: rises and sets BEFORE Sun)
Case B: For an observing point that does not have a rotational model (such
as a spacecraft), the "leading" and "trailing" condition is defined by the
observers' heliocentric ORBITAL motion:
* If continuing in the observers' current direction of heliocentric
motion would encounter the targets' apparent longitude first,
followed by the Sun's, the target LEADS the Sun as seen by the
observer.
* If the Sun's apparent longitude would be encountered first, followed
by the targets', the target TRAILS the Sun.
Two other codes can be output:
/* indicates observer is Sun-centered (undefined)
/? Target is aligned with Sun center (no lead or trail)
The S-O-T solar elongation angle is numerically the minimum separation
angle of the Sun and target in the sky in any direction. It does NOT
indicate the amount of separation in the leading or trailing directions,
which would be defined along the equator of a spherical coordinate system.
Units: DEGREES
Labels: S-O-T /r
24. Sun-Target-Observer angle
The Sun-Target-Observer angle; the interior vertex angle at target center formed by a vector from the target to the apparent center of the Sun (at reflection time on the target) and the apparent vector from target to the observer seen at print-time. Closely approximates true PHASE ANGLE (requestable separately) but is slightly different at the few arcsecond level in that it includes stellar aberration on the down-leg from target to observer. Units: DEGREES Labels: S-T-O
25. Target-Observer-Moon angle and illuminated fraction
Lunar elongation angle and fraction of Moon that is lit by the Sun. The apparent angle between the target and the Moon's center (or largest "visually interfering" body in the system), seen from the observers' location, along with fraction of the lunar disk that is illuminated by the Sun. A negative lunar elongation angle indicates the target center is behind the Moon. Units: DEGREES and PERCENT Labels: T-O-M/Illu%
26. Observer-Primary-Target angle
Observer-Primary-Target angle; apparent angle between a target satellite, its primarys' center and an observer at print time. Interior vertex angle at the primary. Units: DEGREES Labels: O-P-T
27. Position angles of heliocentric radius & -velocity vector
The position angles of the extended Sun-to-target radius vector ("PsAng")
and the negative of the targets' heliocentric velocity vector ("PsAMV"),
as seen in the observers' plane-of-sky, measured CCW (east) from reference
frame north-pole. Computed for small-bodies only (and primarily intended
for ACTIVE COMETS), "PsAng" is an indicator of the comets' gas-tail
orientation in the sky (being in the anti-sunward direction) while "PsAMV"
is an indicator of dust-tail orientation.
Units: DEGREES
Labels: PsAng PsAMV
28. Orbit plane angle
Angle between observer and target orbital plane, measured from center of target at the moment light seen at observation time leaves the target. Positive values indicate observer is above the objects' orbital plane, in the direction of reference frame +z axis. Small-bodies only. Units: DEGREES. Labels: PlAng
29. Constellation ID
The 3-letter abbreviation for the constellation name of targets' astrometric position, as defined by the IAU (1930) boundary delineation. See documentation for list of abbreviations. Labels: Cnst
30. TDB-UT
Difference between the uniform Barycentric Dynamical time-scale and the Earth-rotation dependent Universal Time. Prior to 1962, the difference is with respect to UT1 (TDB-UT1) and the 0.002 second maximum amplitude distinction between TT and TDB is not maintained. For 1962 and later, the difference is with respect to UTC (TDB-UTC) and periodic terms less than 1.e-6 second are ignored. Values beyond the next July or January 1st may change if a leap-second is later required by the IERS. Values from the present date forward through the next ~73 days are predictions. Beyond that prediction interval, the last prediction is taken as a constant for all future dates. Units: SECONDS Labels: TDB-UT
31. Observer ecliptic longitude & latitude
Observer-centered IAU76/80 ecliptic-of-date longitude and latitude of the target centers' apparent position with light-time, gravitational deflection of light, stellar aberration, and optional atmospheric refraction correction. For non-Earth sites, the Earth ecliptic at reference-frame standard epoch is used (J2000 or B1950). Units: DEGREES Labels: ObsEcLon ObsEcLat
32. Target north-pole RA & DEC
Right ascension and declination of the target body's north-pole direction at the time light left the body to be observed at print time. Target rotation model is indicated in the header. RA & DEC are consistent with the requested reference frame (ICRF or FK4/B1950). Units: DEGREES Labels: N.Pole-RA N.Pole-DC
33. Galactic longitude & latitude
Observer-centered Galactic System II (post WW II) longitude and latitude of the target centers' apparent position, with light-time, gravitational deflection of light, and stellar aberrations. Units: DEGREES Labels: GlxLon GlxLat
34. Local Apparent Solar Time
Local Apparent SOLAR Time at observing site. TOPOCENTRIC ONLY. Units are HH.fffffffffff (decimal hours) or HH MM SS.ffff
35. Earth to site light-time
Instantaneous light-time of the station with respect to Earth center at print-time. The geometric (or "true") separation of site and Earth center, divided by the speed of light. Units: MINUTES Labels: 399_ins_LT
36. Plane-of-sky RA and DEC pointing uncertainty
Uncertainty in Right-Ascension and Declination. Output values are the formal +/- 3 standard-deviations (sigmas) around nominal position. Units: ARCSECONDS Labels: RA_3sigma DEC_3sigma
37. Plane-of-sky error ellipse
Plane-of-sky (POS) error ellipse data. These quantities summarize the
targets' 3-dimensional 3-standard-deviation formal uncertainty volume
projected into a reference plane perpendicular to the observers'
line-of-sight.
Labels:
SMAA_3sig = Angular width of the 3-sigma error ellipse semi-major
axis in POS. Units: ARCSECONDS.
SMIA_3sig = Angular width of the 3-sigma error ellipse semi-minor
axis in POS. Units: ARCSECONDS.
Theta = Orientation angle of the error ellipse in POS; the
clockwise angle from the direction of increasing RA to
the semi-major axis of the error ellipse, in the
direction of increasing DEC. Units: DEGREES.
Area_3sig = Area of sky enclosed by the 3-sigma error ellipse.
Units: ARCSECONDS ^ 2.
38. Plane-of-sky ellipse RSS pointing uncertainty
The Root-Sum-of-Squares (RSS) of the 3-standard deviation plane-of-sky error ellipse major and minor axes. This single pointing uncertainty number gives an angular distance (a circular radius) from the targets' nominal position in the sky that encompasses the error-ellipse. Units: ARCSECONDS. Labels: POS_3sigma
39. Uncertainties in plane-of-sky radial direction
Range and range rate (radial velocity) formal 3-standard-deviation uncertainties. Units: KM, KM/S Labels: RNG_3sigma RNGRT_3sig
40. Radar uncertainties (plane-of-sky radial direction)
Doppler radar uncertainties at S-band (2380 MHz) and X-band (8560 MHz) frequencies, along with the round-trip (total) delay to first-order. Units: HERTZ and SECONDS Labels: DOP_S-sig DOP_X-sig RT_delay-sig
41. True anomaly angle
Apparent true anomaly angle of the targets' heliocentric orbit position; the angle in the targets' instantaneous orbit plane from the orbital periapse direction to the target, measured positively in the direction of motion. The position of the target is taken to be at the moment light seen by the observer at print-time would have left the center of the object. That is, the heliocentric position of the target used to compute the true anomaly is one down-leg light-time prior to the print-time. Units: DEGREES Labels: Tru_Anom
42. Local apparent hour angle
Local apparent HOUR ANGLE of target at observing site. The angle between the observers' meridian plane, containing Earth's axis of-date and local zenith direction, and a great circle passing through Earth's axis-of-date and the targets' direction, measured westward from the zenith meridian to target meridian along the equator. Negative values are angular times UNTIL transit. Positive values are angular times SINCE transit. EARTH TOPOCENTRIC ONLY. Units: sHH.fffffffff (decimal angular hours, with 24_hours/360_degrees) Labels: L_ap_Hour_Ang
43. Phase angle and bisector
"phi" is the true PHASE ANGLE at the observers' location at print time. "PAB-LON" and "PAB-LAT" are the FK4/B1950 or ICRF/J2000 ecliptic longitude and latitude of the phase angle bisector direction; the outward directed angle bisecting the arc created by the apparent vector from Sun to target center and the astrometric vector from observer to target center. For an otherwise uniform ellipsoid, the time when its long-axis is perpendicular to the PAB direction approximately corresponds to lightcurve maximum (or maximum brightness) of the body. PAB is discussed in Harris et al., Icarus 57, 251-258 (1984). Units: DEGREES Labels: phi PAB-LON PAB-LAT
44. Apparent target-centered longitude of the Sun (apparent L_s)
The apparent target-centered longitude of the Sun ("apparent L_s") as
seen at the target when the light recorded by the observer at print-time
reflected off the target. It is referred to a coordinate system where the
x-axis is the equinox direction defined by the targets' instantaneous
pole direction and heliocentric orbit plane at reflection time, and is
measured positively in an eastward direction (counter-clockwise around
the positive pole of the solar system angular momentum vector). The quantity
can indicate boundary dates for the target-body seasons as follows:
Northern hemisphere Southern hemisphere
0= Spring Equinox 0= Autumn Equinox
90= Summer Solstice 90= Winter Solstice
180= Autumn Equinox 180= Spring Equinox
270= Winter Solstice 270= Summer Solstice
If the target has no associated spin-pole model (common for asteroids
and comets), "n.a." will be output.
To obtain L_s observed on the target (minimizing light-time lag due to
remote observing of target), specify an observing point near the target
if possible, such as on a nearby natural satellite.
NOTE: For Earth, due to substantial Earth-Moon mutual motion, the
convention is to define seasonal boundaries using the geocentric apparent
ecliptic longitude of the Sun, not apparent L_s. Therefore, to determine
Earth seasons, request quantity #31 ("ObsEcLon") as seen from the
geocenter, with the Sun as a target. The ecliptic plane used to define
Earth seasons is a mean-of-date plane, not the true-of-date plane used for
determining seasons on other solar system bodies, as with this L_s
quantity.
Units: DEGREES
Labels: App_Lon_Sun
45. Inertial apparent RA & Dec
The apparent right ascension and declination of the target in the
ICRF or FK4/B1950 inertial reference frames, with down-leg light-time,
gravitational deflection of light, stellar aberration, and optional
yellow-light atmospheric refraction correction.
Units: DEGREES, DEGREES
Labels: RA_(ICRF-a-app)_DEC (ICRF airless, decimal degree format)
RA_(ICRF-r-app)_DEC (ICRF refracted, decimal degree format)
RA_(ICRF-a-apparnt)_DEC (ICRF airless HMS-DMS format)
RA_(ICRF-r-apparnt)_DEC (ICRF refracted, HMS-DMS format)
RA__(FK4-a-app)_DEC (FK4 airless, decimal degree format)
RA__(FK4-a-apparnt)_DEC (FK4 refracted, decimal degree format)
RA__(FK4-r-app)_DEC (FK4 airless HMS-DMS format)
RA__(FK4-r-apparnt)_DEC (FK4 refracted, HMS-DMS format)
46. Rate: Inertial RA & DEC
The angular rate of change in the targets' inertial reference-frame
apparent RA and DEC, with light-time, gravitational light deflection, and
stellar aberrations. d(RA)/dt is multiplied by the cosine of declination
to provide a linear rate in the plane-of-sky. Units: ARCSECONDS PER HOUR
Units: ARCSECONDS PER HOUR, ARCSECONDS PER HOUR
Labels: I_dRA*cosD I_d(DEC)/dt (ICRF reference frame)
F_dRA*cosD F_d(DEC)/dt (FK4/B1950 reference frame)
47. Sky motion: angular rate, direction position angle, and path angle
Total apparent angular rate of the target in the plane-of-sky. "Sky_mot_PA" is the position angle of the target's direction of motion in the plane-of-sky, measured counter-clockwise from the apparent of-date north pole direction. "RelVel-ANG" is the flight path angle of the target's relative motion with respect to the observer's line-of-sight, in the range [-90,+90], where positive values indicate motion away from the observer, negative values are toward the observer: -90 = target is moving directly toward the observer 0 = target is moving at right angles to the observer's line-of-sight +90 = target is moving directly away from the observer Units: ARCSECONDS/MINUTE, DEGREES, DEGREES Labels: Sky_motion Sky_mot_PA RelVel-ANG
48. Sky brightness and target visual signal-to-noise ratio (SNR)
Sky brightness due to moonlight scattering by Earth's atmosphere at the target's position in the sky. "sky_SNR" is the visual signal-to-noise ratio (SNR) of the target's surface brightness relative to background sky. Output only for topocentric Earth observers when both the Moon and target are above the local horizon and the Sun is in astronomical twilight (or further) below the horizon, and the target is not the Moon or Sun. If all conditions are not met, "n.a." is output. Galactic brightness, local sky light-pollution and weather are NOT considered. Lunar opposition surge is considered. The value returned is accurate under ideal conditions at the approximately 8-23% level, so is a useful but not definitive value. If the target-body radius is also known, "sky_SNR" is output. This is the approximate visual signal-to-noise ratio of the target's brightness divided by lunar sky brightness. When sky_SNR < 1, the target is dimmer than the ideal moonlight-scattering background sky, so unlikely to be detectable at visual wavelengths. In practice, visibility requires sky_SNR > 1 and a detector sensitive enough to reach the target's magnitude, even if it isn't washed out by moonlight. When relating magnitudes and brightness values, keep in mind their logarithmic relationship m2-m1 = -2.5*log_10(b2/b1). Units: VISUAL MAGNITUDES / ARCSECOND^2, and unitless ratio Labels: Lun_Sky_Brt sky_SNR
Close-Approach Tables
For asteroids and comets, a close-approach table may be requested. Output is produced only when the selected object reaches a minimum distance within a user-adjustable spherical radius from a planet or one of the sixteen largest asteroids used as pertubers in the small-body equations of motion.
User-specifications for this table can include the time-span to check, the radius of detection for planets and asteroids, the maximum uncertainty in time-of-close-approach before the table is automatically cut-off, and whether to output optional error ellipse information projected into the B-plane
The B-plane mentioned above is defined by the three orthogonal unit vectors T, R, and S (the origin being the body center). T lies in the B-plane, pointing in the direction of decreasing celestial longitude. R lies in the B-plane, pointing in the direction of decreasing celestial latitude (south). S is directed along the relative velocity vector at body encounter, perpendicular to the B-plane, and thus R and T. The B vector is the vector in the plane from the body to the point where the incoming objects’ velocity asymptote pierces the R-T plane. Note the B-plane is defined only when the incoming object is hyperbolic with respect to the body.
For objects with covariances, statistical quantities are output for each close-approach. All tabulated statistical quantities (MinDist, MaxDist, TCA3Sg, Nsigs and P_i/p) are based on a linearized covariance mapping in which higher-order (small) terms in the variational partial derivatives of the equations of motion are dropped.
Due to possible non-linearities in any given objects’ actual dynamics, this can result in significant errors at epochs distant in time from the solution epoch. Consequently, long linearized mappings (thousands, or hundreds, or sometimes just dozens of years from the present time) should be considered approximate, pending additional analysis, especially in these cases:
- objects with numerous close planetary encounters (dozens),
- objects with very close planetary encounters (< 0.01 AU),
- objects with very short data arcs (days or weeks).
While linearized projections will tend to indicate such cases with obviously rapid uncertainty growth, the specific numbers output can tend to understate orbit uncertainty knowledge.
Possible output quantities are described below. “Nominal” effectively means “highest-probability for the given orbit solution”, although there can be other possible orbits of equal probability.
If there is no covariance, no statistical quantities (marked by ‘>’ are returned. Statistical quantities output only if the user requests an “extended” close-approach table are marked by “>*” symbols:
Time (JDTDB) =
Nominal close-approach date as a Julian Day Number (Barycentric
Dynamical Time).
Date (TDB) =
Nominal close-approach time expressed as a calendar date (Barycentric
Dynamical Time). Calendar dates prior to 1582-Oct-15 are in the Julian
calendar system. Later calendar dates are in the Gregorian system.
Body =
Name or abbreviation of the planetary body or major asteroid being
closely approached by the selected small-body.
CA Dist =
Nominal geometric close-approach distance at the close-approach time,
uncorrected for light travel time. Units: au
> MinDist =
Minimum close-approach distance (formal 3-standard-deviations from
linearized covariance mapping). Units: au
> MaxDist =
Maximum close-approach distance (formal 3 standard-deviations from
linearized covariance mapping). Units: au
Vrel =
Relative velocity of the object and the body it is approaching at the
nominal time of close-approach. Units: km/s
> TCA3Sg =
Uncertainty in time of close-approach (3 standard-deviations).
Units: minutes
> SMaA-1Sg =
1-sigma error ellipse semi-major axis projected into the B-plane at
nominal time of closest-approach. Units: km
> SMiA-1Sg =
1-sigma error ellipse semi-minor axis projected into the B-plane at
nominal time of closest-approach. Units: km
>* B.T =
Component of the 1-sigma error ellipse projected onto the B-plane T-axis
at the nominal time of closest approach (B_dot_T). Units: km
>* B.R =
Component of the 1-sigma error ellipse projected onto the B-plane R-axis
at the nominal time of closest approach (B_dot_R). Units: km
>* Theta0 =
Orientation angle of error ellipse in the B-plane; the smallest angle
from the T axis to the major-axis of the error ellipse in the direction of
the +R axis. This angle is positive when clockwise around the -S axis,
negative when counter-clockwise. Units: degrees
> Nsigs =
The number of standard deviations (sigmas) required for the error
ellipse to intersect the body being closely approached.
Units: STANDARD DEVIATIONS
> P_i/p =
Linearized probability of the object impacting the body. Non-zero values
less than approximately 0.001 may not be numerically significant due to the
linearization process.
Understanding Rise, Elevation-max, Transit and Set Indicators
There are 2 ways the system can be used to mark rise, maximum elevation, transit, and set (RETS) conditions: (1) activate the RTS-only print option for an observer-table request OR (2) request a general observer table with output step interval less than 30 minutes.
Normal Table RETS-Marker Mode
RETS is indicated automatically during normal observer table generation, when the step-size is less than 30 minutes. Markers are placed to indicate the event occurred at some point in the previous step. Therefore, precision of the indicator depends on the step-size selected. For this mode, rise and set are always with respect to the true-visual-horizon reference plane (TVH), described below.
RTS-Only Print Mode
The advantage of this mode is it allows production of a more compact RTS table over a longer time-span than does the “normal” table generation mode.
When RTS-only print is selected, the program will search for the events at a user-specified resolution, from 1 to 9 minutes. Output will be generated ONLY for these three events. Maximum elevation is not included. The marker symbols in the table indicate that the event took place sometime in the previous step interval.
This RTS-only mode can be turned on at two different points in the program (command-line interface):
- Preferably, when specifying the ephemeris/search step-size
- … but also in the “change defaults” prompt structure
Three types of criteria are available for the rise and set conditions, relative to an input elevation angle (nominally 0 degrees). Select by specifying, when prompted at #1 or #2, one of these symbols:
TVH ... True visual horizon plane. The horizon seen by an observer on
the reference ellipsoid. Allows for horizon dip effect and
atmospheric refraction, but not local topography.
GEO ... Geometric horizon plane. The horizon is defined by the plane
perpendicular to the reference ellipsoid local zenith (no
horizon dip). Atmospheric refraction is estimated.
RAD ... Radar case. Geometric horizon plane, no atmospheric refraction.
For example, when prompted for the step-size, one could enter “5 min GEO’ to search, at five-minute steps, for the refracted rise/set relative to the geometric horizon.
Background Description
Rise and set elevations are taken to be the maximum of 0 or the input elevation cut-off value (0-90 deg), set in the “change defaults” prompt section. Thus, if there are local hills, one could set the elevation cut-off at 10 degrees and get RETS relative to that elevation.
At low elevations, these rise/set times should be viewed as approximations, realistically good to perhaps only 1-2 minutes at the horizon due to local atmospheric variation, weather, and topography.
To speed RTS-only searches, use the largest step-size compatible with the required accuracy. For example, considering the inherent atmospheric instability at the horizon, one should rarely need to identify rise/set to better than 5 minute accuracy for optical observations near the horizon. Setting a search-step of 5 minutes will then produce a table 5 times faster than 1 minute searching.
Radar, other low frequency observations, or optical observations at higher elevations, can be less affected by atmospheric effects and warrant finer resolution determination.
The program computes approximate refraction angles assuming yellow-light observations at 10 deg C sea-level with pressure of 1010 millibars. Corrected coordinates should be accurate to < 10 arcsec, but errors may be much larger near the horizon (+- 0.3 deg) or fluctuate unpredictably with local weather.
Both Moon and Sun rise/set are based on when the refracted upper limb of the object reaches the specified elevation. Transit and maximum elevation are based on the center of the target body.
Transit (or “upper culmination”) is when the target’s center crosses the observer’s meridian. Maximum elevation is the highest angle above the local horizons. The two conditions can occur at times differing by seconds or even minutes for close objects moving quickly.
Horizons gives priority to the transit ‘t’ marker if output resolution is too coarse to distinguish the times (no ‘e’ marker output).
Some objects such as orbiting spacecraft may not transit the observer’s meridian but still have a maximum elevation angle, therefore can have an ‘e’ marker but no ‘t’ marker.
Constellation Identification
One output value that may be requested for an observer table is the constellation it is observed to be in (corrected for light-time). The output field will contain a three letter abbreviation of the constellation name, from the list shown below.
Constellation boundaries are those delineated by Gould (1877) and Delporte (1930) under the auspices of the International Astronomical Union.
_______________________________________________________________
| Abbrev. | Constellation Name | | Abbrev. | Constellation Name |
|_________|____________________|_|_________|____________________|
| And | Andromeda | | Leo | Leo |
| Ant | Antila | | LMi | Leo Minor |
| Aps | Apus | | Lep | Lepus |
| Aqr | Aquarius | | Lib | Libra |
| Aql | Aquila | | Lup | Lupus |
| Ara | Ara | | Lyn | Lynx |
| Ari | Aries | | Lyr | Lyra |
| Aur | Auriga | | Men | Mensa |
| Boo | Bootes | | Mic | Microscopium |
| Cae | Caelum | | Mon | Monoceros |
| Cam | Camelopardis | | Mus | Musca |
| Cnc | Cancer | | Nor | Norma |
| CVn | Canes Venatici | | Oct | Octans |
| CMa | Canis Major | | Oph | Ophiuchus |
| CMi | Canis Minor | | Ori | Orion |
| Cap | Capricornus | | Pav | Pavo |
| Car | Carina | | Peg | Pegasus |
| Cas | Cassiopeia | | Per | Perseus |
| Cen | Centaurus | | Phe | Phoenix |
| Cep | Cepheus | | Pic | Pictor |
| Cet | Cetus | | Psc | Pisces |
| Cha | Chamaeleon | | PsA | Pisces Austrinus |
| Cir | Circinus | | Pup | Puppis |
| Col | Columba | | Pyx | Pyxis |
| Com | Coma Berenices | | Ret | Reticulum |
| CrA | Corona Australis | | Sge | Sagitta |
| CrB | Corona Borealis | | Sgr | Sagittarius |
| Crv | Corvus | | Sco | Scorpius |
| Crt | Crater | | Scl | Sculptor |
| Cru | Crux | | Sct | Scutum |
| Cyg | Cygnus | | Ser | Serpens |
| Del | Delphinus | | Sex | Sextans |
| Dor | Dorado | | Tau | Taurus |
| Dra | Draco | | Tel | Telescopium |
| Equ | Equuleus | | Tri | Triangulum |
| Eri | Eridanus | | TrA | Triangulum Australe|
| For | Fornax | | Tuc | Tucana |
| Gem | Gemini | | UMa | Ursa Major |
| Gru | Grus | | UMi | Ursa Minor |
| Her | Hercules | | Vel | Vela |
| Hor | Horologium | | Vir | Virgo |
| Hya | Hydra | | Vol | Volans |
| Hyi | Hydrus | | Vul | Vulpecula |
| Ind | Indus | | | |
| Lac | Lacerta | | | |
|_________|____________________|_|_________|____________________|
Long-Term Ephemerides
Solar System Model
The JPL DE-441 solar system solution [1] is the basis of planetary barycenter motion data over the interval from 13201 B.C. to A.D. 17191; Horizons currently makes available only the sub-interval from 9999 BC to A.D. 9999 (until its Y10K problem is fully handled).
The Chebyshev polynomial representation of DE441 permits rapid recovery of the original barycenter integrator state to the sub-meter level. This difference in representation is much less than the uncertainty associated with the trajectory solution itself.
Horizons uses DE441 for the following objects:
Objects ID code #
--------------------------- -------------------
All planet barycenters 0,1,2,3,4,5,6,7,8,9
Sun 10
Moon 301
Mercury 199
Venus 299
Earth 399
Natural satellites and planet-centers are determined separately, and available over various shorter intervals, as warranted by their observational data arc, but generally hundreds of years.
Planet-center offsets from the planetary system barycenter they move with respect to (barycentric shift vectors) are defined by the satellite solutions. Consequently, planet-centers are available only over the shorter intervals of that planet’s natural satellite solution.
For example, while the center of Mars (499) is available over a few hundred years as defined by the solution for the motions of the moons Phobos and Deimos, the Mars system barycenter (4) is available over 9999 B.C. to A.D. 9999.
The difference between the position of a planet center and planetary system barycenter is often not important unless one has a spacecraft in the vicinity or is studying the offset. Therefore, specifying barycenters (body-code integers less than 10) is typically acceptable if the longer time-span is of interest. This is particularly the case when generating osculating orbital elements, since specifying barycenters as targets and coordinate origins can remove high-frequency terms in the osculating elements caused by a planets’ motion with respect to its local system barycenter.
Comets and asteroids are numerically integrated on demand over a maximum interval of A.D. 1600 to A.D. 2500. Some ancient comets may be available outside that span for their relevant historical period. Only a relatively small number of such small-bodies have sufficiently well-determined orbits to justify rigorous integration over time-spans of hundreds of years. Statistical uncertainty information derived from mapped covariances is available to help the user determine the limits of useful numerical integration.
For an overview of how this information is developed, see https://ssd.jpl.nasa.gov/orbits_doc.html
Precession Model
For the time-span of 1799-Jan-1 to 2202-Jan-1, the IAU 1976 precession model of Lieske is used [9]. As published, this model is valid for only ~200 years on either side of the J2000.0 epoch. This is due to round-off error in the published coefficients and truncation to a 3rd order polynomial in the expressions for the Euler rotation angles. Therefore, outside this interval, the long-term precession and obliquity model of Owen [10] is used to maintain accuracy in the calculation of apparent (“of-date”) quantities.
This model (Owen) is a rigorous numerical integration of the equations of motion of the celestial pole using Kinoshita’s model for the speed of luni-solar precession.
Nutation Model
The IAU (1980) model of Wahr is used [11]. This is the same table printed in the 1992 Explanatory Supplement to the Astronomical Almanac. Note there is an error in the Explanatory Supplement for the Node term, given on p. 114 as:
OMEGA = 135deg 2'40.280" + ...
This system uses the correct formulation:
OMEGA = 125deg 2'40.280" + ...
ITRF93
The IAU76/80 Lieske/Wahr precession-nutation model is then corrected to produce of-date equator and equinox relative coordinates using compatible GPS-derived data in Earth-orientation parameter (EOP) files produced by JPL (and also the IERS) a few times a week. This EOP data contains measured offsets as a function of time with respect to the theory’s predicted precession and nutation angles, as well as polar motion terms needed to go from “true-of-date” to ITRF93/WGS84 terrestrial frames used with maps and GPS to specify surface locations.
Universal Time (TDB -> UT Conversion)
This program internally uses the TDB time-scale of the ephemerides (the independent variable in the equations of motion). To produce the more familiar Universal Time (UT) clock-time output linked to the Earth’s variable rotation, it is necessary to use historical reconstructions of old or ancient observations of constrained events, such as eclipses, to derive a TDB-UT difference. This program currently uses the analyses of [8] as follows:
Span TDB-UT offset ("delta-t") Type Argument (T=...)
------------------- -------------------------- ---- ------------------
9999 BC to 700 BC -10 + 31.4 * T^2 UT1 cent. since JD1825
700 BC to AD 1962 Stephenson/Morrison spline UT1 Besselian date
AD 1962 to Current EOP file UTC Date
Present to AD 9999 Last EOP file prediction UTC Date
For epochs after 1962, the calculation is as follows:
TDB - UTC = (TDB - TAI) + (TAI - UTC)
... where
TDB - TAI = Computed from current planetary ephemeris
TAI - UTC = Interpolated from current EOP file
… dropping terms in TDB-TAI having an RSS of ~4.2 usec. For dates prior to 1962-Jan-20, the periodically varying distinction between TDB and TT (with maximum offset of 0.002 seconds) is not maintained since the historical data does not support that level of accuracy.
As one progresses to earlier times, particularly those prior to the 1620 telescopic data span, uncertainties in conversion to UT generally (though not always and not uniformly) increase due to less precise observations and sparser records. At A.D. 948, uncertainty (not necessarily error) can be a few minutes. At 3000 B.C., the uncertainty in UT is about 4 hours. The TT time scale, being a uniform atomic timescale, does not have this uncertainty, but is not directly related to Earth’s rotation (local civil time) either.
Greenwich Mean Sidereal Time
The GMST used for topocentric ephemerides is related to UT1 using a standard model consistent with the adopted IAU 1976 system of constants:
GMST= 67310.548 + (3155760000. + 8640184.812866)*T_u + 0.093104*T_u^2
- 6.2e-6 * T_u^3
… where T_u is Julian centuries of 36525 days of 86400 seconds of UT1 elapsed since January 1, 2000 12:00 UT1 (J2000.0; JD 2451545.0). That is, T_u = UT1/(86400*36525), where UT1 is seconds of Universal Time UT1 elapsed since January 1, 2000 12:00 UT1.
The IERS (1992) equation of the equinoxes is used to obtain true sidereal time (true_sidereal_time = GMST + delta_THETA):
delta_THETA = delta_PSI*cos(EPSILON) + 0.00264*sin(OMEGA)
+ 0.000063*sin(2*OMEGA)
... where delta_PSI = nutation in longitude
EPSILON = mean obliquity of ecliptic
OMEGA = longitude of mean ascending node of lunar orbit
on the ecliptic
The FK4/B1950 GMST relationship is adopted from the 1961 Explanatory Supplement to the Astronomical Ephemeris, H.M. Nautical Almanac Office.
High Precision Earth Orientation Parameter (EOP) Model
The JPL EOP file is currently updated daily based on GPS and other Earth-monitoring measurements. Horizons uses it to obtain calibrations for UT1-UTC, polar motion, and nutation correction parameters necessary to determine the rotation between the Earth-fixed reference frame (IRTF93) to the inertial reference frame (ICRF).
The EOP file provides data from 1962 to the present, with predictions about 78 days into the future from the date of file release. For future times outside the available EOP data-fit or prediction intervals, Horizons uses the last predicted values available in the EOP file as constants. For historical TDB-UT calculations prior to 1962, it switches to the published reconstruction estimates described and referenced above.
Because EOP values are fit to data and include a near-term prediction interval, it is possible an ephemeris may very slightly differ from one produced days or weeks or months later, especially, if the original ephemeris extended into the predicted region of the EOP file. The most recent ephemeris will be more accurate, but if it is necessary to reproduce results exactly, contact JPL. EOP files are archived and the one used in your initial run (indicated in your output) can be retrieved. Generally, any numeric change over current EOP file time-spans will be unobservable without atomic clocks and time standards at the 10^-5 seconds or better.
Body Rotations
The current IAU rotational models for the planets and satellites are simply extended in time as necessary. The results are therefore consistent with the IAU rotational models, including any of their deficiencies: the rotation models of some satellites may be realistically valid only for much shorter periods of time, such as around the Voyager spacecraft encounters, and produce invalid results outside those windows. Users should consult the IAU cartographic report for more information and limitations on specific body models.
Statement of Ephemeris Limitations
To produce an ephemeris, observational data (optical, VLBI, radar & spacecraft) containing measurement errors are combined with dynamical models containing modeling imprecisions. A best fit is developed to statistically minimize those errors. The resulting ephemeris has an associated uncertainty that fluctuates with time.
For example, only a limited percentage of asteroid orbits are known to better than 1 arcsec in the plane-of-sky over significant periods of time. While 1991 JX center-of-mass was known to within 30 meters along the line-of-sight during the 1995 Goldstone radar experiment, errors increase outside that time-span. Uncertainties in major planet ephemerides range from meter to 1000+ km in the state-of-the-art JPL/DE441 ephemeris, used as the basis for spacecraft navigation, mission planning and radar astronomy.
Cartesian state vectors are output in all their 16 decimal-place glory. This does not mean all digits are physically meaningful. The full-precision may be of interest to those studying the ephemerides or as a source of initial conditions for subsequent integrations.
On top of this basic uncertainty, the mass parameter (GM) used to compute osculating element output is rarely known to better than 5 significant figures.
For observer angular output tables, purely local atmospheric conditions will affect “refraction-corrected” apparent places by several arcseconds, more at the horizon.
Small-body osculating orbital elements are reported in the ICRF reference frame of the planetary ephemeris. This frame is currently thought to differ by no more than 0.02 arcseconds from the old FK5 optical star catalog.
The Earth is assumed to be a rigid body and solid Earth tides affecting station location are not included (generally around 70 cm). Of course, precession and nutation effects are included, as is polar motion. TDB-TAI terms less than 20 usec are omitted. These and other Earth-model approximations result in topocentric station location errors, with respect to the reference ellipsoid, of less than 2 meters. However, many optical site positions (latitude and longitude) are reported far less accurately and could be many kilometers off.
Solar relativistic effects are included in all planet, lunar, and small body dynamics, excluding satellites. Relativity is included in observables via 2nd order terms in stellar aberration and the deflection of light due to gravity fields of the Sun (and Earth, for topocentric observers).
Deflections due to other gravity fields can potentially have an effect at the 10^-4 arcsec level but are not currently included here. Satellites of other planets, such as Jupiter could experience deflections at the 10^-3 arcsec level as well. Light-time iterations are Newtonian. This affects light-time convergence at the millisecond level, position at ~10^-6 arcsec level.
For many small natural satellites, the orbit orientation is well known, but the position of the body along the ellipse is not. Errors may be significant, especially for the lesser satellites of outer planets. Satellite osculating elements output by Horizons should NOT be used to initialize a separate integration or extrapolation. Such elements assume Keplerian motion (two point masses, etc.) which does not match, for example, kinematic models such as a precessing ellipse, used for some satellites. One would do better extrapolating mean orbital elements at https://ssd.jpl.nasa.gov/sats/elem/
Spacecraft in low Earth orbit (such as ISS, HST, Swift, GALEX) need frequent updates to maintain high accuracy. LEO predicts more than a few days into the future can have 10s or 100’s of km of error. If accurate predicts are needed, and the last update was more than a few days ago, an update can be done on request. For interplanetary spacecraft, users having high-precision applications (such as mission data reduction) should contact JPL Solar System Dynamics to verify the status of the specific trajectory in Horizons.
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.
SPK File Generation
Introduction
An SPK file is a binary file which, using SPICE Toolkit APIs, may be smoothly interpolated to retrieve an objects’ position and velocity at any instant within the file time-span. Such files may be used as input to SPICE-enabled visualization and mission design programs, allowing them to quickly retrieve accurate target body observation and data analysis ephemerides without having to integrate equations of motion. An SPK file could be considered a “recording” of the integrator.
SPK stands for “Spacecraft and Planet Kernel”. It is a file element of the SPICE system devised and maintained by the NAIF (Navigation and Ancillary Information Facility) team at JPL:
https://naif.jpl.nasa.gov/naif/index.html
SPK files may hold ephemerides for any kind of spacecraft, vehicle, or solar system body, but the SPK files produced by Horizons are only for comets and asteroids.
Potential users are advised that programming and science/math skills at an advanced college level are needed to utilize these files programmatically. Users must have a computer with a FORTRAN or C compiler, or MATLAB or IDL, or Python. The users’ own code must be capable of calling the appropriate SPICE Toolkit APIs taken from the SPICE Toolkit available here:
https://naif.jpl.nasa.gov/naif/toolkit.html
Internet access is needed to obtain the necessary SPICE components as well as the SPK files generated by Horizons.
For details about SPICE SPK files, see the SPK tutorial:
https://naif.jpl.nasa.gov/naif/tutorials.html
Horizons Implementation of small-body SPK files
SPK files can be produced on demand using the Horizons telnet interface. Horizons allows a maximum of 20 small-bodies per SPK file. To construct an SPK file for a comet or asteroid, Horizons retrieves the latest orbit solution and numerically integrates the objects’ trajectory over a user-specified time span within 1600-2500. Internal data from the integrator (difference tables) are written directly to the SPK file as this occurs. When a users’ application program reads the SPK file, using SPICE Toolkit APIs, that data can be used to reconstruct the integrator state to within machine-precision limits.
SPK files are capable of storing trajectory data with a fidelity greater than 1 millimeter (more accurately than should ever be required).
Summary information is stored in the SPK file comment area. It can be read using the “spacit” or “commnt” utility in the SPICE Toolkit distribution.
Files produced autonomously by Horizons users are considered informal file releases and should not be used for purposes affecting the safety and success of spacecraft hardware or missions without first contacting the JPL Solar System Dynamics Group:
Jon.D.Giorgini@jpl.nasa.gov (SSDG analyst)
This is because an objects’ orbit solution may be insufficiently determined over the chosen time-span to be suitable for some high-precision purposes, due to the quantity of measurements available for an object, the time-span they cover, and the objects’ dynamical path.
Although not stored in an SPK file, the statistical uncertainty of the trajectory as a function of time is available from the JPL Horizons system. This can help interpret the accuracy of the trajectory.
The orbit solutions used to produce SPK files on demand are updated in Horizons as new measurements are made. Therefore, a trajectory in a previously generated SPK file may be superceded by more recent solutions. Check the orbit solution number for an object (given as “source” in the SPK file comments area) against the latest Horizons entry to determine if an updated orbit solution is available.
External DASTCOM Small-Body Database
The small-body database Horizons uses to obtain initial integrator conditions and basic physical parameters can be retrieved and used separately outside of Horizons:
https://ssd.jpl.nasa.gov/ftp/xfr/dastcom5.zipunzip -ao dastcom5.zip
The .zip file is updated as warranted, but as often as hourly (between 30-32 minutes after the hour) to capture database changes.
Unzipping the archive will create a sub-directory with a file called
./dastcom5/doc/README.txt, explaining usage.
Other directories will contain the latest FORTRAN source code for a reader
library and application program called dxlook which accesses the database
interactively or with scripts.
The DASTCOM5 package is intended for programmers comfortable with UNIX/LINUX/MacOSX command-line usage.
External References
Major Body Physical Parameters
The bulk-property parameters or constants shown as “object data” when a planet or natural satellite is selected are not necessarily used in or even relevant to Horizons ephemeris calculations.
They are displayed for general informational purposes only, to confirm the selected object, and are from a variety of sources but primarily collected from the scientific literature and summarized in the following:
-
Yoder, C. “Astrometric and Geometric Properties of Earth and the Solar System”, published in “Global Earth Physics: A Handbook of Physical Constants”, AGU Reference Shelf 1, 1995, with some updates and corrections.
-
Clawson, J.F., et al., “Spacecraft Thermal Environments”, Chapter 2 in “Spacecraft Thermal Control Handbook, Volume I: Fundamental Technologies”, ed. D. Gilmore, 2002.
-
NSSDCA Planetary Fact Sheets (August 2018), https://nssdc.gsfc.nasa.gov/planetary/planetfact.html
-
JPL Solar System Dynamics Group (planet and satellite solutions)
See “Constant and Model References” below for the sources of data actually used by Horizons for computational work.
Asteroid Physical Parameters
These parameters can be used in Horizons computations; includes radius, rotation period, taxonomic class, albedo, etc. Updated a few times a year from the Light Curve Database (LCDB, reference below), with some other cases manually input based on data from the radar team and miscellaneous sources:
- Warner, B. D., Harris, A. W., and Pravec, P. (2009). The asteroid lightcurve database. Icarus, 202(1):134–146.
Constants and Model References
-
Major-body (planet & satellite) mass-parameter (GM) and other dynamical constants used by Horizons are from the DE441 planetary & lunar ephemeris solution:
-
“The JPL Planetary and Lunar Ephemerides DE440 and DE441”, R.S. Park, W.M. Folkner; J.G. Williams; D.H. Boggs, The Astronomical Journal, 161:105 (15pp), 2021 March.
For a list of mass-parameters used by Horizons when converting from state vectors to osculating elements (and back), see:
-
-
Other planetary and satellite constants used by Horizons, such as body triaxial dimensions, rotation, and orientation, are from:
-
“Report of the IAU/IAG Working Group on Cartographic Coordinates and Rotational Elements of the Planets and Satellites: 2009”, Celestial Mechanics and Dynamical Astronomy, Feb 2011, v. 109, pp. 101-135.
… with corrections from Cel. Mech. & Dyn. Ast., 110, August, 401-403.
-
-
Planetary & satellite magnitudes are based on:
-
Mallama, A., Hilton, J.L. “Computing apparent planetary magnitudes for The Astronomical Almanac”, Astronomy and Computing, Volume 25, October 2018, pp 10-24.
-
Krisciunas, K., Schaefer, B., “A Model for the Brightness of Moonlight”, Pub. Astro. Society of Pacific, 103:1033-1039, Sep. 1991.
-
Urban, S.E., and Seidelmann, P.K., “Explanatory Supplement to the Astronomical Almanac”, University Science Books, 2012.
-
-
Airmass computation is based on:
- “Revised Optical Air Mass Tables and Approximation Formula”, Kasten F., Young A., Applied Optics, vol 28, no. 22, p. 4735-4738, Nov. 15, 1989.
-
Atmospheric extinction computation based on:
- “Correcting for Atmospheric Extinction”, Green D.W.E., International Comet Quarterly, July 1992, Vol 14, pp. 55-59.
-
Refraction computation based on the following:
- Saemundsson, T., Sky & Telescope, July, 1986, p.70.
- Meeus, J., “Astronomical Algorithms”, 1991, p. 101-102
-
Constellation identification based on the following:
- Roman, N.G. 1987, “Identification of a Constellation from a Position”, Publ. Astronomical Society of the Pacific, 99, 695-699
- Warren, Wayne H., Jr., (1997, GSFC) private communication.
- Delporte, E. 1930, “Delimitation Scientifique des Constellations”, Cambridge, Cambridge University Press.
- Gould, B.A., 1877, “Uranometria Argentina, mapas” (Buenos Aires, Argentina: Observatorio Nacional)
-
Pre-1962 TDB-UT time-scale calculation:
-
Stephenson F.R.; Morrison L.V.; Hohenkerk C.Y., “Measurement of the Earth’s Rotation: 720 BC to AD 2015”, Proc. R. Soc. A 472:20160404, 2016-Nov-4.
-
Morrison, L.V.; Zawilski, M.; Hohenkerk, C.Y., and Stephenson F.R., “Addendum 2020 to ‘Measurement of the Earth’s Rotation: 720 B.C. to A.D. 2015’”, Proceedings of the Royal Society A, Volume 477, Issue 2246, 2021-Feb-17.
-
Lieske, J.H., “Galilean satellite evolution: observational evidence for secular changes in mean motions”, Astronomy and Astrophysics, 176, p 146-158 (1987).
-
-
Precession (IAU 1976) from 1799-Jan-1 to 2202-Jan-1:
- Lieske, J., “Precession Matrix Based on IAU (1976) System of Astronomical Constants”, Astron. Astrophys. 73, 282-284, 1979.
-
Precession (long-term) before 1799-Jan-1 and after 2202-Jan-1:
- Owen, William M., Jr., (JPL) “A Theory of the Earth’s Precession Relative to the Invariable Plane of the Solar System”, Ph.D. Dissertation, University of Florida, 1990.
-
Nutation (IAU 1980):
- Table 1,’Proposal to the IAU Working Group on Nutation’, John M. Wahr and Martin L. Smith 1979. Adopted 1980.
Acknowledgements
This software reflects the underlying contributions of several people at JPL:
Design/implementation : Jon Giorgini
Don Yeomans
Cognizant Eng. : Jon Giorgini
Contributors : Alan Chamberlin (web interface, APIs, database)
The NAIF group (SPICELIB)
(esp. Chuck Acton, Bill Taber, Nat Bachman)
Paul Chodas (some subroutines)
Major body ephemerides: Ryan S. Park (Planetary ephemerides)
Bob Jacobson (Satellites)
Marina Brozovic (Satellites)
Inquiries can be sent to Jon.D.Giorgini@jpl.nasa.gov, who is probably responsible for any errors or omissions. Solar System Dynamics Group, Jet Propulsion Laboratory, 4800 Oak Grove Drive, Pasadena, CA 91109 USA.
The system described in this document was developed at the Jet Propulsion Laboratory (Solar System Dynamics Group), California Institute of Technology, under contract with the National Aeronautics and Space Administration.
References for the Horizons system:
-
Giorgini, JD and JPL Solar System Dynamics Group, NASA/JPL Horizons On-Line Ephemeris System, < https://ssd.jpl.nasa.gov/horizons/ >, data retrieved YYYY-MON-DD.
-
“Orbit Uncertainty and Close-Approach Analysis Capabilities of the Horizons On-Line Ephemeris System”, J.D. Giorgini, P.W. Chodas, D.K. Yeomans 33rd AAS/DPS meeting in New Orleans, LA, Nov 26, 2001 - Dec 01, 2001.
-
“On-Line System Provides Accurate Ephemeris and Related Data”, Giorgini JD, Yeomans DK NASA TECH BRIEFS, NPO-20416, p. 48, Oct, 1999.
-
Giorgini, J.D., Yeomans, D.K., Chamberlin, A.B., Chodas, P.W., Jacobson, R.A., Keesey, M.S., Lieske, J.H., Ostro, S.J., Standish, E.M., Wimberly, R.N., “JPL’s On-Line Solar System Data Service”, Bulletin of the American Astronomical Society, Vol 28, No. 3, p. 1158, 1996.
