Library: Localization
time_base time_get locale::facet
A time formatting facet for input, and for parsing of date and time values
#include <locale> namespace std { class time_base; template <class charT, class InputIterator = istreambuf_iterator<charT> > class time_get; }
The primary template can be implicitly or explicitly specialized on any character type that satisfies the requirements on the type of character used by iostream class templates, and on any iterator type that satisfies the requirements of Input Iterator.
Members of the time_get facet extract time and date components from a sequence of characters and store the resulting values in one or more members of a struct tm argument. The functions parse the input sequence according to the same locale-specific format as the one used by the time_put facet to format time and date values. If the sequence does not match the format, the facet indicates an error by setting ios_base::failbit in err. See member function descriptions for details.
The time_base class includes a set of values for specifying the order in which the three parts of a date appear. The dateorder function returns one of these five possible values, as illustrated in Table 33:
| Order | Meaning |
no_order |
Date format has no set ordering |
dmy |
Date order is day, month, year |
mdy |
Date order is month, day, year |
ymd |
Date order is year, month, day |
ydm |
Date order is year, day, month |
namespace std { class time_base { public: enum dateorder { no_order, dmy, mdy, ymd, ydm }; }; template <class charT, class InputIterator = istreambuf_iterator<charT> > class time_get : public locale::facet, public time_base { public: typedef charT char_type; typedef InputIterator iter_type; explicit time_get(size_t = 0); dateorder date_order() const; iter_type get_time(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; iter_type get_date(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; iter_type get_weekday(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; iter_type get_monthname(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; iter_type get_year(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; // extension of this implementation iter_type get (iter_type, iter_type, ios_base&, ios_base::iostate&, tm*, const char_type*, const char_type*) const; // extension of this implementation iter_type get (iter_type, iter_type, ios_base&, ios_base::iostate&, tm*, char, char) const; static locale::id id; protected: virtual dateorder do_date_order() const; virtual iter_type do_get_time(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; virtual iter_type do_get_date(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; virtual iter_type do_get_weekday(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; virtual iter_type do_get_monthname(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; virtual iter_type do_get_year(iter_type, iter_type, ios_base&, ios_base::iostate&, tm*) const; // extension of this implementation virtual iter_type do_get (iter_type, iter_type, ios_base&, ios_base::iostate&, tm*, char, char) const; }; }
char_type
Type of the first template argument, charT.
iter_type
Type of the second template argument, InputIterator.
explicit time_get(size_t refs = 0)
Constructs a time_get object. Calls locale::facet (refs).
The refs argument is set to the initial value of the time_get object's reference count. A time_get object f constructed with (refs == 0) that is installed in one or more locale objects will be destroyed and the storage it occupies will be deallocated when the last locale object containing the facet is destroyed, as if by calling delete static_cast<locale::facet*>(&f).
A time_get object constructed with (refs != 0) will not be destroyed by any locale objects in which it may have been installed.
virtual ~time_get();
Destroys the facet.
static locale::id id;
Unique identifier for this type of facet.
The public members of the time_get facet include an interface to protected members. Each public member function get_xxx() calls the corresponding protected virtual member function do_get_xxx(). For instance, the public function get_time() calls its protected cousin do_get_time(). The result of the call may be cached. Subsequent calls to the public function with the same arguments may return the cached result to avoid the expense of repeatedly calling the virtual function.
dateorder date_order() const; iter_type get_date(iter_type s, iter_type end, ios_base& f, ios_base::iostate& err, tm* t) const; iter_type get_monthname(iter_type s, iter_type end, ios_base& f, ios_base::iostate& err, tm* t) const; iter_type get_time(iter_type s, iter_type end, ios_base& f, ios_base::iostate& err, tm* t) const; iter_type get_weekday(iter_type s, iter_type end, ios_base& f, ios_base::iostate& err, tm* t) const; iter_type get_year(iter_type s, iter_type end, ios_base& f, ios_base::iostate& err, tm* t) const;
Each of these public functions calls the corresponding protected virtual do_xxx() function.
iter_type get (iter_type s, iter_type end, ios_base &io,
ios_base::iostate &err,tm *t, const char_type *pat, const
char_type *pat_end) const;
The function iterates over characters in the range [pat, pat_end) that is composed of zero or more directives. Each directive is composed as follows: either a non-empty sequence of white-space characters (as determined by isspace(io.getloc(), c)); or an ordinary character other than '%' or white-space; or a conversion specification. Each conversion specification is composed of a leading '%' character followed by an optional conversion modifier, mod, and then by a conversion specifier, fmt, which determines the interpretation of the input character(s). The modifier and specifier characters are obtained by converting the (possibly wide) characters following the leading '%' character extracted from the input sequence as if by use_facet<ctype<char_type> >(io.getloc()).narrow(c, '\0').
For each ordinary character other than white-space, the function extracts a character from the input sequence and compares the two. If they are not equal, the function indicates an error by setting ios_base::failbit in err and the algorithm terminates. If the function reaches the end of the input sequence, it sets ios_base::eofbit in err and the algorithm terminates.
For each white-space character, the function extracts any white-space characters from the input sequence until it encounters a character other than white-space. If the function reaches the end of the input sequence, it sets ios_base::eofbit in err and the algorithm terminates.
For each conversion specification given by the characters fmt and mod, the function performs s = get (s, end, io, errtmp, t, fmt, mod) with a errtmp argument of type ios_base::iostate initialized to ios_base::good. If (errtmp != ios_base::good) evaluates to true after the call, the function performs err |= errtmp and the algorithm terminates.
Returns an iterator pointing just beyond the last extracted character.
iter_type get (iter_type s, iter_type end, ios_base &io,
ios_base::iostate &err, tm *t, char fmt, char mod = '\0')
const;
Returns do_get (s, end, io, err, t, fmt, mod).
The facet functions parse the string input sequence according to the same locale-specific format as the one used by the time_put facet to format time and date values. If the input sequence does not match the expected format, the functions indicate an error by setting ios_base::failbit in err. If the functions reach the end of the input sequence while attempting to extract additional characters, they set ios_base::eofbit in err. The io argument is used to obtain a reference to the ctype<char_type> facet installed in the object's locale.
The behavior of the functions is undefined if the t pointer does not point to a valid object of type tm.
virtual dateorder do_date_order() const;
Returns the a value indicating the relative ordering of the three basic parts of a date. Possible return values are:
no_order, indicating that the date format has no ordering, an ordering cannot be determined, or the date format contains components other than Month, Day and Year. no_order is never returned by the primary template, but may be used by derived classes. In the C locale, the function returns mdy.
One of dmy, mdy, ymd, ydm, indicating the relative ordering of Day, Month, and Year.
virtual iter_type do_get_date(iter_type s, iter_type end, ios_base &io, ios_base::iostate& err, tm* t) const;
Fills the appropriate members of the object pointed to by the t argument with values parsed from the character buffer specified by the range [s,end). Alphabetic characters are compared without regard to case. If the input sequence does not contain a valid date representation corresponding to the "%x" time_put specifier, then the object pointed to by t is not modified and ios_base::failbit is set in the err argument.
Returns an iterator pointing just beyond the last extracted character.
virtual iter_type do_get_monthname(iter_type s, ios_base &io, ios_base::iostate& err, tm* t) const;
Fills the t->tm_mon member with a month number (0 for January) parsed from the character buffer specified by the range [s,end). This name may be an abbreviation, but the function attempts to read a full name if valid characters are found after an abbreviation. For example, if a full name is "December", and an abbreviation is "Dec", then the string "Dece" causes an error. Characters are compared without regard to case. If an error occurs, then the object pointed to by t is not modified and ios_base::failbit is set in the err argument.
Returns an iterator pointing just beyond the last extracted character.
virtual iter_type do_get_time(iter_type s, iter_type end, os_base &io, ios_base::iostate& err, tm* t) const;
Fills out the appropriate members of the object pointed to by the t argument with time values parsed from the character buffer specified by the range [s,end). Alphabetic characters are compared without regard to case. If the input sequence does not contain a valid date representation corresponding to the "%X" time_put specifier, then the object pointed to by t is not modified and ios_base::failbit is set in the err argument.
Returns an iterator pointing just beyond the last extracted character.
virtual iter_type do_get_weekday(iter_type s, iter_type end, ios_base &io, ios_base::iostate& err, tm* t) const;
Fills the t->tm_wday member of the t argument with a weekday number (0 for Sunday) parsed from the character buffer specified by the range [s,end). This name may be an abbreviation, but the function attempts to read a full name if valid characters are found after an abbreviation. For instance, if a full name is "Monday", and an abbreviation is "Mon", then the string "Mond" causes an error. Alphabetic characters are compared without regard to case. If an error occurs, then the object pointed to by t is not modified and ios_base::failbit is set in the err argument.
Returns an iterator pointing just beyond the last extracted character.
virtual iter_type do_get_year(iter_type s, iter_type end, ios_base &io, ios_base::iostate& err, tm* t) const;
Fills in the t->tm_year member of the t argument with a year parsed from the character buffer specified by the range [s,end). Values in the range [69,99] are assumed to refer to years 1969 through 1999, and values in the range [0, 68] are assumed to refer to years 2000 through 2068; all other values are assumed to include the century. This behavior follows the requirement on the strptime() function of IEEE Std 1003.1-2001. If an error occurs, then ios_base::failbit is set in the err argument.
Returns an iterator pointing just beyond the last extracted character.
iter_type do_get (iter_type s, iter_type end, ios_base &io, ios_base::iostate &err, tm *t, char fmt, char mod)
const;
Fills the appropriate members of the object pointed to by the t argument with values parsed from the character sequence in the range [s,end) according to the corresponding format specifier and, optionally, modifier (when (mod != '\0') evaluates to true). Alphabetic characters are compared without regard to case. If the input sequence does not match the format of the corresponding specifier and modifier, then the object pointed to by t is not modified and ios_base::failbit is set in the err argument.
The following format specifiers and modifiers are recognized, as illustrated in Table 34 and Table 35.
| Conversion Specifier | Description |
%a |
Represents the day of the week. %a uses the locale's weekday names, specifiying either the abbreviated or full name. |
%A |
Same as or equivalent to %a. |
%b |
Represents the month. %b uses the locale's month names, specifiying either the abbreviated or full name. |
%B |
Same as or equivalent to %b. |
%c |
Represents date and time formatted appropriate to the locale. |
%d |
Represents the day of the month as [01,31]. Leading zeros are optional. |
%D |
Represents the date, expressed as %m / %d / %y. |
%e |
Same as or equivalent to %d. |
%h |
Same as or equivalent to %b. |
%H |
Represents the hour in 24-hour clock form as [00,23]. Leading zeros are optional. |
%I |
Represents the hour in 12-hour clock form as [01,12]. Leading zeros are optional. |
%j |
Represents the day number of the year as [001,366]. Leading zeros are optional. |
%m |
Represents the month number as [01,12]. Leading zeros are optional. |
%M |
Expresses the minute as [00,59]. Leading zeros are optional. |
%n |
Represents blank (white) space. |
%p |
Represents "a.m "or "p.m" formatted as appropriate to the locale. |
%r |
Represents the 12-hour clock time using the AM/PM notation. In the classic C locale, equivalent to %I : %M : %S %p. |
%R |
Represents the time as %H : %M. |
%S |
Represents the seconds as [00,60]. Leading zeros are optional. |
%t |
Represents blank (white) space. |
%T |
Represents the time as %H : %M : %S. |
%U |
Represents the week number of the year as a decimal number ([00,53]) with Sunday representing as the first day of the week . Leading zeros are optional. |
%w |
Expresses the weekday as a decimal number [0,6]. 0 represents Sunday. Leading zeros are optional. |
%W |
The week number of the year (Monday as the first day of the week) as a decimal number [00,53]. Leading zeros are optional. |
%x |
Represents the date in the locale's date format. |
%X |
Represents the time in the locale's time format. |
%y |
Represents the year within the century. If a century is not specified, values in the range [59,99] will refer to years 1959 to 1999 inclusive, and values in the range [00,58] will refer to years 2000 to 2058 inclusive. Leading zeros are optional. |
%Y |
Represents the year and includes the century (e.g. 1988). |
%% |
Represents a literal % character. |
Table 35 describes the recognized modified conversion specifiers.
| Name | Description |
%Ec |
Represents the locale's alternative appropriate date and time conversion. |
%EC |
Represents the locale's alternative name of the base year (period) conversion. |
%Ex |
Represents the locale's alternative date conversion. |
%EX |
Represents the locale's alternative time conversion. |
%Ey |
Represents the offset from %EC (year only) in an alternate locale conversion. |
%EY |
Represents the full alternative year conversion. |
%Od |
Represents the day of the month by using alternate locale numeric symbols. Note, leading zeros are permitted but not required. |
%Oe |
Same as or equivalent to %Od. |
%OH |
Represents the hour in 24-hour clock form using alternate numeric symbols for the locale. |
%OI |
Represents the hour in 12-hour clock form using alternate numeric symbols for the locale. |
%Om |
Represents the month using alternate numeric symbols for the locale. |
%OM |
Represents the minutes using alternate numeric symbols for the locale. |
%OS |
Represents the seconds using alternate numeric symbols for the locale. |
%OU |
Represents the week number of the year, with Sunday as the first day of the week, using alternate numeric symbols for the locale. |
%Ow |
Represents the number of the weekday (Sunday=0) using alternative numeric symbols for the locale. |
%OW |
Represents the week number of the year, with Monday as the first day of the week, using alternate numeric symbols for the locale. |
%Oy |
Represents the year (offset from %C) using alternate numeric symbols for the locale. |
Returns an iterator pointing just beyond the last extracted character.
#include <ctime> // for struct tm #include <locale> // for locale, time_get #include <sstream> // for stringstream #include <iostream> // for cout, endl // Print out a tm struct value in one atomic operation std::ostream& operator<< (std::ostream &os, const std::tm &t) { std::stringstream strm; strm << "Daylight Savings = " << t.tm_isdst << "\nDay of year = " << t.tm_yday << "\nDay of week = " << t.tm_wday << "\nYear = " << t.tm_year << "\nMonth = " << t.tm_mon << "\nDay of month = " << t.tm_mday << "\nHour = " << t.tm_hour << "\nMinute = " << t.tm_min << "\nSecond = " << t.tm_sec << '\n'; // guard for thread safety and output synchronization const std::ostream::sentry guard (os); if (guard) os.rdbuf ()->sputn (strm.str ().c_str (), strm.str ().size ()); else os.setstate (os.failbit); return os; } int main () { typedef std::istreambuf_iterator<char, std::char_traits<char> > Iter; // time struct to parse date into static std::tm timeb; // zero initialized // Unused, required by time_get std::ios_base::iostate state; // Stream object to read from std::istringstream ins (""); // Iterators into the stream object Iter begin (ins); Iter end; const std::locale loc ("C"); // Get a reference to the time_get facet in locale loc. const std::time_get<char, Iter> &tg = std::use_facet<std::time_get<char, Iter> >(loc); // Display time_base::dateorder value. std::cout << "time_base::dateorder == " << tg.date_order () << ".\n"; // Insert date string into stream. ins.str ("04/07/69"); // get_date from the stream and output tm contents. tg.get_date (begin, end, ins, state, &timeb); std::cout << "Date: Apr 7 1969\n" << timeb << std::endl; // Insert weekday string into stream. ins.str ("Monday"); // get_weekday from the stream and output tm contents. tg.get_weekday (begin, end, ins, state, &timeb); std::cout << "Weekday: Monday\n" << timeb << std::endl; // Insert time string into stream. ins.str ("06:47:32"); // get_time from the stream and output tm contents. tg.get_time (begin, end, ins, state, &timeb); std::cout << "Time: 06:47:32\n" << timeb << std::endl; return 0; } Program Output: time_base::dateorder == 2. Date: Apr 7 1969 Daylight Savings = 0 Day of year = 0 Day of week = 0 Year = 69 Month = 3 Day of month = 7 Hour = 0 Minute = 0 Second = 0 Weekday: Monday Daylight Savings = 0 Day of year = 0 Day of week = 1 Year = 69 Month = 3 Day of month = 7 Hour = 0 Minute = 0 Second = 0 Time: 06:47:32 Daylight Savings = 0 Day of year = 0 Day of week = 1 Year = 69 Month = 3 Day of month = 7 Hour = 6 Minute = 47 Second = 32
ISO/IEC 14882:1998 -- International Standard for Information Systems -- Programming Language C++, Section <IP_ADDRESS>
IEEE Std 1003.1-2001 -- The Open Group Base Specifications Issue 6, strptime


A (random) collection of functions for data manipulation.
| requires: | NumPy |
|---|---|
| requires: | SciPy |
| version: | 0.1 |
| author: | Sami-Matias Niemi |
| contact: |<EMAIL_ADDRESS>|
Functions
| average_bins(xdata, ydata, xmin, xmax[, nxbins]) | Computes mean and 16 and 84 percentiles of y-data in bins in x |
| binAndReturnFractions(x, y1, y2[, xmin, ...]) | |
| binAndReturnMergerFractions(mstar, nomerge, ...) | |
| binAndReturnMergerFractions2(mstar, nomerge, ...) | |
| binned_average(xdata, ydata, xbins, step) | Calculates a binned average from data |
| movingAverage(x, n[, type]) | compute an n period moving average, type is ‘simple’ | ‘exponential’ |
| percentile_bins(xdata, ydata, xmin, xmax[, ...]) | Computes median and 16 and 84 percentiles of y-data in bins in x. |
| rollingAverage(x) | Returns the average between the cells of a list. |


At the Colorado Dept. Of Education in Denver, training their emergency respones team members
We conducted 2 classes for the RNs, CNAs, LPNs and other care givers at Orchard Park. This is the second year for training at Orchard Park. We had a great day of training outdoors followed by an excellent barbecue at Schulhoff Tree & Lawn Care in Golden
Spent the morning with the awesome staff of At Home Healthcare. We have been providing them with CPR training for many years. The dental office of Dr. Brian A. Furgason D.D.S. in Lakewood. This was the second time Dr. Furgason asked Advanced CPR to provide him and his staff with CPR training. Great group of people, we had a good time.
In May we trained over 200 people in CPR & First Aid. Doctors, Nurses, Nannies, Dentists, Day Care providers, Camp Counselors, Foster Parents, Personal Trainers, Physical Therapists, CNAs, Scuba Divers, Coaches and people who just wanted to be prepared. We had groups up to 27 people, small groups of 3 & 4 and many individuals. We traveled to Golden, Lakewood and downtown Denver. We conducted many classes in our training center in Aurora individuals and groups.


| Reference Frames |
Table of ContentsReference Frames Abstract Purpose Intended Audience Using Frames Frame Functions in Mice Frame Transformation Functions Frame Information Functions Frames Supported in SPICE Kernels Needed For Computing Frame Transformations Creating a Frame Kernel Frame Classes Specifying a New Frame Guidelines for Frame Specification Selecting a Name Selecting a Frame ID Selecting the Class Selecting the Center Selecting a Class ID Frame IDs Reserved for Public Use Why have a Frame ID and a Class ID? Putting the Pieces Together Connecting an Object to its Body-fixed Frame The rest of the frame information Inertial Frames PCK Frames CK Frames SCLK and SPK ID codes TK Frames Defining a TK Frame Using a Matrix Defining a TK Frame Using Euler Angles Defining a TK Frame Using a SPICE-style Quaternion Gaining Flexibility via TK Frames Dynamic Frames Parameterized Dynamic Frame Families Notation Required Keywords for Parameterized Dynamic Frames Conditional Keywords for Parameterized Dynamic Frames Rotation State Freeze Epoch Two-Vector Frames Defining a Two-Vector Frame in a Frame Kernel Kernel Availability Specifying the Base Frame Specifying the Frame Family Specifying the Rotation state or Freeze Epoch Specifying the Angular Separation Tolerance Frame Axis Labels Vector Specifications Observer-Target Position Vectors Target Near point Vectors Observer-Target Velocity Vectors Constant Vectors Mean Equator and Equinox of Date Frames Defining a Mean Equator and Equinox of Date Frame in a Frame Kernel Specifying the Base Frame Specifying the Frame Family Specifying the Precession Model Specifying a Rotation State or Freeze Epoch True Equator and Equinox of Date Frames Defining a True Equator and Equinox of Date Frame in a Frame Kernel Specifying the Base Frame Specifying the Frame Family Specifying the Precession Model Specifying the Nutation Model Specifying a Rotation State or Freeze Epoch Mean Ecliptic and Equinox of Date Frames Defining a Mean Ecliptic and Equinox of Date Frame in a Frame Kernel Specifying the Base Frame Specifying the Frame Family Specifying the Precession Model Specifying the Mean Obliquity Model Specifying a Rotation State or Freeze Epoch Euler Frames Defining an Euler Frame in a Frame Kernel Specifying the Base Frame Specifying the Frame Family Specifying the Epoch Specifying the Euler Angles Dynamic Frame Implementation Considerations Introduction Simulated Recursion The Need for Recursion in the Mice Frame Subsystem Implementation of Limited Simulated Recursion Limits on Recursion in Frame Definitions Frame Derivative Accuracy Degenerate Geometry Efficiency Concerns Appendix. ``Built in'' Inertial Reference Frames Complete List of ``Built in'' Inertial Reference Frames Inertial Reference Frame References Low Level Inertial Reference Frame Functions Appendix. ``Built in'' PCK-Based IAU Body-Fixed Reference Frames Appendix. High Precision Earth Fixed Frames Appendix. Frame Identifiers Reserved for Earth Fixed Frames Appendix. Frame Definition Examples Inertial Frame PCK Frame CK Frames TK frame --- Alias TK frame --- Topographic TK frame --- Instrument Examples of Two-Vector Parameterized Dynamic Frames Geocentric Solar Ecliptic (GSE) Frame Geocentric Solar Magnetospheric (GSM) Frame Mercury Solar Equatorial (MSEQ) Frame Example: Nadir Frame for Mars Orbiting Spacecraft Example: Roll-Celestial Spacecraft Frame Examples of Mean Equator and Equinox of Date Frames Earth Mean Equator and Equinox of Date Frames Examples of True Equator and Equinox of Date Frames Example of a Mean Ecliptic and Equinox of Date Frame Example of an Euler Frame Reference Frames
Abstract
Purpose
Intended Audience
This document assumes you have some familiarity with SPICE concepts and terminology. If you are new to the SPICE system, or just a bit rusty with it, you should consider reviewing ``An Overview of the SPICE System'' and ``An Introduction to SPICE.'' Using FramesFrame Functions in Mice
Frame Transformation Functions
The two user-level interface functions that deal solely with frame transformations are cspice_sxform and cspice_pxform. cspice_sxform supports transformations of Cartesian state vectors (6 components) between reference frames while cspice_pxform supports transformations of Cartesian position vectors (3 components). cspice_pxform may be used when only position information is needed, or when the derivatives required for a state transformation are unavailable, for example when one frame is defined by a C-kernel that lacks angular velocity data. The calling sequences for these functions are
xform = cspice_sxform( from, to, et ) rotate = cspice_pxform( from, to, et )The output of cspice_sxform, `xform', is a 6 by 6 matrix used to transform state vectors relative to a reference frame, the name of which is specified by the `from' input argument, to states relative to another reference frame, the name of which is specified by the `to' input argument, at the epoch `et' (specified in seconds past J2000). The output of cspice_pxform, `rotate', is a 3 by 3 transformation matrix equivalent to the upper left 3x3 block of `xform'. This matrix transforms position as opposed to state vectors. Frame Information Functions
frname = cspice_frmnam( frcode ) frcode = cspice_namfrm( frname ) [ cent, clss, clssid, found ] = cspice_frinfo( code ) [ frcode, frname, found ] = cspice_cidfrm( cent ) [ frcode, frname, found ] = cspice_cnmfrm( cname )See the section ``Specifying a New Frame'' below for more information on frame specification parameters. Frames Supported in SPICE
A number of names are automatically recognized by the frame subsystem because the definitions for these frames are ``built into'' Mice software. Among these frames are:
cspice_furnsh( 'myframe.tf' )Note that the SPICE data loading mechanism detects and prohibits loading text kernel files containing lines terminated with EOL character(s) non-native to the platform on which the Toolkit was compiled. If a non-native EOL terminator is detected in the first 132 characters of a text kernel, the execution is stopped and an error message is displayed. This feature does not work with files that are smaller that 132 bytes or have the first line longer that 132 characters. Kernels Needed For Computing Frame Transformations
The ``built in'' inertial frames are the only frames the transformations between which can be computed without loading any SPICE kernels. Since the body-fixed frames are tied to the rotation of planets, satellites, asteroids, etc, the information about how the orientation of these frames is changing with respect to inertial frames is stored in SPICE PCK files. It is important to note that although the names of these frames are ``built in'' their relationship to inertial frames is not. This information must be ``loaded'' into the SPICE system from a PCK file. Without loading this information you cannot compute the transformation to or from a body-fixed frame. As the name suggests, the orientation of CK-based frames is computed using data provided in CK files and cannot be computed without loading these. In addition to the CKs, an SCLK kernel establishing time correlation for the on-board clock that is used to tag data in the CKs must be loaded to support time conversion between that clock and ephemeris time. Because the fixed offset frame definitions stored in text kernels provide all information needed to determine their orientation relative to the frame with respect to which they are defined, only the text kernel containing the definition need be loaded. Depending on the particular family to which a dynamic frame belongs, no additional data may be needed in order to compute its orientation, or one or more types of SPICE kernels, including SPKs, PCKs, CKs, and SCLK, may have to be loaded. Creating a Frame Kernel
You will also need to understand the concept of a frame class. Frame Classes
Specifying a New Frame
Frame Name : 'WALDO' Frame ID code : 1234567 (A number guaranteed to be suitable for private use) Frame Class : 3 (C-kernel) Frame Center : -10001 (Waldo Spacecraft ID code) Frame Class_id: -10000001 (ID code in C-kernel for Waldo)The frame kernel that specifies this frame is given below:
\begindata FRAME_WALDO = 1234567 FRAME_1234567_NAME = 'WALDO' FRAME_1234567_CLASS = 3 FRAME_1234567_CENTER = -10001 FRAME_1234567_CLASS_ID = -10000001 \begintext Guidelines for Frame SpecificationSelecting a Name
Selecting a Frame ID
If the class is CK, you may use the same ID as you use for the CLASS_ID. In the previous example, we selected the Frame ID to be 1234567. (Since our example frame above is of class 3, a CK frame, we would normally use the same number for the frame ID as we used for the class ID. However, in this example, we have chosen a different value to illustrate the connection between the frame ID and the variables needed to define the frame.) For TK frames, the frame and class IDs must be identical. For TK frames associated with an instrument, the instrument ID is used for both frame ID and class ID. For topocentric TK frames at tracking station sites, both frame ID and class ID are created by ``combining'' the ID of the body on which the station is located with the station number (for example frame and class ID 1399012 is used for ``DSS-12'', with the formula used to arrive at this ID being 1000000 + ``Earth ID''*1000 + ``station ID''.) For local level and surface fixed TK frames at a landing site, both frame ID and class ID are based on the ID of the lander (for example frame and class ID of -222999 would be the natural choice for the lander with ID -222.) If the frame is a PCK frame or a dynamic frame and you are working without consultation with NAIF, select an integer in the range from 1400000 to 2000000. Selecting the Class
Selecting the Center
Note that this center ID is used to look up the position of the frame origin when SPICE computes frame orientation adjusted for light time. Therefore, only centers for which supporting SPK data are expected to be available should be picked. It is usually an issue only for TK and CK frames associated with instruments because the positions of instruments are rarely available in SPKs. To get around the need to provide the instrument positions, it is appropriate to specify the ID of the spacecraft on which an instrument is mounted as the center of a TK or CK frame associated with it. Selecting a Class ID
If your frame is a PCK class frame the CLASS_ID is the ID code for the body for which rotation constants are provided in the text PCK file or the ID associated with the orientation data provided in the binary PCK file. If your frame is a CK class frame, the CLASS_ID is the ID code used in the C-kernel to describe the orientation of the spacecraft. If the frame is a TK frame, the class ID must match the frame ID. For both ID codes you should use a positive integer in the range from 1400000 to 2000000 (unless you are working in an official project capacity in which case you should ask NAIF to provide a CLASS_ID for you). In the example above, the CLASS_ID is the ID code for the C-kernel structure: -10000001. If the frame is a dynamic frame, the class ID must match the frame ID. Frame IDs Reserved for Public Use
Why have a Frame ID and a Class ID?
To support existing data products and allow extension of the SPICE system, NAIF needed to associate the old ID code with the new frame ID. The CLASS_ID fills this role. When the frame is identified, the ID code suitable for the frame class is located and passed onto the frame's class so that the initial portion of the frame transformation can be carried out. Putting the Pieces Together
FRAME_<name> = <ID code> FRAME_<ID code>_NAME = '<name>' FRAME_<ID code>_CLASS = <class> FRAME_<ID code>_CLASS_ID = <classid> FRAME_<ID code>_CENTER = The example we used for the frame 'WALDO' illustrates this.
\begindata FRAME_WALDO = 1234567 FRAME_1234567_NAME = 'WALDO' FRAME_1234567_CLASS = 3 FRAME_1234567_CENTER = -10001 FRAME_1234567_CLASS_ID = -10000001 \begintextOnce you've completed the frame specification you tell the SPICE system about the frame by ``loading'' the frame kernel that contains it. As with all text kernels, you load it via the routine cspice_furnsh. For example if the frame kernel containing your frame specification is contained in the file ``myframe.tf'' you load the kernel via the call
cspice_furnsh( 'myframe.tf' ) Connecting an Object to its Body-fixed Frame
OBJECT_<name or spk_id>_FRAME = '<frame name>'or
OBJECT_<name or spk_id>_FRAME = <frame ID code>You may use the ID codes for either the object, the frame or both. As example, four of the following assignments could serve to connect the Earth with the 'ITRF93' frame.
OBJECT_399_FRAME = 13000 OBJECT_399_FRAME = 'ITRF93' OBJECT_EARTH_FRAME = 13000 OBJECT_EARTH_FRAME = 'ITRF93'Note: if you use the name of either the object or frame, you must use upper case letters. Of these four means of specifying an object's body-fixed frame the second (OBJECT_399_FRAME = 'ITRF93') is the most robust. For the sun, the planets and their satellites the frame subsystem maintains a default connection between the object and its body-fixed frame ``built into'' SPICE. The complete list of ``built in'' body-fixed frames is provided in the ``built in PCK-Based IAU Body-Fixed Reference Frames'' appendix of this document. The rest of the frame information
Inertial Frames
NAIF recommends against creating inertial frame specifications. However, if you choose to do so anyway, you are done once you've defined the frame specification. (You may not be done explaining to your colleagues why you've decided to do this.) In the example cited earlier (EME2000) here's how you'd specify the frame.
\begindata FRAME_EME2000 = 2000000 FRAME_2000000_NAME = 'EME2000' FRAME_2000000_CLASS = 1 FRAME_2000000_CENTER = 0 FRAME_2000000_CLASS_ID = 1 \begintextEverything else about this frame is ``built into'' the SPICE system. PCK Frames
CK Frames
SCLK and SPK ID codes
CK_<ck_ID code>_SCLK = <ID code of SCLK> CK_<ck_ID code>_SPK = <SPK ID code>These variables are normally placed in either the SCLK kernel or in the frame specification kernel (FK). To illustrate how you would create a C-kernel frame, we shall suppose that we have a C-kernel for structure -100001 aboard the fictional spacecraft ``Waldo'' which has ID code -1001. Moreover we shall assume that the clock ID appropriate for this structure is -1002. Below is a frame specification together with the CK_..._SCLK and CK_..._SPK variable definitions for the 'WALDO' frame.
\begindata FRAME_WALDO = -100001 FRAME_-100001_NAME = 'WALDO' FRAME_-100001_CLASS = 3 FRAME_-100001_CLASS_ID = -100001 FRAME_-100001_CENTER = -1001 CK_-100001_SCLK = -1002 CK_-100001_SPK = -1001 \begintext TK Frames
FRAME_<name> = <ID code> FRAME_<ID code>_NAME = '<name>' FRAME_<ID code>_CLASS = 4 FRAME_<ID code>_CLASS_ID = <ID code> FRAME_<ID code>_CENTER = You need to supply information that indicates the frame, RELATIVE, from which the TK frame is offset. It is done using this kernel pool variable:
TKFRAME_<frame>_RELATIVE = '<name of relative frame>'where `frame' is the ID code or name you used in the frame specification. Because the rotation from the TK frame to the RELATIVE frame is fixed (time invariant) it can be specified in the FK along with the frame specification information described above. This rotation data can be provided in any of three ways:
V_relative = M * V_tkframe
TKFRAME_<frame>_SPEC.To use a matrix to define the rotation, use the assignment:
TKFRAME_<frame>_SPEC = 'MATRIX'To define the rotation via three Euler angles, use the assignment:
TKFRAME_<frame>_SPEC = 'ANGLES'To define the rotation via a SPICE-style quaternion, use the assignment:
TKFRAME_<frame>_SPEC = 'QUATERNION'Depending upon the value of the `SPEC' variable, you need to supply one of the following sets of kernel pool variables. Defining a TK Frame Using a Matrix
TKFRAME_<frame>_MATRIX = ( matrix_value(1,1), matrix_value(2,1), matrix_value(3,1), matrix_value(1,2), matrix_value(2,2), matrix_value(3,2), matrix_value(1,3), matrix_value(2,3), matrix_value(3,3) )For example, if the matrix defining your TK frame is
0.4 -0.6 0.0 0.6 0.4 0.0 0.0 0.0 1.0and the ID code you've selected for the frame is 1234567, then you would supply the following information in a text kernel.
TKFRAME_1234567_SPEC = 'MATRIX' TKFRAME_1234567_MATRIX = ( 0.4 0.6 0.0 -0.6 0.4 0.0 0.0 0.0 1.0 ) Defining a TK Frame Using Euler Angles
TKFRAME_<frame>_ANGLES = ( angle_1, angle_2, angle_3 ) TKFRAME_<frame>_AXES = ( axis_1, axis_2, axis_3 ) TKFRAME_<frame>_UNITS = 'units_of_angles'The units must be from the list given above. The axes must be chosen from the set of integers 1,2,3 where 1 stands for the x-axis, 2 for the y-axis, and 3 for the z-axis. If M is the matrix that converts vectors relative to the TK frame to the RELATIVE frame by left multiplication, then the angles and axes must satisfy the following relationship:
M = [angle_1] [angle_2] [angle_3] axis_1 axis_2 axis_3where the symbol
[ A ] istands for a rotation by the angle A about the i'th axis.
+- -+ | 1 0 0 | | 0 cos A sin A | = [ A ] | 0 -sin A cos A | 1 +- -+ +- -+ | cos A 0 -sin A | | 0 1 0 | = [ A ] | sin A 0 cos A | 2 +- -+ +- -+ | cos A sin A 0 | | -sin A cos A 0 | = [ A ] | 0 0 1 | 3 +- -+This method of definition is particularly well suited for defining topocentric frames on the surface of the Earth. For example, suppose you have an SPK (ephemeris) file that specifies the location of some surface point on the Earth, and that the SPK ID code of this point is 399100. Moreover suppose you have the geodetic co-latitude (COLAT) and longitude (LONG) measured in degrees for this point. (Note that the co-latitude is the complement of latitude: latitude + co-latitude = 90 degrees.) Given this information we can easily define a topocentric reference frame at the point such that the x-axis points north along the local meridian, the y-axis points west along the local latitude and the z-axis points up from the reference spheroid. The transformation from Earth body-fixed frame to topocentric frame is given by
BF2TP = [180] [COLAT] [LONG] 3 2 3Consequently the transformation from the topocentric frame to the body-fixed frame is given by
M = TP2BF = [-LONG] [-COLAT] [180] 3 2 3Let 1234567 be the ID code for the topocentric frame; let the name of this frame be 'MYTOPO'; and define this relative to the IAU frame for the Earth (one of the ``built in'' frames). The topocentric frame at the ephemeris point 399100 is specified as shown below:
\begindata FRAME_MYTOPO = 1234567 FRAME_1234567_NAME = 'MYTOPO' FRAME_1234567_CLASS = 4 FRAME_1234567_CLASS_ID = 1234567 FRAME_1234567_CENTER = 399100 TKFRAME_1234567_SPEC = 'ANGLES' TKFRAME_1234567_RELATIVE = 'IAU_EARTH' TKFRAME_1234567_ANGLES = ( <-long>, <-colat>, 180 ) TKFRAME_1234567_AXES = ( 3, 2, 3 ) TKFRAME_1234567_UNITS = 'DEGREES' \begintextAs we'll see a bit later, we can make a more flexible definition for this topocentric frame. Defining a TK Frame Using a SPICE-style Quaternion
TKFRAME_<frame>_Q = ( q_0, q_1, q_2, q_3 )where component zero is the so-called ``real'' component of the quaternion (the ``cosine'' component of the quaternion). The last 3 components (components 1 through 3) are the ``axis'' components of the quaternion -- the i, j, and k components respectively of the quaternion. The quaternion must be a unit quaternion.
2 2 2 2 (q_0) + (q_1) + (q_2) + (q_3) = 1A more detailed discussion of quaternions is available in the reference document ``Rotations Required Reading'' (rotation.req), and in a ``Quaternions White Paper'' available from NAIF. Gaining Flexibility via TK Frames
\begindata FRAME_MOONFIXED = 3010000 FRAME_3010000_NAME = 'MOONFIXED' FRAME_3010000_CLASS = 4 FRAME_3010000_CLASS_ID = 3010000 FRAME_3010000_CENTER = 301 TKFRAME_3010000_SPEC = 'MATRIX' TKFRAME_3010000_RELATIVE = '<name of base frame>' TKFRAME_3010000_MATRIX = ( 1, 0, 0, 0, 1, 0, 0, 0, 1 ) \begintextBy editing this definition you can make the MOONFIXED frame be the IAU MOON frame or some other model if one is available. Or you can create several such definitions and, at run-time, load the file that best fits your current environment. Using this indirect method of defining the various frames for which more than one orientation model may be available, you can avoid limiting how various kernels can be used. Dynamic Frames
A ``parameterized dynamic frame'' is a dynamic frame defined by a formula implemented in Mice code and having user-selectable parameters set via a frame kernel. The formula defining a dynamic frame may rely on data from other SPICE kernels, for example state vectors provided by SPK files or rotation matrices from C-kernels or PCK files. An example of a parameterized dynamic frame is a nadir-pointing reference frame for a spacecraft orbiting a planet, where the spacecraft's nadir direction and velocity vector define the frame. Using a frame kernel, a Mice user may specify the planet and spacecraft, the relationship between the nadir and velocity vectors and the frame's axes, and a small set of additional parameters required to define the frame. Currently parameterized dynamic frames are the only type of dynamic frame supported by Mice. Other types of dynamic frames, such as frames defined by complete formulas (as opposed to parameters) provided in frame kernels, may be implemented in future versions of Mice. Below we'll discuss the various types of supported dynamic frames, how to create frame kernels that define dynamic frames, and dynamic frame implementation considerations. The appendix ``Frame Definition Examples'' contains frame definition templates for a variety of popular dynamic frames. Parameterized Dynamic Frame Families
Notation
C = A x BDouble vertical bars bracketing the name of a vector indicate the norm of the vector:
||A||Throughout this discussion we'll use text enclosed in angle brackets to indicate values to be filled in by the creator of a frame kernel. Examples are:
Token Replacement Value ------------- ----------------------------------------- <vec_ID> 'PRI' or 'SEC' [See discussion of two-vector frames below.] <frame_name> SPICE frame name, .e.g. 'J2000' <frame_ID> Integer frame ID code <observer_ID> NAIF integer ID for the observing body <aberration correction> String indicating aberration correction, e.g.: 'NONE', 'LT', 'XLT', 'LT+S' Required Keywords for Parameterized Dynamic Frames
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = <center_ID> FRAME_<frame_ID>_RELATIVE = <base_frame_name> FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = <frame_family>These first five of the assignments are common to all Mice frame definitions; the class code 5 indicates that the frame is dynamic. See the section ``Guidelines for Frame Specification'' in the chapter ``Creating a Frame Kernel'' above for a detailed discussion of these assignments. The sixth assignment (for keyword FRAME_<frame_ID>_RELATIVE) is the ``base frame'' specification; this indicates the frame the transformation defined by the frame kernel ``maps to'': starting with an epoch ET and a state vector S specified relative to the defined frame
<frame name>the frame definition determines the 6x6 state transformation matrix XFORM such that the product
XFORM * Syields the equivalent state specified relative to the base frame at ET. The seventh assignment (for keyword FRAME_<frame_ID>_DEF_STYLE) is used to simplify future implementation of other dynamic frame definition styles. Only the value
'PARAMETERIZED'is currently supported. The last assignment indicates the frame family. The possible values are
'TWO-VECTOR' 'MEAN_EQUATOR_AND_EQUINOX_OF_DATE' 'TRUE_EQUATOR_AND_EQUINOX_OF_DATE' 'MEAN_ECLIPTIC_AND_EQUINOX_OF_DATE' 'EULER'Additional, required frame kernel assignments are a function of the family to which a dynamic frame belongs. These are discussed below. Conditional Keywords for Parameterized Dynamic FramesRotation State
When a parameterized dynamic frame is specified as ``inertial,'' the derivative with respect to time of the transformation between the frame and any inertial frame, for example the J2000 frame, is zero. The rotation between the frame and any inertial frame is still treated as time-dependent. For such a frame F, the call
xform = cspice_sxform( 'F', 'J2000', t )yields a 6x6 state transformation matrix `xform' having the structure
+-----+-----+ | R(t)| 0 | +-----+-----+ | 0 | R(t)| +-----+-----+where R(t) is the 3x3 rotation matrix that transforms vectors from frame F to the J2000 frame at time `t'. By contrast, when the rotation state of F is ``rotating,'' `xform' has the structure
+-----+-----+ | R(t)| 0 | +-----+-----+ |dR/dt| R(t)| +-----+-----+So, when the rotation state of frame F is ``inertial,'' velocities are transformed from frame F to J2000 by left-multiplication by R(t); the time derivative of the rotation from F to J2000 is simply ignored. Normally the inertial rotation state makes sense only for slowly rotating frames such as the earth mean equator and equinox of date frame. A parameterized dynamic frame's rotation state is specified via the assignment
FRAME_<frame_ID>_ROTATION_STATE = <state>where
<state>is one of
'ROTATING' 'INERTIAL'For frames belonging to the parameterized dynamic frame families
'MEAN_EQUATOR_AND_EQUINOX_OF_DATE' 'TRUE_EQUATOR_AND_EQUINOX_OF_DATE' 'MEAN_ECLIPTIC_AND_EQUINOX_OF_DATE'either the rotation state must be specified, or the frame must be frozen (see ``Frozen Frames'' below). For two-vector and Euler frames, the rotation state specification is optional; these frames are considered to be rotating by default. When the rotation state of a parameterized frame is specified, the frame cannot be frozen; these options are mutually exclusive. Freeze Epoch
A frozen frame whose base frame is time-varying is still time-varying: it is the relationship between the frozen frame and the base frame that is time-independent. A frame is declared frozen by specifying a ``freeze epoch.'' This is done via the assignment:
FRAME_<frame_ID>_FREEZE_EPOCH = <time_spec>where
<time_spec>is a TDB calendar date whose format conforms to the SPICE text kernel date format specification. These dates
@
@YYYY-MON-DD/HR:MN.SEC.###Literal examples include
@7-MAR-2005 @March-7-2005-3:10:39.221 @2005-MAR-07/3:10:39.221Note that unlike time strings supported by the Mice function cspice_str2et, time system tokens such as
UTC TDT TDBare not supported; times are always assumed to be TDB. For frames belonging to the parameterized dynamic frame families
'MEAN_EQUATOR_AND_EQUINOX_OF_DATE' 'TRUE_EQUATOR_AND_EQUINOX_OF_DATE' 'MEAN_ECLIPTIC_AND_EQUINOX_OF_DATE'either the frame must be frozen or the rotation state must be specified, (see ``Rotation State'' above). For two-vector and Euler frames, the freeze epoch specification is optional; these frames are considered to be time-varying relative to their base frames by default. When a parameterized frame is frozen, the rotation state of the frame cannot be specified; these options are mutually exclusive. Two-Vector Frames
In a two-vector frame definition, one defining vector is parallel to a specified axis of the reference frame; this vector is called the ``primary vector.'' The other vector, called the ``secondary vector,'' defines another axis: the component of the secondary vector orthogonal to the primary vector is parallel to a specified axis of the reference frame. The secondary vector itself need not be, and typically is not, aligned with an axis of the defined frame. Below, we'll call the primary and secondary defining vectors PRI and SEC, and we'll name the axes of the right-handed frame X, Y, and Z. The unit +Z vector is the cross product of the unit +X and +Y vector. In a two-vector frame definition, the vectors PRI and SEC are specified geometrically; for example, PRI could be the position of the earth relative to a spacecraft, and SEC could be defined by the right ascension and declination of a given star in a specified reference frame. In a frame kernel, the vectors PRI and SEC are associated with two members of the set of unit vectors
{ X, -X, Y, -Y, Z, -Z }An example: in this case PRI is associated with -Z and SEC is associated with +X. SEC itself is not parallel to the X axis, but the component of SEC orthogonal to PRI points in the +X direction. The diagram below shows the relationship between PRI, SEC, X, Y, and Z:
Component of SEC orthogonal to PRI | | ^ v | <-----+--+ \ | | \ +--+ \ | SEC \ | +Z = - PRI / ||PRI|| \ | \ | \ +--+ \| | +X = Y x Z <---------+---+--+ / /| +---/ | /| / / |/| / + | -Z = PRI / ||PRI|| / | / | v v PRI Z x SEC +Y = ----------- ||Z x SEC|| = Z x XBy defining PRI and SEC we can create a concrete frame definition. Continuing the above example, we can define a nadir-pointing frame for the Mars Global Surveyor (MGS) spacecraft as follows:
PRI = Vector from MGS to nearest point on Mars reference ellipsoid Z = -PRI / ||PRI|| SEC = Inertially referenced velocity of MGS relative to Mars Y = Z x SEC / ||Z x SEC|| X = Y x ZFor this nadir-pointing frame, -Z is the nadir direction, X points roughly in the direction of the inertially referenced spacecraft velocity, and Y is aligned with the orbital angular velocity vector. By converting the above definition into the frame kernel ``keyword=value'' format, we can make the definition usable by the Mice system. Above, for brevity, we've glossed over a few aspects of the vector definitions. Below we'll discuss in detail all of the elements of two-vector frame specifications. Defining a Two-Vector Frame in a Frame KernelKernel Availability
We'll also call a frame transformation between frames F1 and F2 ``computable'' if both frames F1 and F2 are computable and kernels have been loaded sufficient to enable computation of the transformation between F1 and F2. For example, the transformation between the J2000 and IAU_TITAN frames is computable once a PCK containing rotational elements for TITAN has been loaded. Specifying the Base Frame
For a two-vector frame, the base frame may be any frame F_BASE such that the transformation between F_BASE and the J2000 reference frame is computable at the time the two-vector frame definition is referenced. Normally for two-vector frames the base frame should be set to 'J2000'; this choice yields optimal run-time efficiency. The assignment is made as follows.
FRAME_<frame_ID>_RELATIVE = 'J2000'Base frame specifications are part of the two-vector frame definition because the base frame can be used to control how Mice chains together two-vector frames with other frames. However, from a mathematical point of view, two-vector frames are fully defined without reference to a base frame. For example, suppose the two-vector frame F1 is defined by the earth-moon position vector and the earth-sun position vector, and the base frame for F1 is IAU_EARTH. Suppose that the two-vector frame F2 is defined by the same vectors and that the base frame of F2 is J2000. Then, ignoring small round-off errors, the transformation between F1 and F2 is the identity transformation. Base frames should not be confused with other frames occurring in two-vector frame definitions: constant vectors and velocity vectors have associated frames which are also specified by keyword assignments. See the discussion below under the heading ``Constant Vectors'' and ``Velocity Vectors'' for details. Specifying the Frame Family
FRAME_<frame_ID>_FAMILY = 'TWO-VECTOR'Further assignments (discussed below) define the primary and secondary vectors and relate these vectors to the frame's axes. Specifying the Rotation state or Freeze Epoch
Specifying the Angular Separation Tolerance
FRAME_<frame_ID>_ANGLE_SEP_TOL = <tolerance>where <tolerance> is the separation limit in radians. If the angular separation of the defining vectors differs from zero or pi radians by less than the specified tolerance, an error will be signaled at run time. When a two-vector frame definition omits specification of an angular separation tolerance, Mice uses a default value of one milliradian. Frame Axis Labels
FRAME_<frame_ID>_PRI_AXIS = Here
may be any of
{ 'X', '-X', 'Y', '-Y', 'Z', '-Z' }Blanks and case in the label are not significant. Unsigned axis designations are treated as positive; optionally '+' signs may be used to prefix positive axis designations. The primary vector is aligned with the indicated axis and has the sense indicated by the implied or explicit sign. The secondary defining vector is associated with a frame axis via the assignment
FRAME_<frame_ID>_SEC_AXIS = where the axis labels are as above. The assignment means that the component of the secondary vector orthogonal to the primary vector is aligned with the indicated axis and has the sense indicated by the implied or explicit sign. Vector Specifications
All keywords comprising the primary vector definition start with the prefix
FRAME_<frame_ID>_PRI_All keywords for the second defining vector are prefixed by
FRAME_<frame_ID>_SEC_Here <frame_ID> is the integer ID code for the frame being defined. Both the primary and secondary vectors are specified using the sets of keywords described below. Observer-Target Position Vectors
The observer and target are specified by name or ID code. The aberration correction may be any value accepted by cspice_spkezr. The frame kernel assignments used to define an observer-target position vector are:
FRAME_<frame_ID>_<vec_ID>_VECTOR_DEF = 'OBSERVER_TARGET_POSITION' FRAME_<frame_ID>_<vec_ID>_OBSERVER = <observer name or ID code> FRAME_<frame_ID>_<vec_ID>_TARGET = <target name or ID code> FRAME_<frame_ID>_<vec_ID>_ABCORR = <aberration correction>where <vec_ID> may be either PRI or SEC, and <frame_ID> is the ID code of the frame established by the generic assignments described above. In order for a two-vector frame using a position vector as part of its definition to be computable, kernel data must be loaded that enable computation of the specified position vector with respect to the J2000 frame. For an example of a two-vector frame definition using an observer-target position vector, see the subsection titled ``Geocentric Solar Ecliptic (GSE) Frame'' in the appendix ``Frame Definition Examples.'' Target Near point Vectors
Target near point vectors are defined by an observer, a target, an aberration correction, a frame, and an epoch. As with position vectors, the frame and epoch are not specified in the frame kernel. The observer and target are specified by name or ID code. Aberration corrections may be any supported by the Mice function cspice_subpt. Light time corrections are applied both to the observer- target center vector and to the rotation of the target body. The stellar aberration correction, if specified, is applied to the observer-target center vector. The frame kernel assignments used to define a target near point position vector are:
FRAME_<frame_ID>_<vec_ID>_VECTOR_DEF = 'TARGET_NEAR_POINT' FRAME_<frame_ID>_<vec_ID>_OBSERVER = <observer name or ID code> FRAME_<frame_ID>_<vec_ID>_TARGET = <target name or ID code> FRAME_<frame_ID>_<vec_ID>_ABCORR = <aberration correction>In order for a two-vector frame using a target near point vector as part of its definition to be computable, kernel data must be loaded that enable computation of the target near point vector with respect to the J2000 frame. For an example of a two-vector frame definition using a target near point vector, see the subsection titled ``Nadir Frame for Mars Orbiting Spacecraft'' in the appendix ``Frame Definition Examples.'' Observer-Target Velocity Vectors
When the velocity frame is non-inertial and aberration corrections are used, the epoch at which the velocity frame is evaluated will be adjusted by the one-way light time between the observer and the frame's center---just as is done by cspice_spkezr (see the header of that function for details). The reason the velocity frame specification is crucial is that, (unlike rotations) state transformations between non-inertial frames don't preserve geometric properties of velocity vectors. Example: compare the specific angular momentum vector of a geosynchronous satellite (obtained by taking the cross product of the satellite's geocentric position and velocity vectors) in both the J2000 frame and in the earth body-fixed frame. In the latter frame, the specific angular momentum is zero. A valid two-vector frame could be defined using the satellite's position and velocity in the J2000 frame, while using the position and velocity in the earth body-fixed frame gives rise to a degenerate case for which the two-vector frame is undefined. The observer and target defining the velocity vector are specified by name or ID code. The aberration correction may be any value accepted by cspice_spkezr. The velocity frame may be any computable by Mice, including a dynamic frame, as long as the transformation between the velocity frame and the J2000 frame doesn't require multiple levels of simulated recursion (see the discussion of recursion in the chapter ``Dynamic Frame Implementation Considerations'' below for details). The frame kernel assignments used to define an observer-target velocity vector are:
FRAME_<frame_ID>_<vec_ID>_VECTOR_DEF = 'OBSERVER_TARGET_VELOCITY' FRAME_<frame_ID>_<vec_ID>_OBSERVER = <observer name or ID code> FRAME_<frame_ID>_<vec_ID>_TARGET = <target name or ID code> FRAME_<frame_ID>_<vec_ID>_FRAME = <frame_name> FRAME_<frame_ID>_<vec_ID>_ABCORR = <aberration correction>In order for a two-vector frame using a velocity vector as part of its definition to be computable, kernel data must be loaded that enable computation of the velocity vector with respect to both the velocity frame and the J2000 frame. For an example of a two-vector frame definition using an observer-target velocity vector, see the subsection titled ``Geocentric Solar Ecliptic (GSE) Frame'' in the appendix ``Frame Definition Examples.'' Constant Vectors
The coordinates of a constant vector may be specified in any of the rectangular, latitudinal, or RA/DEC (right ascension and declination) systems. If the coordinates are angular, the associated angular units must be specified; any angular units supported by the Mice function cspice_convrt may be used. All constant vectors require the frame kernel assignments
FRAME_<frame_ID>_<vec_ID>_VECTOR_DEF = 'CONSTANT' FRAME_<frame_ID>_<vec_ID>_SPEC = <coordinate_system> FRAME_<frame_ID>_<vec_ID>_FRAME = <frame_name>where <coordinate_system> is one of
'RECTANGULAR' 'LATITUDINAL' 'RA/DEC'and the frame is any computable by Mice, including a dynamic frame, as long as the transformation between the constant vector's frame and the J2000 frame doesn't require multiple levels of simulated recursion (see the discussion of recursion in the chapter ``Dynamic Frame Implementation Considerations'' below for details). When the coordinate system is rectangular, the vector is specified by the frame kernel assignment
FRAME_<frame_ID>_<vec_ID>_SPEC = 'RECTANGULAR' FRAME_<frame_ID>_<vec_ID>_VECTOR = ( <X component>, <Y component>, <Z component> )When the coordinate system is latitudinal, the vector is specified by the frame kernel assignments
FRAME_<frame_ID>_<vec_ID>_SPEC = 'LATITUDINAL' FRAME_<frame_ID>_<vec_ID>_UNITS = <angular_units> FRAME_<frame_ID>_<vec_ID>_LONGITUDE = <longitude> FRAME_<frame_ID>_<vec_ID>_LATITUDE = <latitude>where <angular_units> designates one of the units supported by the Mice function cspice_convrt. The set of supported units includes
'RADIANS' 'DEGREES' 'ARCSECONDS'When the coordinate system is RA/DEC, the vector is specified by the frame kernel assignments
FRAME_<frame_ID>_<vec_ID>_SPEC = 'RA/DEC' FRAME_<frame_ID>_<vec_ID>_UNITS = <angular_units> FRAME_<frame_ID>_<vec_ID>_RA = <RA> FRAME_<frame_ID>_<vec_ID>_DEC = <DEC>where <angular_units> are as described above. Aberration corrections are optional for constant vectors. The set of available corrections is unique to this application: either light time correction or stellar aberration correction may be applied, but both cannot be applied together. Light time corrections adjust the orientation of the constant vector's frame for the one-way light time between the center of the frame and a specified observer. The application to the frame of light time correction is identical to that performed by the Mice function cspice_spkezr when it is asked to compute a light-time corrected state relative to a non-inertial reference frame. Supported light time corrections are any of those supported by cspice_spkezr that don't include stellar aberration correction. The user may also correct the constant vector for stellar aberration; this correction is a function of the constant vector and the velocity of an observer relative to the solar system barycenter. A typical application would be to correct an inertially referenced star direction vector for the stellar aberration induced by motion of an observing spacecraft. The supported stellar aberration corrections are
'S' {correct for stellar aberration, reception case} 'XS' {correct for stellar aberration, transmission case}In the application above, one would correct the apparent observer-star direction by selecting the 'S' option. See the discussion in the header of the Mice function cspice_spkezr for a description of the ``reception'' and ``transmission'' aberration correction cases. When aberration corrections are desired, the observer and the correction are specified by the frame kernel assignments
FRAME_<frame_ID>_<vec_ID>_OBSERVER = <observer name or ID code> FRAME_<frame_ID>_<vec_ID>_ABCORR = <aberration correction>In order for a two-vector frame using a constant vector as part of its definition to be computable, kernel data must be loaded that enable computation of the specified vector with respect to both the constant vector's frame and the J2000 frame. For examples of two-vector frame definitions using constant vectors, see the subsections titled ``Geocentric Solar Magnetospheric (GSM) Frame'' and ``Mercury Solar Equatorial (MSEQ) Frame'' in the appendix ``Frame Definition Examples.'' Mean Equator and Equinox of Date Frames
The mathematical model for a mean equator and equinox of date frame is typically called a ``precession model''; Mice adopts this usage. The Mice frame subsystem supports mean equator and equinox of date frames via precession models built into Mice. In principle, for any body, a frame kernel definition for a mean equator and equinox of date frame identifies which precession model to use for that body. Currently Mice supports only one precession model: the 1976 IAU precession model for the earth. Defining a Mean Equator and Equinox of Date Frame in a Frame KernelSpecifying the Base Frame
FRAME_<frame_ID>_RELATIVE = 'J2000' Specifying the Frame Family
FRAME_<frame_ID>_FAMILY = 'MEAN_EQUATOR_AND_EQUINOX_OF_DATE' Specifying the Precession Model
FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' Specifying a Rotation State or Freeze Epoch
Users can instruct the Mice frame subsystem to treat a mean equator and equinox of date frame as either inertial or rotating by making a ``rotation state'' assignment. Users can also direct the frame subsystem to treat a mean equator and equinox of date frame as though it were ``frozen'' at a specified epoch. See the section above titled ``Conditional Keywords for Parameterized Dynamic Frames'' for instructions on how to make these assignments. Definitions of mean equator and equinox of date frames require either, but not both, the rotation state or a freeze epoch to be specified. For examples of Mean Equator and Equinox of Date frame definitions, see the subsection titled ``Earth Mean Equator and Equinox of Date Frames'' in the appendix ``Frame Definition Examples.'' True Equator and Equinox of Date Frames
Defining a True Equator and Equinox of Date Frame in a Frame Kernel
Specifying the Base Frame
FRAME_<frame_ID>_RELATIVE = 'J2000' Specifying the Frame Family
FRAME_<frame_ID>_FAMILY = 'TRUE_EQUATOR_AND_EQUINOX_OF_DATE' Specifying the Precession Model
The 1976 IAU precession model is ``selected'' via the assignment:
FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' Specifying the Nutation Model
FRAME_<frame_ID>_NUT_MODEL = <nutation_model>Currently the only available nutation model is the 1980 IAU nutation model for the earth. An assignment specifying this model has the form:
FRAME_<frame_ID>_NUT_MODEL = 'EARTH_IAU_1980' Specifying a Rotation State or Freeze Epoch
Users can instruct the Mice frame subsystem to treat a true equator and equinox of date frame as either inertial or rotating by making a ``rotation state'' assignment. Users can also direct the frame subsystem to treat a true equator and equinox of date frame as though it were ``frozen'' at a specified epoch. See the section above titled ``Conditional Keywords for Parameterized Dynamic Frames'' for instructions on how to make these assignments. Definitions of true equator and equinox of date frames require either, but not both, the rotation state or a freeze epoch to be specified. For examples of True Equator and Equinox of Date frame definitions, see the subsection titled ``Earth True Equator and Equinox of Date Frames'' in the appendix ``Frame Definition Examples.'' Mean Ecliptic and Equinox of Date Frames
The term ``mean equator'' indicates that orientation of a body's equatorial plane is modeled accounting for precession. The ``mean equinox'' is the intersection of the body's mean orbital plane with the mean equatorial plane. The X-axis of such a frame is aligned with the cross product of the north-pointing vectors normal to the body's mean equator and mean orbital plane of date. The Z-axis is aligned with the second of these normal vectors. The Y axis is the cross product of the Z and X axes. The term ``of date'' means that these axes are evaluated at a specified epoch. Defining a Mean Ecliptic and Equinox of Date Frame in a Frame Kernel
Specifying the Base Frame
FRAME_<frame_ID>_RELATIVE = 'J2000' Specifying the Frame Family
FRAME_<frame_ID>_FAMILY = 'MEAN_ECLIPTIC_AND_EQUINOX_OF_DATE' Specifying the Precession Model
The 1976 IAU precession model is ``selected'' via the assignment:
FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' Specifying the Mean Obliquity Model
FRAME_<frame_ID>_OBLIQ_MODEL = <obliquity_model>Currently the only available mean obliquity model is the 1980 IAU obliquity model for the earth. An assignment specifying this model has the form:
FRAME_<frame_ID>_OBLIQ_MODEL = 'EARTH_IAU_1980' Specifying a Rotation State or Freeze Epoch
Users can instruct the Mice frame subsystem to treat a mean ecliptic and equinox of date frame as either inertial or rotating by making a ``rotation state'' assignment. Users can also direct the frame subsystem to treat a mean ecliptic and equinox of date frame as though it were ``frozen'' at a specified epoch. See the section above titled ``Conditional Keywords for Parameterized Dynamic Frames'' for instructions on how to make these assignments. Definitions of mean ecliptic and equinox of date frames require either, but not both, the rotation state or a freeze epoch to be specified. For examples of Mean Ecliptic and Equinox of Date frame definitions, see the subsection titled ``Earth Mean Ecliptic and Equinox of Date Frames'' in the appendix ``Frame Definition Examples.'' Euler Frames
The rotation defined by the Euler angles maps position vectors via left multiplication from the defined Euler reference frame to the base frame:
V = r(t) * V base_frame Euler_frameThis rotation can be considered to be a time-dependent matrix
r(t)where r(t) represents the composition of the rotations defined by the input angle-axis pairs. Naming the axis indices and angles of the Euler angle sequence
axindx_i, angle_i, i = 1, 2, 3r(t) is
r(t) = [ angle_1(t) ] [ angle_2(t) ] [ angle_3(t) ] axindx_1 axindx_2 axindx_3The axis indices axindx_i, for i = 1, 2, 3, are in the set { 1, 2, 3 }; axindx_2 cannot equal axindx_1 or axindx_3. For example, we could have
axindx_1 = 3 axindx_2 = 1 axindx_3 = 3Here the notation
[ A ] jstands for a frame rotation by the angle A radians about the jth axis of a right-handed frame, where we assign the axes {X, Y, Z} the indices {1, 2, 3} respectively:
+- -+ | 1 0 0 | | 0 cos A sin A | = [ A ] | 0 -sin A cos A | 1 +- -+ +- -+ | cos A 0 -sin A | | 0 1 0 | = [ A ] | sin A 0 cos A | 2 +- -+ +- -+ | cos A sin A 0 | | -sin A cos A 0 | = [ A ] | 0 0 1 | 3 +- -+The base frame can be constructed from the Euler frame via a sequence of Euler angle rotations as follows:
The rotation angles are defined as follows: letting t0 represent the reference epoch, and letting
c , i = 1, 2, 3; j = 0, ... , ni i,jbe the polynomial coefficients for the ith angle, we have
n1 angle_1(t) = c + c * (t-t0) + ... + c * (t-t0) 1,0 1,1 1,n1 n2 angle_2(t) = c + c * (t-t0) + ... + c * (t-t0) 2,0 2,1 2,n2 n3 angle_3(t) = c + c * (t-t0) + ... + c * (t-t0) 3,0 3,1 3,n3See the Rotation Required Reading, rotation.req, or the header of the Mice function cspice_eul2m for details concerning definition of rotations via Euler angles. Note however that the referenced document and source code use a different convention for labeling Euler angles and their rotation axes: here the elements of the rotation sequence are numbered left to right; in those documents the order is that in which rotations are performed, namely right to left. Defining an Euler Frame in a Frame KernelSpecifying the Base Frame
FRAME_<frame_ID>_RELATIVE = '<frame_name>' Specifying the Frame Family
FRAME_<frame_ID>_FAMILY = 'EULER' Specifying the Epoch
FRAME_<frame_ID>_EPOCH = @YYYY-MON-DD/HR:MN.SEC.###A concrete example is:
FRAME_<frame_ID>_EPOCH = @2000-JAN-1/12:00:00.000The calendar time string is assumed to represent a TDB epoch. See the discussion in the section ``Freeze Epoch'' above or the Kernel Required Reading, kernel.req, for further information. Specifying the Euler Angles
FRAME_<frame_ID>_AXES = ( <index of axis 1> <index of axis 2> <index of axis 3> )The axis indices must be taken from the set
{ 1, 2, 3 }and the middle value must differ from its neighbors. The first integer listed is the axis index for angle 1, the second for angle 2, and the last for angle 3, where the role of the angles is as shown in the equation for r(t) above. Let n1, n2, and n3 represent the maximum degrees of the polynomials for angles 1, 2, and 3 respectively. Then the polynomial coefficients are defined by the assignments
FRAME_<frame_ID>_ANGLE_1_COEFFS = ( <order 0 coefficient> <order 1 coefficient> ... <order n1 coefficient> ) FRAME_<frame_ID>_ANGLE_2_COEFFS = ( <order 0 coefficient> <order 1 coefficient> ... <order n2 coefficient> ) FRAME_<frame_ID>_ANGLE_3_COEFFS = ( <order 0 coefficient> <order 1 coefficient> ... <order n3 coefficient> )Angular units are specified by the frame kernel assignment
FRAME_<frame_ID>_UNITS = <angular_units>where <angular_units> designates one of the units supported by the Mice function cspice_convrt. The set of supported units includes
'RADIANS' 'DEGREES' 'ARCSECONDS'For an example of an Euler frame definition, see the subsection titled ``Euler Frames'' in the appendix ``Frame Definition Examples.'' Dynamic Frame Implementation ConsiderationsIntroduction
Simulated RecursionThe Need for Recursion in the Mice Frame Subsystem
A -> BA function R_0 is ``recursive'' if it calls itself
R_0 -> R_0or if some sequence of calls initiated in the function R_0 results in a call to R_0:
R_0 -> R_1-> ... -> R_0ANSI standard Fortran 77 doesn't permit recursive calls. However, the implementation of two-vector frames requires sequences of calls that at face value are recursive. For example, to look up a state vector in the GSE frame (see the appendix ``Frame Definition Examples''), the function SPKEZ must initiate the sequence of calls (ellipses indicate omitted portions of the call graph)
SPKEZ -> ... -> FRMGET -> ... -> SPKEZ -> ... -> FRMGETBoth SPKEZ and FRMGET are called recursively in this graph. This issue affects not only SPICELIB but CSPICE and Icy as well because these products rely on the SPICELIB (Fortran) implementation of the frame subsystem. Implementation of Limited Simulated Recursion
SPKEZ -> ... -> FRMGET -> ... -> SPKEZ -> ... -> FRMGETis implemented in (valid) ANSI standard Fortran 77 using the call graph
SPKEZ -> ... -> FRMGET -> ... -> ZZSPKEZ0 -> ... -> ZZFRMGT0To a limited extent, two levels of simulated recursion are supported in the frame subsystem, so call graphs of the form
SPKEZ -> ... -> FRMGET -> ... -> ZZSPKEZ0 -> ... -> ZZFRMGT0 -> ... -> ZZSPKEZ1 -> ... -> ZZFRMGT1are possible. For brevity, when we refer to recursion in the following discussion, we'll omit the qualifier ``simulated.'' Limits on Recursion in Frame Definitions
[ state, ltime ] = cspice_spkezr( moon, et, 'GSE', ... 'NONE', 'EARTH' ) xform = cspice_sxform( 'GSE', 'J2000', et )both cause the GSE parameterized dynamic frame to be evaluated at ET. When the definition of a parameterized dynamic frame F1 refers to a second frame F2 as
If F2 is not dynamic but its evaluation requires evaluation of a dynamic frame F3, the same restrictions apply to F3. When a dynamic frame is used as a base frame in either an SPK or CK segment, evaluation of data from that segment may result in a call to the dynamic frame subsystem. That call may result in lookup of another segment whose base frame is dynamic, and so on: the original kernel lookup could easily exhaust the dynamic frame subsystem's ability to handle recursive calls. Clearly use of dynamic frames in SPK and CK files requires caution. However, there are some ``reasonable'' applications that call for dynamic base frames in kernels, for example: representing ephemerides of earth orbiters expressed relative to the earth true equator and equinox of date frame. Frame Derivative Accuracy
Degenerate Geometry
Because two-vector frame definitions may be perfectly valid for some epochs and yield degenerate geometry for others, testing can easily fail to reveal problems with these definitions. Careful frame design is the best defense. As a backup measure, setting the angular separation tolerance in two-vector frame definitions can enable the frame subsystem to diagnose at run time degenerate or near-degenerate geometry. See the section ``Specifying the Angular Separation Tolerance'' above for details. Efficiency Concerns
To minimize the performance degradation imposed by recursion, avoid unnecessary references to dynamic frames in frame definitions. When possible, use J2000 or another inertial frame as the base frame, or as the frame relative to which constant or velocity vectors are defined. When it is not possible to use an inertial frame, prefer non-dynamic, non-inertial frames to dynamic frames. Appendix. ``Built in'' Inertial Reference FramesComplete List of ``Built in'' Inertial Reference Frames
ID Name Description ----- -------- ------------------------------------------- 1 J2000 Earth mean equator, dynamical equinox of J2000. The root reference frame for SPICE. 2 B1950 Earth mean equator, dynamical equinox of B1950. The B1950 reference frame is obtained by precessing the J2000 frame backwards from Julian year 2000 to Besselian year 1950, using the 1976 IAU precession model. The rotation from B1950 to J2000 is [ -z ] [ theta ] [ -zeta ] 3 2 3 The values for z, theta, and zeta are taken directly from formulas given in table 5 of [5]. z = 1153.04066200330" theta = -1002.26108439117" zeta = 1152.84248596724" 3 FK4 Fundamental Catalog (4). The FK4 reference frame is derived from the B1950 frame by applying the equinox offset determined by Fricke. [ 0.525" ] 3 4 DE-118 JPL Developmental Ephemeris (118). The DE-118 reference frame is nearly identical to the FK4 frame. It is also derived from the B1950 frame. Only the offset is different [ 0.53155" ] 3 In [2], Standish uses two separate rotations, [ 0.00073" ] P [ 0.5316" ] 3 3 (where P is the precession matrix used above to define the B1950 frame). The major effect of the second rotation is to correct for truncating the magnitude of the first rotation. At his suggestion, we will use the untruncated value, and stick to a single rotation. Most of the other DE historical reference frames are defined relative to either the DE-118 or B1950 frame. The values below are taken from [4]. DE number Offset from DE-118 Offset from B1950 --------- ------------------ ----------------- 96 +0.1209" +0.4107" 102 +0.3956" +0.1359" 108 +0.0541" +0.4775" 111 -0.0564" +0.5880" 114 -0.0213" +0.5529" 122 +0.0000" +0.5316" 125 -0.0438" +0.5754" 130 +0.0069" +0.5247" 5 DE-96 JPL Developmental Ephemeris ( 96). 6 DE-102 JPL Developmental Ephemeris (102). 7 DE-108 JPL Developmental Ephemeris (108). 8 DE-111 JPL Developmental Ephemeris (111). 9 DE-114 JPL Developmental Ephemeris (114). 10 DE-122 JPL Developmental Ephemeris (122). 11 DE-125 JPL Developmental Ephemeris (125). 12 DE-130 JPL Developmental Ephemeris (130). 13 GALACTIC Galactic System II. The Galactic System II reference frame is defined by the following rotations: o o o [ 327 ] [ 62.6 ] [ 282.25 ] 3 1 3 In the absence of better information, we assume the rotations are relative to the FK4 frame. 14 DE-200 JPL Developmental Ephemeris (200). 15 DE-202 JPL Developmental Ephemeris (202). 16 MARSIAU Mars Mean Equator and IAU vector of J2000. The IAU-vector at Mars is the point on the mean equator of Mars where the equator ascends through the earth mean equator. This vector is the cross product of Earth mean north with Mars mean north. 17 ECLIPJ2000 Ecliptic coordinates based upon the J2000 frame. The value for the obliquity of the ecliptic at J2000 is taken from page 114 of [7] equation 3.222-1. This agrees with the expression given in [5]. 18 ECLIPB1950 Ecliptic coordinates based upon the B1950 frame. The value for the obliquity of the ecliptic at B1950 is taken from page 171 of [7]. 19 DE-140 JPL Developmental Ephemeris. (140) The DE-140 frame is the DE-400 frame rotated: 0.9999256765384668 0.0111817701197967 0.0048589521583895 -0.0111817701797229 0.9999374816848701 -0.0000271545195858 -0.0048589520204830 -0.0000271791849815 0.9999881948535965 The DE-400 frame is treated as equivalent to the J2000 frame. 20 DE-142 JPL Developmental Ephemeris. (142) The DE-142 frame is the DE-402 frame rotated: 0.9999256765402605 0.0111817697320531 0.0048589526815484 -0.0111817697907755 0.9999374816892126 -0.0000271547693170 -0.0048589525464121 -0.0000271789392288 0.9999881948510477 The DE-402 frame is treated as equivalent to the J2000 frame. 21 DE-143 JPL Developmental Ephemeris. (143) The DE-143 frame is the DE-403 frame rotated: 0.9999256765435852 0.0111817743077255 0.0048589414674762 -0.0111817743300355 0.9999374816382505 -0.0000271622115251 -0.0048589414161348 -0.0000271713942366 0.9999881949053349 The DE-403 frame is treated as equivalent to the J2000 frame. Inertial Reference Frame References
[1] Jay Lieske, ``Precession Matrix Based on IAU (1976) System of Astronomical Constants,'' Astron. Astrophys. 73, 282-284 (1979). [2] E.M. Standish, Jr., ``Orientation of the JPL Ephemerides, DE 200/LE 200, to the Dynamical Equinox of J2000,'' Astron. Astrophys. 114, 297-302 (1982). [3] E.M. Standish, Jr., ``Conversion of Ephemeris Coordinates from the B1950 System to the J2000 System,'' JPL IOM 314.6-581, 24 June 1985. [4] E.M. Standish, Jr., ``The Equinox Offsets of the JPL Ephemeris,'' JPL IOM 314.6-929, 26 February 1988. [5] Jay Lieske, ``Expressions for the Precession Quantities Based upon the IAU (1976) System of Astronomical Constants'' Astron. Astrophys. 58, 1-16 (1977). [6] Laura Bass and Robert Cesarone "Mars Observer Planetary Constants and Models" JPL D-3444 November 1990. [7] "Explanatory Supplement to the Astronomical Almanac" edited by P. Kenneth Seidelmann. University Science Books, 20 Edgehill Road, Mill Valley, CA 94941 (1992) Low Level Inertial Reference Frame Functions
Appendix. ``Built in'' PCK-Based IAU Body-Fixed Reference Frames
IAU_ADRASTEA IAU_AMALTHEA IAU_ANANKE IAU_ARIEL IAU_ATLAS IAU_BELINDA IAU_BENNU IAU_BIANCA IAU_BORRELLY IAU_CALLIRRHOE IAU_CALLISTO IAU_CALYPSO IAU_CARME IAU_CERES IAU_CHALDENE IAU_CHARON IAU_CORDELIA IAU_CRESSIDA IAU_DAVIDA IAU_DEIMOS IAU_DESDEMONA IAU_DESPINA IAU_DIONE IAU_EARTH IAU_ELARA IAU_ENCELADUS IAU_EPIMETHEUS IAU_ERINOME IAU_EROS IAU_EUROPA IAU_GALATEA IAU_GANYMEDE IAU_GASPRA IAU_HARPALYKE IAU_HELENE IAU_HIMALIA IAU_HYPERION IAU_IAPETUS IAU_IDA IAU_IO IAU_IOCASTE IAU_ISONOE IAU_ITOKAWA IAU_JANUS IAU_JULIET IAU_JUPITER IAU_KALYKE IAU_LARISSA IAU_LEDA IAU_LUTETIA IAU_LYSITHEA IAU_MAGACLITE IAU_MARS IAU_MERCURY IAU_METIS IAU_MIMAS IAU_MIRANDA IAU_MOON IAU_NAIAD IAU_NEPTUNE IAU_NEREID IAU_OBERON IAU_OPHELIA IAU_PALLAS IAU_PAN IAU_PANDORA IAU_PASIPHAE IAU_PHOBOS IAU_PHOEBE IAU_PLUTO IAU_PORTIA IAU_PRAXIDIKE IAU_PROMETHEUS IAU_PROTEUS IAU_PUCK IAU_RHEA IAU_ROSALIND IAU_SATURN IAU_SINOPE IAU_STEINS IAU_SUN IAU_TAYGETE IAU_TELESTO IAU_TEMPEL_1 IAU_TETHYS IAU_THALASSA IAU_THEBE IAU_THEMISTO IAU_TITAN IAU_TITANIA IAU_TRITON IAU_UMBRIEL IAU_URANUS IAU_VENUS IAU_VESTA Appendix. High Precision Earth Fixed Frames
ITRF93 EARTH_FIXED'ITRF93' is a frame ``fixed'' to the Earth's crust. It provides a high precision model for the orientation of the Earth with respect to J2000. In SPICE this is also a PCK type frame but its orientation is provided in a binary PCK file. 'EARTH_FIXED' is a ``generic frame'' that gives the orientation of the Earth with respect to some other frame (usually 'IAU_EARTH' or 'ITRF93') via a constant rotational offset. Such frames are called Text Kernel (TK) frames. See the subsection `` Gaining Flexibility via TK Frames'' for a discussion of the use of TK frames. Appendix. Frame Identifiers Reserved for Earth Fixed Frames
The class ID to associate with any DSN frame is the frame ID minus 10000. For example, the class ID associated with frame 13003 is 3003. It is this class ID that should be placed in the PCK file that implements the relationship between the DSN frame and the corresponding inertial frame. The center of any DSN frame is the center of mass of the Earth, which has SPK ID code 399. These frames are partially ``built in''. Given a frame ID in the range from 13001 to 13999, the frame subsystem ``knows'' that the frame is a PCK frame, the center of the frame is 399 and the class ID of the frame is the frame ID - 10000. This knowledge cannot be overridden. However, the frame subsystem does not ``know'' the relationship between the names of these frames and their ID codes. The relationship must be specified via the appropriate kernel pool frame definition.
FRAME_<name> = <DSN Frame-ID> FRAME_<DSN Frame-ID>_NAME = '<name>' OBJECT_EARTH_FRAME = <DSN Frame-ID>Note that this specification leaves out the items below
FRAME_<DSN Frame-ID>_CENTER = 399 FRAME_<DSN Frame-ID>_CLASS = 2 FRAME_<DSN Frame-ID>_CLASS_ID = <DSN Frame-ID - 10000>You may supply these values if you like, but they have no effect on the frame subsystem's recognition and interpretation of the frame with the specified frame ID. Appendix. Frame Definition Examples
Inertial Frame
\begindata FRAME_EME50 = 2000000 FRAME_2000000_NAME = 'EME50' FRAME_2000000_CLASS = 1 FRAME_2000000_CLASS_ID = 2 FRAME_2000000_CENTER = 0 \begintext PCK Frame
\begindata FRAME_EROS_FIXED = 2000433 FRAME_2000433_NAME = 'EROS_FIXED' FRAME_2000433_CLASS = 2 FRAME_2000433_CLASS_ID = 2000433 FRAME_2000433_CENTER = 2000433 OBJECT_2000433_FRAME = 'EROS_FIXED' \begintext CK Frames
\begindata FRAME_MGS_SPACECRAFT = -94000 FRAME_-94000_NAME = 'MGS_SPACECRAFT' FRAME_-94000_CLASS = 3 FRAME_-94000_CLASS_ID = -94000 FRAME_-94000_CENTER = -94 CK_-94000_SCLK = -94 CK_-94000_SPK = -94 OBJECT_-94_FRAME = 'MGS_SPACECRAFT' \begintext TK frame --- Alias
\begindata FRAME_MARS_FIXED = 1400499 FRAME_1400499_NAME = 'MARS_FIXED' FRAME_1400499_CLASS = 4 FRAME_1400499_CLASS_ID = 1400499 FRAME_1400499_CENTER = 499 OBJECT_499_FRAME = 'MARS_FIXED' \begintext To make this point to another frame just replace 'IAU_MARS' below with the name of that frame. \begindata TKFRAME_1400499_RELATIVE = 'IAU_MARS' TKFRAME_1400499_SPEC = 'MATRIX' TKFRAME_1400499_MATRIX = ( 1 0 0 0 1 0 0 0 1 ) \begintext TK frame --- Topographic
\begindata FRAME_DSS-17_TOPO = 1399017 FRAME_1399017_NAME = 'DSS-17_TOPO' FRAME_1399017_CLASS = 4 FRAME_1399017_CLASS_ID = 1399017 FRAME_1399017_CENTER = 399017 OBJECT_399017_FRAME = 'DSS-17_TOPO' \begintext Note that the geodetic longitude and co-latitude of the DSS-17 tracking station are:<PHONE_NUMBER>75 and 54.657822839 respectively. \begindata TKFRAME_DSS-17_TOPO_RELATIVE = 'EARTH_FIXED' TKFRAME_DSS-17_TOPO_SPEC = 'ANGLES' TKFRAME_DSS-17_TOPO_UNITS = 'DEGREES' TKFRAME_DSS-17_TOPO_AXES = ( 3, 2, 3 ) TKFRAME_DSS-17_TOPO_ANGLES = ( -243.126496675, -54.657822839, 180.0 ) \begintext Recall that the frame `EARTH_FIXED' is a TK frame. As a result its relationship to other frames must be specified via a kernel pool variable. We make that specification here. If the ITRF93 PCK kernel is not available we can simply rename the "RELATIVE" frame to be IAU_EARTH and still have the topocentric frame well defined. \begindata TKFRAME_EARTH_FIXED_RELATIVE = 'ITRF93' TKFRAME_EARTH_FIXED_SPEC = 'MATRIX' TKFRAME_EARTH_FIXED_MATRIX = ( 1 0 0 0 1 0 0 0 1 ) \begintext TK frame --- Instrument
The rotation from the DIF spacecraft frame to the MRI instrument frame determined from the in-flight calibration data can be represented by the following rotation angles:
mri M = |0.129539306414| * |-45.006884881185| * |0.004898709285| sc Z Y XThe frame definition contains the opposite of these rotation angles -- with the angle order reversed and the angle signs changed to the opposite ones -- because the angles specified in it define the transformation from the MRI frame to the spacecraft frame.
\begindata FRAME_DIF_MRI = -140200 FRAME_-140200_NAME = 'DIF_MRI' FRAME_-140200_CLASS = 4 FRAME_-140200_CLASS_ID = -140200 FRAME_-140200_CENTER = -140 TKFRAME_-140200_SPEC = 'ANGLES' TKFRAME_-140200_RELATIVE = 'DIF_SPACECRAFT' TKFRAME_-140200_ANGLES = ( -0.004898709285, 45.006884881185, -0.129539306414 ) TKFRAME_-140200_AXES = ( 1, 2, 3 ) TKFRAME_-140200_UNITS = 'DEGREES' \begintext Examples of Two-Vector Parameterized Dynamic FramesGeocentric Solar Ecliptic (GSE) Frame
FRAME_GSE = <frame_ID> FRAME_<frame_ID>_NAME = 'GSE' FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'TWO-VECTOR' FRAME_<frame_ID>_PRI_AXIS = 'X' FRAME_<frame_ID>_PRI_VECTOR_DEF = 'OBSERVER_TARGET_POSITION' FRAME_<frame_ID>_PRI_OBSERVER = 'EARTH' FRAME_<frame_ID>_PRI_TARGET = 'SUN' FRAME_<frame_ID>_PRI_ABCORR = 'NONE' FRAME_<frame_ID>_SEC_AXIS = 'Y' FRAME_<frame_ID>_SEC_VECTOR_DEF = 'OBSERVER_TARGET_VELOCITY' FRAME_<frame_ID>_SEC_OBSERVER = 'EARTH' FRAME_<frame_ID>_SEC_TARGET = 'SUN' FRAME_<frame_ID>_SEC_ABCORR = 'NONE' FRAME_<frame_ID>_SEC_FRAME = 'J2000' Geocentric Solar Magnetospheric (GSM) Frame
FRAME_GSM = <frame_ID> FRAME_<frame_ID>_NAME = 'GSM' FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'TWO-VECTOR' FRAME_<frame_ID>_PRI_AXIS = 'X' FRAME_<frame_ID>_PRI_VECTOR_DEF = 'OBSERVER_TARGET_POSITION' FRAME_<frame_ID>_PRI_OBSERVER = 'EARTH' FRAME_<frame_ID>_PRI_TARGET = 'SUN' FRAME_<frame_ID>_PRI_ABCORR = 'NONE' FRAME_<frame_ID>_SEC_AXIS = 'Z' FRAME_<frame_ID>_SEC_VECTOR_DEF = 'CONSTANT' FRAME_<frame_ID>_SEC_FRAME = 'IAU_EARTH' FRAME_<frame_ID>_SEC_SPEC = 'LATITUDINAL' FRAME_<frame_ID>_SEC_UNITS = 'DEGREES' FRAME_<frame_ID>_SEC_LONGITUDE = 288.43 FRAME_<frame_ID>_SEC_LATITUDE = 79.54 Mercury Solar Equatorial (MSEQ) Frame
The MSEQ frame can be defined using the following assignments, where <frame_ID> must be replaced by an integer ID code.
FRAME_MSEQ = <frame_ID> FRAME_<frame_ID>_NAME = 'MSEQ' FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 199 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'TWO-VECTOR' FRAME_<frame_ID>_PRI_AXIS = 'Z' FRAME_<frame_ID>_PRI_VECTOR_DEF = 'CONSTANT' FRAME_<frame_ID>_PRI_FRAME = 'IAU_SUN' FRAME_<frame_ID>_PRI_SPEC = 'RECTANGULAR' FRAME_<frame_ID>_PRI_VECTOR = ( 0, 0, 1 ) FRAME_<frame_ID>_SEC_AXIS = 'X' FRAME_<frame_ID>_SEC_VECTOR_DEF = 'OBSERVER_TARGET_POSITION' FRAME_<frame_ID>_SEC_OBSERVER = 'MERCURY' FRAME_<frame_ID>_SEC_TARGET = 'SUN' FRAME_<frame_ID>_SEC_ABCORR = 'NONE' Example: Nadir Frame for Mars Orbiting Spacecraft
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = <orbiter_ID> FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'TWO-VECTOR' FRAME_<frame_ID>_PRI_AXIS = 'Z' FRAME_<frame_ID>_PRI_VECTOR_DEF = 'TARGET_NEAR_POINT' FRAME_<frame_ID>_PRI_OBSERVER = <orbiter_ID/name> FRAME_<frame_ID>_PRI_TARGET = 'MARS' FRAME_<frame_ID>_PRI_ABCORR = 'NONE' FRAME_<frame_ID>_SEC_AXIS = '-X' FRAME_<frame_ID>_SEC_VECTOR_DEF = 'OBSERVER_TARGET_VELOCITY' FRAME_<frame_ID>_SEC_OBSERVER = <orbiter_ID/name> FRAME_<frame_ID>_SEC_TARGET = 'MARS' FRAME_<frame_ID>_SEC_ABCORR = 'NONE' FRAME_<frame_ID>_SEC_FRAME = 'J2000' Example: Roll-Celestial Spacecraft Frame
Definition of the roll-celestial frame:
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = <spacecraft_ID> FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'TWO-VECTOR' FRAME_<frame_ID>_PRI_AXIS = 'Z' FRAME_<frame_ID>_PRI_VECTOR_DEF = 'OBSERVER_TARGET_POSITION' FRAME_<frame_ID>_PRI_OBSERVER = <spacecraft_ID/name> FRAME_<frame_ID>_PRI_TARGET = 'EARTH' FRAME_<frame_ID>_PRI_ABCORR = 'NONE' FRAME_<frame_ID>_SEC_AXIS = 'X' FRAME_<frame_ID>_SEC_VECTOR_DEF = 'CONSTANT' FRAME_<frame_ID>_SEC_FRAME = 'J2000' FRAME_<frame_ID>_SEC_SPEC = 'RA/DEC' FRAME_<frame_ID>_SEC_UNITS = 'DEGREES' FRAME_<frame_ID>_SEC_RA = <star RA in degrees> FRAME_<frame_ID>_SEC_DEC = <star DEC in degrees> FRAME_<frame_ID>_SEC_ABCORR = 'S' FRAME_<frame_ID>_SEC_OBSERVER = <spacecraft_ID/name> Examples of Mean Equator and Equinox of Date FramesEarth Mean Equator and Equinox of Date Frames
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'MEAN_EQUATOR_AND_EQUINOX_OF_DATE' FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' FRAME_<frame_ID>_ROTATION_STATE= 'ROTATING'Definition for the inertial version of the above frame:
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'MEAN_EQUATOR_AND_EQUINOX_OF_DATE' FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' FRAME_<frame_ID>_ROTATION_STATE= 'INERTIAL'Definition for the frozen version of the above frame, where the ``freeze epoch'' is B1950 TDB. The resulting frame should match the inertial frame B1950 to round-off level:
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'MEAN_EQUATOR_AND_EQUINOX_OF_DATE' FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' FRAME_<frame_ID>_FREEZE_EPOCH = @1949-DEC-31/22:09:46.861901 Examples of True Equator and Equinox of Date Frames
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'TRUE_EQUATOR_AND_EQUINOX_OF_DATE' FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' FRAME_<frame_ID>_NUT_MODEL = 'EARTH_IAU_1980' FRAME_<frame_ID>_ROTATION_STATE= 'ROTATING'Definition for the inertial version of the above frame:
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'TRUE_EQUATOR_AND_EQUINOX_OF_DATE' FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' FRAME_<frame_ID>_NUT_MODEL = 'EARTH_IAU_1980' FRAME_<frame_ID>_ROTATION_STATE= 'INERTIAL'Definition for the frozen version of the above frame, where the ``freeze epoch'' is B1950 TDB.
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'TRUE_EQUATOR_AND_EQUINOX_OF_DATE' FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' FRAME_<frame_ID>_NUT_MODEL = 'EARTH_IAU_1980' FRAME_<frame_ID>_FREEZE_EPOCH = @1949-DEC-31/22:09:46.861901 Example of a Mean Ecliptic and Equinox of Date Frame
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'MEAN_ECLIPTIC_AND_EQUINOX_OF_DATE' FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' FRAME_<frame_ID>_OBLIQ_MODEL = 'EARTH_IAU_1980' FRAME_<frame_ID>_ROTATION_STATE= 'ROTATING'Definition for the inertial version of the above frame:
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'MEAN_ECLIPTIC_AND_EQUINOX_OF_DATE' FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' FRAME_<frame_ID>_OBLIQ_MODEL = 'EARTH_IAU_1980' FRAME_<frame_ID>_ROTATION_STATE= 'INERTIAL'Definition for the frozen version of the above frame, where the ``freeze epoch'' is B1950 TDB.
FRAME_<frame_name> = <frame_ID> FRAME_<frame_ID>_NAME = <frame_name> FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 399 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'MEAN_ECLIPTIC_AND_EQUINOX_OF_DATE' FRAME_<frame_ID>_PREC_MODEL = 'EARTH_IAU_1976' FRAME_<frame_ID>_OBLIQ_MODEL = 'EARTH_IAU_1980' FRAME_<frame_ID>_FREEZE_EPOCH = @1949-DEC-31/22:09:46.861901 Example of an Euler Frame
The PCK data defining the underlying IAU_MARS frame are:
BODY499_POLE_RA = ( 317.68143 -0.1061 0. ) BODY499_POLE_DEC = ( 52.88650 -0.0609 0. ) BODY499_PM = ( 176.630<PHONE_NUMBER>6 0. )These values are from:
Seidelmann, P.K., Abalakin, V.K., Bursa, M., Davies, M.E., Bergh, C. de, Lieske, J.H., Oberst, J., Simon, J.L., Standish, E.M., Stooke, P., and Thomas, P.C. (2002). "Report of the IAU/IAG Working Group on Cartographic Coordinates and Rotational Elements of the Planets and Satellites: 2000," Celestial Mechanics and Dynamical Astronomy, v.82, Issue 1, pp. 83-111.Here pole RA/Dec terms in the PCK are in degrees and degrees/century; the rates here have been converted to degrees/sec. Prime meridian terms in the PCK are in degrees and degrees/day; the rate here has been converted to degrees/sec. The 3x3 transformation matrix M defined by the angles is
M = [angle_1] [angle_2] [angle_3] 3 1 3Vectors are mapped from the J2000 base frame to the IAU_MARS frame via left multiplication by M. The relationship of these Euler angles to RA/Dec/PM for the J2000-to-IAU Mars body-fixed transformation is as follows:
angle_1 is PM * (radians/degree) angle_2 is pi/2 - Dec * (radians/degree) angle_3 is pi/2 + RA * (radians/degree)Since when we define the IAU_MARS_EULER frame we're defining the *inverse* of the above transformation, the angles for our Euler frame definition are reversed and the signs negated:
angle_1 is -pi/2 - RA * (radians/degree) angle_2 is -pi/2 + Dec * (radians/degree) angle_3 is - PM * (radians/degree)Then our frame definition is:
FRAME_IAU_MARS_EULER = <frame_ID> FRAME_<frame_ID>_NAME = 'IAU_MARS_EULER' FRAME_<frame_ID>_CLASS = 5 FRAME_<frame_ID>_CLASS_ID = <frame_ID> FRAME_<frame_ID>_CENTER = 499 FRAME_<frame_ID>_RELATIVE = 'J2000' FRAME_<frame_ID>_DEF_STYLE = 'PARAMETERIZED' FRAME_<frame_ID>_FAMILY = 'EULER' FRAME_<frame_ID>_EPOCH = @2000-JAN-1/12:00:00 FRAME_<frame_ID>_AXES = ( 3 1 3 ) FRAME_<frame_ID>_UNITS = 'DEGREES' FRAME_<frame_ID>_ANGLE_1_COEFFS = ( -47.68143 0.33621061170684714E-10 ) FRAME_<frame_ID>_ANGLE_2_COEFFS = ( -37.1135 -0.19298045478743630E-10 ) FRAME_<frame_ID>_ANGLE_3_COEFFS = ( -176.630 -0.40612497946759260E-02 ) |


Before Change
h5f = Instance(tables.File, transient = True)
// internal identifier
digest = Property( depends_on = ["mpos.digest", "grid.digest", "c", \
"env.digest", "steer", "precision"], cached = True)
@cached_property
def _get_digest( self ):
After Change
//: instance of :class:`~acoular.fbeamform.SteeringVector` or its derived classes,
//: that contains information about the steering vector.
steer_obj = Trait(SteeringVector)
//: Flag that defines how to calculate and store the point spread function
//: defaults to "single".
//: