| PCK Required Reading |
Table of ContentsPCK Required Reading Abstract Intended Audience References Introduction Body Codes Epochs and Reference Frames Planetocentric Coordinates Using the PCK System: Overview Orientation Models used by PCK Software The Two Formats of PCK files Detection of Non-native Text Files DAF Run-Time Binary File Format Translation NAIF Text Kernel Format Text PCK Contents Reference Ellipsoid Orientation Offsets Text PCK Kernel Variable Names Restrictions on the Availability of Orientation Models in Text PCK Kernels Models for the Sun, Planets, and some Minor Bodies in Text PCK Kernels Models for Satellites in Text PCK Kernels Shape models in Text PCK Kernels Summary of PCK Variables used in Text PCK Kernels by CSPICE Creating and Modifying Text PCKs Binary PCK Kernel Format Segments--The Fundamental PCK Building Blocks The Comment Area Binary PCK Data Types Supported Data Types Type 2: Chebyshev (Angles only) Type 3: Chebyshev (Angles and their derivatives) Type 20: Chebyshev (Only angular derivatives) Creating Binary PCKs PCK Software Getting PCK Data into Your Program Loading Text PCK Kernels Loading Binary PCK Kernels Unloading Binary PCK Kernels Binary PCK Coverage Summary Routines Access Routines High-Level PCK Data Access Low-Level PCK Data Access Appendix A --- Summary of PCK Routines Appendix B --- Epoch and Frame Specifications in Text PCK Kernels Appendix C --- Revision History 2021 DEC 24 by N.J. Bachman 2013 JAN 22 by E. D. Wright, C. H. Acton 2010 JUN 03 by B. V. Semenov. Original version K.R. Gehringer, K. S. Zukor PCK Required Reading
Abstract
Intended Audience
References
Introduction
Historically, only one type of PCK existed, the text PCK (called the "P constants kernel.") These ASCII files can be easily viewed and modified via text editor. The current SPICE system also supports a non-ascii binary PCK. These files contain more precise body orientation information in binary format (no size and shape data). This format permits large amounts of data to be stored and quickly accessed. As of the date of this document, binary PCK files exists only for the moon, earth, and the asteroid Eros. The purpose of the PCK and associated software is to provide SPICE users a convenient mechanism for supplying planetary physical constants to application programs. CSPICE software reads files conforming to these formats and returns both the data contained in such files and a few commonly used numeric quantities derived from the kernel data. Body Codes
In this document, the following features of the code system will be relied on:
PNN, where
P is 1, ..., 9
and NN is 01, ... 98
PXNNN, where
P is 1, ..., 9,
X is 0 or 5,
and NNN is 001, ... 999
Codes with X = 5 are provisional.
Epochs and Reference Frames
Within CSPICE, reference frames are identified by short character strings such as 'J2000'. The names of the body-fixed reference frames are usually constructed by adding the prefix ``IAU_'' to the name of the body, for example ``IAU_MARS'' for Mars. The exception from this rule are body-fixed reference frames associated with high-precision orientation provided in binary PCK files. For more details see FRAMES Required Reading, frames.req. However, CSPICE also has a system of integer codes used by some routines to specify reference frames. This coding system is also described in detail in frames.req. Planetocentric Coordinates
Using the PCK System: Overview
The use of PCK data in an application program requires three steps:
Step 2 is referred to as ``loading'' a PCK file. Text PCK files are loaded by calling the CSPICE subroutine furnsh_c and supplying the name of the PCK file to load as the input argument or by loading a meta kernel that lists the PCK. All data in a text PCK file is read into memory when the file is loaded by an application program at run-time. Load binary PCKs in the same way. The program can access all loaded data during the program run, unless deliberately overwritten or unloaded. Multiple text and multiple binary PCKs can be used simultaneously. The data available from binary PCKs take precedence over that from text PCKs. If data for a requested planetary constant and time period is covered by a loaded binary PCK file, the subsystem returns and uses the binary data. If multiple binary PCK files are loaded, the most recently loaded file takes precedence, down to the binary file loaded earliest. The subsystem defaults to text PCK data when no binary PCK data is available. If the user loaded multiple text PCKs, and those PCKs contained variable assignments using the same variable name, the later loads overwrite the assignments defined by earlier loads. Step 3, using loaded PCK data, is accomplished via calls to CSPICE routines. At the lowest level, these access routines allow the calling program to retrieve specified data that has been read from one or more PCK files. Higher-level access routines can return quantities derived from loaded PCK data. For text PCK files, the PCK software can be thought of as ``buffering'' all data loaded from PCK files: the data from these files is retained in memory. Therefore, repeated calls to the PCK access routines do not incur the inefficiency of re-reading data from files. For binary PCK file, like the case of the SPK and CK readers, only a portion of the most recently used information is buffered. The data structure used by CSPICE to maintain associations of text kernel variable names and values is called the ``kernel pool.'' Data loaded into memory via furnsh_c is referred to as ``being present in the kernel pool.'' There is no analog to the kernel pool for binary PCK files. Orientation Models used by PCK Software
The orientation models use three Euler angles to describe the pole and prime meridian location: the first two angles, in order, are the right ascension and declination (henceforth RA and DEC) of the north pole of a body as a function of time. The third angle is the prime meridian location (represented by `W'), which is expressed as a rotation about the north pole, also a function of time. The coordinate transformation defined by the Euler angles is represented by the matrix product
[ W ] [ Pi/2 - Dec ] [ Pi/2 + RA ]
3 1 3
where
[ W ]
i
denotes the matrix that rotates a coordinate system by W radians about
the ith coordinate axis (or rotates vectors by -W radians about the same
axis), using the right hand rule. (This notation is explained in detail
in rotation.req).
In PCK files, the time arguments of functions that define orientation always refer to Barycentric Dynamical Time (TDB), measured in centuries or days past a specified epoch such as J2000, which is Julian ephemeris date 2451545.0. The time units expected by the CSPICE software are ephemeris days for prime meridian motion and ephemeris centuries for motion of the pole. The Two Formats of PCK files
Detection of Non-native Text Files
Environment Native End-Of-Line
Indicator
___________ _____________________
PC DOS/Windows <CR><LF>
Mac OS X, Linux, Unix <LF>
As of CSPICE N0059, the CSPICE text kernel loaders, furnsh_c and
ldpool_c, can read and parse non-native text files. The FORTRAN SPICELIB
does not include this capability.
Please be aware the CSPICE text file reader, rdtext_c, does not possess the capability to read non-native text files. DAF Run-Time Binary File Format Translation
NAIF Text Kernel Format
Text PCK files conform to a flexible format called ``NAIF text kernel'' format. The SPICE file identification word provided by itself on the first line of the text PCK file, starting in the leftmost column, is ``KPL/PCK''. Both the NAIF text kernel format and SPICE file identification word are described in detail in the Kernel Required Reading document, kernel.req. For the reader's convenience, an overview of the NAIF text kernel format is provided here. NAIF text kernels are, first of all, ASCII files. As such, they are human readable and can be easily modified by text editors. In addition, NAIF text kernels can be readily ported between computer systems, even when the systems in question have different file systems and file formats. The NAIF text kernel format provides for representation of data in a ``keyword = value'' syntax. The format also provides for the inclusion of free-form comment blocks. There are two kinds of data that can be placed in NAIF text kernel files: double precision numbers and UTC time strings. According to the text kernel format, a text kernel nominally consists of a series of sets of contiguous lines (or ``blocks'') of comments, alternating with blocks of data. Comment blocks are started with the string (called a ``control sequence'')
\begintextalone on a line, as shown here. Comment blocks are ended by the control sequence
\begindataalone on a line. In a text kernel file, the lines preceding the first
\begindatacontrol sequence are considered to constitute a comment block; the
\begintextcontrol sequence is optional for this comment block. Comment blocks can contain arbitrary text, except for non-printing characters or lines that can be interpreted as control sequences. On the other hand, data must be organized according to a very specific format: all of the data in a text kernel must appear in the form of an ``assignment'' such as
NAME = VALUEor
NAME = ( VALUE1, VALUE2, ... )where "NAME" is a string no longer than 32 characters, and one or more values appear on the right hand. A specific example is shown below:
BODY399_RADII = ( 6378.140 6378.140 6356.75 )The "VALUES" may be integer, double precision or string values. Some variations on the form shown here are allowed: commas between data values are optional, the right hand side of the assignment can be continued over multiple lines, and the data values can be expressed as integers or reals without causing the PCK software to fail. Either an "E" or "D" can be used to set off an exponent. Assignments of scalars do not require the value on the right hand side to be enclosed in parentheses, but that notation is frequently used as a visual cue. Blank lines within or between assignments are ignored by the CSPICE software that reads text kernels. In addition to numbers, UTC strings can be assigned to variables. The ``@'' character is used to identify the strings as time strings. The strings are stored internally as double precision numbers representing ``UTC seconds past J2000.'' An example is the assignment:
SCLK_KERNEL_ID = ( @01-MAY-1991/16:25 )See kernel.req for a complete discussion of the allowed form of assignments. The effect of an assignment in a text PCK file is to associate values with a name. The name is referred to as a ``kernel variable.'' When a text PCK file is loaded by an application, the associations of names and values established by the PCK are maintained: the values associated with a given name can be retrieved at any time. Text PCK Contents
CSPICE includes a set of routines (gipool_c, gdpool_c, gipool_c) for general access to text PCK defined data. Another set (bodvrd_c, bodvcd_c, sxform_c, pxform_c) recognizes and uses particular PCK data to return body constants or the matrices to transform position or state vectors between reference frames. In this document, the formulas defining time-varying coordinate transformation matrices and Euler angles are referred to as ``orientation models'' since they define the orientation of an extended body with respect to specific inertial frames. Because PCK access routines that deal with orientation models are used extensively in CSPICE and applications that use the Toolkit, the kernel variables that these routines rely on will be discussed in detail. Those functions defining the Euler angles are characterized by a set of parameters. The specific values of the parameters are values assigned to kernel variables in PCK files. The functions themselves are implemented by code within CSPICE routines. The general form of the functions is that used in the IAU/IAG 2000 report. Values shown in this document reflect the 2000 report. For the latest PCK values, check with NAIF. In a text PCK file, the variables (Euler angles)
RA, DEC, Wfor the Earth (Earth ID = 399) are represented by the names
BODY399_POLE_RA BODY399_POLE_DEC BODY399_POLE_PMThe equations above are expressed in a text PCK file by the kernel variable assignments (Values taken from IAU/IAG 2000 report.)
BODY399_POLE_RA = ( 0. -0.641 0. ) BODY399_POLE_DEC = ( +90. -0.557 0. ) BODY399_PM = ( 190.16 +360.9856235 0. ) Reference Ellipsoid Orientation Offsets
BODY399_LONG_AXISThe CSPICE function bodeul_c returns the value of the kernel variable
BODY<id code>_LONG_AXISas an output argument, but CSPICE does not make use of this value. This value represents the offset between the longest axis of the triaxial ellipsoid used to model the shape of a body and the prime meridian of the body. Historically, IAU orientation models have had only zero offsets. CSPICE high-level geometry software that makes use of reference ellipsoids assumes that ellipsoid axes are aligned with those of the corresponding PCK reference frame. When this is not the case, a new TK reference frame can be defined that provides the correct reference ellipsoid orientation relative to the PCK frame. See the Frames Required Reading document frames.req for more information on TK frames. Defining a TK frame for reference ellipsoid orientation relative to the corresponding PCK frame is an effective way of representing such offsets. It enables user applications to pass the TK frame name to CSPICE APIs, so that those APIs will perform computations using the desired ellipsoid orientation. Text PCK Kernel Variable Names
BODYnnn_<item name>where
<item name>is a short string that identifies the type of quantity the kernel variable represents. For example, the variable containing quadratic polynomial coefficients for the right ascension of the Earth's north pole is
BODY399_POLE_RAThe following sections specify the specific item names recognized by PCK access routines. Restrictions on the Availability of Orientation Models in Text PCK Kernels
Models for the Sun, Planets, and some Minor Bodies in Text PCK Kernels
Let RA and DEC represent the right ascension and declination of a body's north pole as expressed in the J2000 frame, and let W be the prime meridian location, measured in the counterclockwise direction, from the direction defined by the cross product of the Z direction in the J2000 frame (the Earth's ``mean'' North pole at the J2000 epoch) and BODY's North pole at ET, to BODY's prime meridian at ET. The variables RA, DEC, and W constitute sufficient information to compute the transformation from a specified inertial frame to body-fixed, planetocentric coordinates for the body to which they apply, at a specified time. The angles RA, DEC, and W are defined as follows:
2
RA2*t
RA = RA0 + RA1*t/T + ------ + [optional trig polynomials]
2
T
2
DEC2*t
DEC = DEC0 + DEC1*t/T + ------- + [optional trig polynomials]
2
T
2
W2*t
W = W0 + W1*t/d + ----- + [optional trig polynomials]
2
d
where
d = seconds/day
T = seconds/Julian century
t = ephemeris time, expressed as seconds past the reference epoch
for this body or planetary system
Expressions for RA, Dec, and W for planets rarely include the
trigonometric polynomial terms shown above. If they are used, these
terms follow the form described below which is used for natural
satellites.
Models for Satellites in Text PCK Kernels
Expressions for the right ascension and declination of the north pole and the location of the prime meridian for any satellite of a given planet are as follows:
2 ____
RA2*t \
RA = RA0 + RA1*t/T + ------ + / a * sin * theta
2 ---- i i
T i
2 ____
DEC2*t \
DEC = DEC0 + DEC1*t/T + ------- + / d * cos * theta
2 ---- i i
T i
2 ____
W2*t \
W = W0 + W1*t/d + ----- + / w * sin * theta
2 ---- i i
d i
where
d = seconds/day T = seconds/Julian century t = ephemeris time, expressed as seconds past a reference epochRA0, RA1, DEC0, DEC1, W0, and W1 are constants specific to each satellite. The nutation precession angles
theta
i
are specific to each planet. The coefficients
a , d , and w
i i i
are specific to each satellite.
CSPICE software for text PCKs expects the models for satellite orientation to follow the form of the model shown here: the polynomial terms in the RA, DEC, and W expressions are expected to be quadratic, the trigonometric terms for RA and W (satellite prime meridian) are expected to be sums of sines of nutation precession angles, and the trigonometric terms for DEC are expected to be sums of cosines of nutation precession angles. The nutation precession angles themselves, by default, are defined by linear polynomial functions of time. It is possible to use polynomials of degree up to 3 to represent nutation precession angles for a specified planetary system. This is done by adding to a text PCK file the kernel variable assignment
BODY<id code>_MAX_PHASE_DEGREE = <degree>where ``id'' is the code of the planetary system barycenter. For example, quadratic nutation precession angle expressions can be used for the Mars system if a text PCK contains the assignment
BODY4_MAX_PHASE_DEGREE = 2For any planetary system, all nutation precession angles must have the same number of coefficients. Units of the polynomial coefficients of the nutation precession angles are, in order of increasing degree,
degrees degrees
degrees, --------------, ---------------, ...
Julian century 2
Julian century
Note that the number of values defining the nutation precession angles
for a planetary system must be consistent with the number of
trigonometric terms used in the expressions for the RA, DEC and W angles
for the satellites of that system. See ``Creating and Modifying Text
PCKs Kernels'' for details.
Shape models in Text PCK Kernels
In text PCK files produced by NAIF, the radius values for body nnn are assigned to the variable as:
BODYnnn_RADII = ( a, b, c )where ``a,'' ``b,'' and ``c'' are the radius values for each axis. Three radius values are always assigned for each instance of this variable. The data are ordered as in the IAU/IAG report: the equatorial radii are listed with the largest axis, normally called the ``a'' axis, appearing first; the polar radius, normally called the ``c'' axis, is last. Spheroids and spheres are obtained when two or all three radii are equal. Summary of PCK Variables used in Text PCK Kernels by CSPICE
BODYppp_POLE_RA BODYppp_POLE_DEC BODYppp_PMFor a satellite (say body number sss), one or more PCK files containing values for the following variables must be loaded:
BODYsss_POLE_RA BODYsss_POLE_DEC BODYsss_PM BODYsss_NUT_PREC_RA BODYsss_NUT_PREC_DEC BODYsss_NUT_PREC_PM BODYbbb_NUT_PREC_ANGLESwhere the code bbb embedded in the last name above is that of the barycenter of the planetary system to which the satellite belongs. The triaxial ellipsoidal model for body nnn is expressed by the assignment
BODYnnn_RADII = ( <larger equatorial radius>,
<smaller equatorial radius>,
<polar radius> )
Creating and Modifying Text PCKs
Although the text PCK format makes it easy to modify text PCK files, NAIF recommends that application programmers avoid software designs that call for special-purpose, user-created text PCK files. The opportunities for confusion and errors increase with the number of available versions of a text PCK file (or any data file). NAIF recommends that you take the following precautions when modifying a text PCK file:
BODYnnn_where nnn is the NAIF integer code of the body corresponding to the variable. Kernel variables having names recognized by users' application software are a potential problem area: if the names used in the application don't match those in the text PCK file, the application will fail to obtain the data as intended. The most frequent cause of this type of failure is misspelling of variable names, but programmers who considering changing the names of PCK variables already in use should also keep this problem in mind. Modifying orientation models for satellites requires attention to consistency between the number of nutation precession angles and the number of coefficients of trigonometric functions having the nutation precession angles as arguments. For any planetary system, if DEG is the maximum nutation precession angle polynomial degree for that system, there should be DEG+1 times as many values for the nutation precession angles as the maximum number of trigonometric terms in the expressions for prime meridian location or right ascension or declination of the pole of any satellite in the system. This is because all nutation precession angle polynomials for a given planetary system must have the same degree. Binary PCK Kernel Format
Segments--The Fundamental PCK Building Blocks
The data in each segment are stored as a single array. The summary for the array, called a `descriptor', has two double precision components:
The Comment Area
CSPICE provides a family of subroutines for handling this Comment Area. This software provides the ability to add, extract, read, and delete comments and convert commented files from binary format to transfer format and back to binary again. Binary PCK Data Types
Supported Data Types
Type 2: Chebyshev (Angles only)
The segments contain an arbitrary number of logical records with each record describing a set of Chebyshev coefficients valid across an interval of fixed length. A segment consists of a set of records, ordered by increasing initial epoch, each record containing the same number of coefficients. The segment structure is illustrated below:
+---------------+
| Record 1 |
+---------------+
| Record 2 |
+---------------+
.
.
.
+---------------+
| Record N |
+---------------+
| INIT |
+---------------+
| INTLEN |
+---------------+
| RSIZE |
+---------------+
| N |
+---------------+
A four-number `directory' at the end of the segment contains the
information needed to determine the location of the record corresponding
to a particular epoch.
polynomial degree = ( RSIZE - 2 ) / 3 - 1
The structure of each record:
--------------------------------------------------------------- | The midpoint of the approximation interval in TDB seconds | --------------------------------------------------------------- | The radius of the approximation interval in TDB seconds | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for RA | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for DEC | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for W | ---------------------------------------------------------------TDB seconds is time in ephemeris seconds past J2000, often called ET in the SPICE system. The first two elements in the record, MID and RADIUS, are the midpoint and radius of the time interval covered by coefficients in the record. These are used as parameters to perform transformations between the domain of the record (from MID - RADIUS to MID + RADIUS) and the domain of Chebyshev polynomials (from -1 to 1 ). Type 3: Chebyshev (Angles and their derivatives)
Each segment contains an arbitrary number of logical records. All records contain the same number of coefficients. A segment of this type is structured as follows:
+---------------+
| Record 1 |
+---------------+
| Record 2 |
+---------------+
.
.
.
+---------------+
| Record N - 1 |
+---------------+
| Record N |
+---------------+
The structure of each record:
--------------------------------------------------------------- | The midpoint of the approximation interval in TDB seconds | --------------------------------------------------------------- | The radius of the approximation interval in TDB seconds | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for RA | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for DEC | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for W | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for the body | | fixed X-axis rate | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for the body | | fixed Y-axis rate | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for the body | | fixed Z-axis rate | ---------------------------------------------------------------TDB seconds is time in ephemeris seconds past J2000, called ET in the SPICE system. The type 3 data type is seldom used. Type 20: Chebyshev (Only angular derivatives)
This data type is provided to accurately represent ``EPM'' orientation data developed by the Institute of Applied Astronomy (IAA), Russian Academy of Sciences (RAS). Each type 20 segment contains an arbitrary number of logical records. Each record contains a set of Chebyshev coefficients valid throughout an interval of fixed length. Each record also contains an Euler angle set applicable at the midpoint of its coverage interval. The records within a segment are ordered by increasing initial epoch. All records contain the same number of coefficients. A segment of this type is structured as follows:
+---------------+
| Record 1 |
+---------------+
| Record 2 |
+---------------+
.
.
.
+---------------+
| Record N |
+---------------+
| ASCALE |
+---------------+
| TSCALE |
+---------------+
| INITJD |
+---------------+
| INITFR |
+---------------+
| INTLEN |
+---------------+
| RSIZE |
+---------------+
| N |
+---------------+
A seven-number `directory' at the end of the segment contains the
information needed to determine the location of the record and perform
an evaluation of the record corresponding to a particular epoch.
polynomial degree = ( RSIZE/3 - 2 )Define the angles as:
angle * ASCALE = ( RA + pi/2 )
1
angle * ASCALE = ( pi/2 - DEC )
2
angle * ASCALE = ( W )
3
The structure of each record:
--------------------------------------------------------------- | (polynomial degree + 1) coefficients for the rate of | | angle 1 | --------------------------------------------------------------- | value of angle 1 at interval midpoint | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for the rate of | | angle 2 | --------------------------------------------------------------- | value of angle 2 at interval midpoint | --------------------------------------------------------------- | (polynomial degree + 1) coefficients for the rate of | | angle 3 | --------------------------------------------------------------- | value of angle 3 at interval midpoint | ---------------------------------------------------------------The rate coefficients have units of ASCALE radians/TSCALE seconds: multiplying a Chebyshev expansion's value by ASCALE/TSCALE converts angular rates to units of radians/s. Euler angles at a record's midpoint epoch are given in units of ASCALE radians: multiplying the angles by ASCALE converts the angles to units of radians. The Euler angles represent the orientation of the PCK reference frame relative to its base frame. The angles, which are numbered according to their ordinal position in the logical records, define a transformation matrix R as follows:
R = [ angle *A ] [ angle *A ] [ angle *A ]
3 3 2 1 1 3
where A is the angular scale ASCALE. Here the notation
[ THETA ]
i
denotes a reference frame rotation of THETA radians in the right-hand
sense about the ith coordinate axis. See the Rotation Required Reading
for further discussion of this notation.
Creating Binary PCKs
Only very knowledgeable users who need to incorporate new planetary/satellite orientation information in binary format should consider writing binary PCK files. Users who write binary PCK files must have a thorough understanding of the information they wish to place in a binary PCK file. They must also master the high level structure of the PCK files, and they must be sure to correctly package the data for the PCK writing subroutines provided in CSPICE. We also strongly recommend that the writer of a PCK file include descriptive comments in the comment area. The user should keep in mind that the PCK segments should be as large as possible to create smaller, faster to load files. The are generally three steps to creating a binary PCK file.
pckopn_c ( file, ifname, i, &handle );The method for beginning the segment, adding data to the segment and closing the segment differs with the PCK type. For type 2, CSPICE includes a segment writing routine called pckw02_c. This routine takes as input arguments the handle of an PCK file that is open for writing, the information needed to construct the segment descriptor, and the data to be stored in the segment. The header of the subroutine provides a complete description of the input arguments and an example of its usage. An example of a call to pckw02_c:
pckw02_c ( handle, clssid, frame, first, last, segid, intlen, n, polydg, cdata, btime );For type 3, there are three subroutines used in creating a binary PCK file. They are pck03b_, which begins a type 3 segment, PCK03A, which adds data to segment, and pck03e_, which ends a segment. The type 3 subroutines can be used in a loop, where pck03a_ is called to add data to the segment. Here is a code fragment that begins a type 3 segment, writes data to that segment in a loop, and then closes the segment.
pck03b_ ( &handle, segid, &body, frame, &first, &last,
chbdeg , strlen(segid), strlen(frame));
do
{
...
pck03a_ ( &handle, &n, coeffs, epochs);
...
} while ( <a condition> );
pck03e_ ( &handle);
For type 20, CSPICE includes a segment writing routine called pckw20_.
takes as input arguments the handle of a PCK file that is open for
writing, the information needed to construct the segment descriptor, and
the data to be stored in the segment. The header of the function
provides a complete description of the input arguments and an example of
its usage.
An example of a call to pckw20_:
pckw20_ ( &handle, &clssid, frame,
&first, &last, segid, &intlen,
&n, &polydg, &cdata, &ascale,
&tscale, &initjd, &initfr,
strlen(frame), strlen(segid) );
When a user finishes writing segments of any type to a binary PCK, the
PCK must be closed with the subroutine pckcls_c.
pckcls_c( handle ); PCK Software
Getting PCK Data into Your Program
It is also wise to avoid designing data processing systems that effectively place PCK loading in a tight loop by requiring repeated runs of programs that expend a significant fraction of their run time on loading PCK files. If a program loads PCK files, it is preferable that it do all of its processing in a single run, or at least in a small number of runs, rather than carry out its processing by being re-run a large number of times: the former design will greatly reduce the ratio of the time the program spends loading PCKs to the time it spends on the rest of its data processing. Loading Text PCK Kernels
furnsh_c ( "example_pck.tcp" );File names supplied to furnsh_c will generally be system-dependent. It is good programming practice to not use hard-coded file names in calls to furnsh_c. Instead, applications should obtain kernel file names by one of the following methods:
Each time a text PCK is loaded, the assignments made in the file are maintained in the PCK software. In particular, if a kernel variable occurs in multiple PCKs loaded in a single run of a program, the value of the variable will be the one assigned in the following priority: last binary PCK file loaded, previously loaded binary PCK files, then last loaded text PCK files followed by previously loaded text PCK files. All binary PCK files take precedence over text PCK files. Within the binary and/or text file groups, the last loaded files takes precedence. Loading Binary PCK Kernels
furnsh_c ( "example_binary_pck.tcp" );Once an PCK file has been loaded, it may be accessed by the PCK software. Each set of constants is computed from a distinct segment. A PCK file may contain any number of segments. In fact, the same file may contain overlapping segments: segments containing data for the same body over a common interval. When this happens, the latest segment in a file supersedes any competing segments earlier in the file. Similarly, the latest file loaded supersedes any earlier files. In effect, several loaded files become equivalent to one large file. Binary PCK files take precedence over text PCK files. Unloading Binary PCK Kernels
unload_c ( "example_binary_pck.tcp" ); Binary PCK Coverage Summary Routines
The pckfrm_c function provides an API via which an application can find the set of reference frames for which a specified binary PCK file contains data. The reference frame class ID codes are returned in a SPICE ``set'' data structure (see sets.req). The pckcov_c function provides an API via which an application can find the time periods for which a specified binary PCK file provides data for a reference frame of interest. The coverage information is a set of disjoint time intervals returned in a SPICE ``window'' data structure (see windows.req). Refer to the headers of pckfrm_c and pckcov_c for details on the use of those routines. Access Routines
All of the routines listed here make use of the orientation models discussed in the section titled ``Orientation Models used by PCK Software.'' Note that in order to use these routines, an application must first load a PCK file (or files) containing sufficient data to define all of the required orientation models. If needed data has not been loaded, these routines will signal run-time errors when called. High-Level PCK Data Access
pxform_c ( from, to, et, rotate );In the argument list for pxform_c:
rotate = [ W ] [ Pi/2 - DEC ] [ Pi/2 + RA ]
3 1 3
To directly retrieve these angles, use the call:
bodeul_ ( &body, &et, &ra, &dec, &w, &lambda );
CSPICE provides a routine analogous to pxform_c that returns the matrix to transform state vectors between reference frames for a particular time. This routine is called sxform_c; the calling sequence being
sxform_c ( from, to, et, rotate );The input arguments ``from'', ``to'', and ``et'' have the same meanings as in the argument list of pxform_c. The output argument ``rotate'' is the 6x6 matrix required to transform state vectors from inertial to body-fixed coordinates. Left multiplication of a state vector by ``rotate'' will transform it from the frame specified by ``from'' to the frame specified by ``to'' at time ``et''. Low-Level PCK Data Access
The lowest-level CSPICE PCK access routines are gipool_c, gdpool_c and gcpool_c. These are general-purpose routines for retrieving any text kernel data by data type (integer, double precision, and character string, respectively) loaded via furnsh_c. The calling sequences for the routines:
gcpool_c ( name, start, room, lenout, &n, vals, &found ); gdpool_c ( name, start, room, &n, vals, &found ); gipool_c ( name, start, room, &n, vals, &found );The meanings of the arguments are follows:
In text PCKs produced by NAIF, PCK variables will have names conforming to the naming convention used in CSPICE, that is, the kernel variable names have the form
BODYnnn_<item name>bodvrd_c and bodvcd_c retrieve the values of such variables from the kernel pool; bodvrd_c accepts as inputs the body name and a string making up the portion of the item's name following the prefix:
bodvrd_c ( bodynm, item, maxn, &dim, values );bodvcd_c functions in the same manner as bodvrd_c except bodvcd_c accepts as inputs the body NAIF ID and the string, ``item'', as described for bodvrd_c:
bodvcd_c ( bodyid, item, maxn, &dim, values );It is possible to test whether a kernel variable has been loaded by calling the CSPICE logical function bodfnd_c, as long as the variables in question follow the CSPICE naming convention. The calling sequence is
found = bodfnd_c ( body, item );where body is the NAIF integer code of the body, and ``item'' is the string making up the portion of the item's name following the prefix
BODYnnn_ Appendix A --- Summary of PCK Routines
bodeul_ ( Return Euler angles for a body ) bodfnd_c ( Find values from the kernel pool ) bodvcd_c ( Return d.p. values from the kernel pool ) bodvrd_c ( Return d.p. values from the kernel pool ) furnsh_c ( Furnish a program with SPICE kernels ) gcpool_c ( Get character data from the kernel pool ) gdpool_c ( Get d.p. values from the kernel pool ) gipool_c ( Get integers from the kernel pool ) pck03a_ ( PCK, add data to a type 3 segment ) pck03b_ ( PCK, begin a type 3 segment ) pck03e_ ( PCK, end a type 3 segment ) pckcls_c ( PCK, close file ) pckcov_c ( PCK, coverage ) pcke02_ ( PCK, evaluate data record from type 2 segment ) pcke03_ ( PCK, evaluate data record from type 3 segment ) pcke20_ ( PCK, evaluate data record from type 20 segment ) pckeul_ ( PCK, get Euler angles at time from PCK file ) pckfrm_c ( PCK, get reference frame class ID set ) pcklof_c ( PCK Kernel, Load binary file ) pckopn_c ( PCK, open new file ) pckr02_ ( PCK, read record from type 2 segment ) pckr03_ ( PCK, read record from type 3 segment ) pckr20_ ( PCK, read record from type 20 segment ) pcksfs_ ( PCK, select file and segment ) pckuof_ ( PCK Kernel, Unload binary file ) pckw02_c ( PCK, write type 2 segment ) pckw20_ ( PCK, write type 20 segment ) pxform_c ( Position Transformation Matrix ) sxform_c ( State Transformation Matrix ) unload_c ( Unload a kernel ) Appendix B --- Epoch and Frame Specifications in Text PCK Kernels
The default epoch and inertial base frame for a body are overridden by setting the values of either of the kernel variables
BODY<id code>_CONSTANTS_REF_FRAME BODY<id code>_CONSTS_REF_FRAMEand
BODY<id code>_CONSTANTS_JED_EPOCH BODY<id code>_CONSTS_JED_EPOCHThe shorter forms of the kernel variable names enable use of 11-character ID codes, which can represent any 32-bit signed integer, while keeping the names within the 32-character limit imposed by CSPICE. Here
<id code>is:
BODY<id code>_CONSTANTS_REF_FRAME BODY<id code>_CONSTS_REF_FRAMEare the frames IDs for the inertial reference frames coded into the Frames subsystem. Refer to the Frames Required Reading document, frames.req, for a list of the inertial reference frames and the corresponding frame IDs. For example, to use constants referenced to the FK4 frame (frame ID 3) for the asteroid Gaspra (ID code = 9511010), the PCK file containing the constants should include one of the assignments
BODY9511010_CONSTANTS_REF_FRAME = 3 BODY9511010_CONSTS_REF_FRAME = 3The values of the epoch specifier variables
BODY<id code>_CONSTANTS_JED_EPOCH BODY<id code>_CONSTS_JED_EPOCHare Julian ephemeris dates. To use constants for Gaspra referenced to the J1950 epoch, the PCK file containing the constants should include one of the assignments
BODY9511010_CONSTANTS_JED_EPOCH = 2433282.5 BODY9511010_CONSTS_JED_EPOCH = 2433282.5The creator of a PCK file can set the frame and epoch of the constants on a body-by-body basis, except in the case of planets and their (natural) satellites, where a single choice of frame and epoch must be used for each planetary system. For example, to use constants referenced to the B1950 frame (frame ID 2) and J1950 epoch for the Earth and Moon, use the assignments
BODY3_CONSTANTS_REF_FRAME = 2
BODY3_CONSTANTS_JED_EPOCH = 2433282.5
or
BODY3_CONSTS_REF_FRAME = 2
BODY3_CONSTS_JED_EPOCH = 2433282.5
The ID code `3' designates the Earth-Moon barycenter.
Note: the assignments
BODY399_CONSTANTS_REF_FRAME = 2
BODY399_CONSTANTS_JED_EPOCH = 2433282.5
or
BODY399_CONSTS_REF_FRAME = 2
BODY399_CONSTS_JED_EPOCH = 2433282.5
would be ignored by the PCK reader routines; you cannot assign a frame
or epoch using the ID code of a planet or satellite.
Appendix C --- Revision History2021 DEC 24 by N.J. Bachman
Added documentation of extended nutation precession angle polynomial capability. Deleted summary of calling sequences. Updated summary of PCK routines. Added subsection discussing possible offsets of reference ellipsoid axes from the corresponding PCK frame, and handling this situation via TK frames. Added description of nutation precession angle coefficient units. Changed description of segment descriptor ID from ``body ID'' to ``frame class ID.'' Changed names of arguments in calling sequence documentation to match. Updated description of PCK ID word to say this string must start in the leftmost column. Removed unnecessary parentheses from kernel variable assignment examples. 2013 JAN 22 by E. D. Wright, C. H. Acton
Eliminated Examples section. Corrections to text eliminating typos in the code call examples. Update to document structure to include Revision History. The document now includes description of Icy, and Mice PCK APIs. 2010 JUN 03 by B. V. Semenov.
Original version K.R. Gehringer, K. S. Zukor
|