[Spice_discussion] spkezr vs Geocentric Solar Ecliptic (GSE) Frame

Nat Bachman nathaniel.bachman at jpl.nasa.gov
Fri Jan 29 21:03:59 PST 2016


Folks,

Hello, this is from Nat Bachman. I'm a member of the
NAIF team at JPL and am the author of the SPICE
dynamic frames software subsystem. This note is
about the definition of the GSE frame, SPICE documentation,
and the questions from Donald Linton.

GSE frame definition
====================

The GSE frame definition presented in the SPICE documentation
is based on instantaneous geometry: it uses the velocity of
the sun relative to the earth as the secondary vector of
the frame. (Note that a "secondary vector" is not a basis
vector: the component of the secondary vector orthogonal
to the primary vector is a basis vector. All frames implemented
in SPICE frame kernels have right-handed, orthonormal bases.)

This GSE definition was based on a request from scientists using
SPICE on the NASA Galileo mission.

The instantaneous GSE frame has some desirable properties:

   - It satisfied the original users

   - Its orientation is close to that achieved via more
     complicated definitions

   - Computation of the frame orientation is relatively fast

   - It doesn't rely on another dynamic frame, so it can be
     referenced in another dynamic frame definition

   - It is easy to describe

Of course these advantages are immaterial for a given user
if the frame definition's wrong for that user.

It seems that over time (starting with a spice_discussion
posting by William Thompson in 2005, but especially
today!), evidence has mounted that this definition is not
the one preferred by SPICE users.

All of the "non-SPICE" GSE definitions I've seen so far use
the northern normal to the mean ecliptic plane of date,
but there are differences in the way it's used: the Mars Express
frames kernel

    ftp://naif.jpl.nasa.gov/pub/naif/MEX/kernels/fk/RSSD0002.TF

makes the ecliptic normal primary, whereas the STEREO and
Van Allen probe definitions make the earth-sun vector
primary.

The ECLIP_DATE and MEAN_ECLIP frames whose definitions I've
seen in various emails have equivalent geometric definitions.
These frames have the mean ecliptic of date as their X-Y plane
and the ascending node of mean ecliptic plane on the mean earth
equatorial plane as their +X axis direction. The models used
to define these "mean" planes are named in the frame definitions
within the respective frame kernels. Note that the frame family
name

    MEAN_ECLIPTIC_AND_EQUINOX_OF_DATE

is an abbreviation: a more verbose and accurate name would be

    "mean ecliptic and mean equinox of date"

One can think of the word "mean" distributing (syntactically)
over "ecliptic" and "equinox." :)

As described above, the direction of the "mean equinox" is
determined using the earth's mean, rather than true, equator.
Nutation is not used.

I've attached plots showing comparisons between GSE frame
orientations. Each plot expresses a relative rotation
between frames as a single rotation angle (see the
SPICE routine RAXISA for details). Based on a sampling
step of 10 days, we can see that over the time period

    2000 - 2030

the rotation between the instantaneous GSE frame and
the Mars Express GSE frame has a maximum angle of under

    45 microradians

The rotation between the Mars Express GSE frame and the
STEREO GSE frame has a maximum angle of under

    6 microradians


SPICE documentation
===================

NAIF has no reason to advocate for a particular GSE definition.
In my opinion, there's some value in understanding
that different definitions exist, and a great deal of value
in coordinating with one's colleagues on any particular project.

I suggest that NAIF update our documentation of the GSE
frame to say that there are multiple definitions in use. We
should present as an example at least one GSE implementation.
We can withdraw discussion of the "instantaneous" GSE definition
altogether or present it as a simplified alternative to
the more common definitions. In any case we can recommend
that SPICE users adopt the conventions of their project,
whenever this is applicable. Often this can be done in software
simply by loading the project's frames kernel.

The NAIF team will discuss this. SPICE users are welcome
to comment.


Donald's questions
==================

I've sent a detailed answer to Donald, as has William Thompson.

To summarize: the effect of the eccentricity of the orbit of
the earth-moon system about the sun is substantial:
the earth-sun distance varies by a few million km over 1 orbit.
In addition the orbit of the earth about the earth-moon
barycenter contributes to the non-circular character of the
earth's orbit about the sun. So the range rate (derivative
of distance with respect to time) of the sun relative to
the earth is non-zero, at all but a discrete set of times.

Distance and range rate (unlike velocity) are invariant
with respect to transformation between orthonormal bases.
Whatever range rate one can compute in an inertial frame
will be found in any version of the GSE frame as well.
For that matter, one could replace GSE with 'IAU_JUPITER'
(Jupiter body-fixed). The choice of frame center and the frame
orientation play no role in the range rate computation.

Any GSE frame definition for which the earth-sun vector
is the primary axis (all but the MEX GSE definitions)
has the nice property that the earth-sun range rate appears
as the X velocity component of the earth-sun state vector,
expressed in the GSE frame. This benefit can't be obtained
if one replaces GSE with the IAU_JUPITER frame.

   -Nat


On 01/29/16 07:24, William T Bridgman wrote:
> A tf file for the Van Allen probes has a different definition to build GSE:
>
>         \begindata
>
>         FRAME_GSE                    = -362930
>         FRAME_-362930_NAME           = 'GSE'
>         FRAME_-362930_CLASS          = 5
>         FRAME_-362930_CLASS_ID       = -362930
>         FRAME_-362930_CENTER         = 399
>         FRAME_-362930_RELATIVE       = 'J2000'
>         FRAME_-362930_DEF_STYLE      = 'PARAMETERIZED'
>         FRAME_-362930_FAMILY         = 'TWO-VECTOR'
>         FRAME_-362930_PRI_AXIS       = 'X'
>         FRAME_-362930_PRI_VECTOR_DEF = 'OBSERVER_TARGET_POSITION'
>         FRAME_-362930_PRI_OBSERVER   = 'EARTH'
>         FRAME_-362930_PRI_TARGET     = 'SUN'
>         FRAME_-362930_PRI_ABCORR     = 'NONE'
>         FRAME_-362930_SEC_AXIS       = 'Z'
>         FRAME_-362930_SEC_VECTOR_DEF = 'CONSTANT'
>         FRAME_-362930_SEC_SPEC       = 'RECTANGULAR'
>         FRAME_-362930_SEC_FRAME      = 'MEAN_ECLIP'
>         FRAME_-362930_SEC_VECTOR     = (0, 0, 1)
>
>         \begintext
>
> It defines the secondary as z-axis rather than y-axis.  I suspect your
> y-axis is not quite perpendicular to your x-axis which might be
> projecting some velocity in the x-direction.
>
> Tom
>
> On 1/27/16 7:33 PM, Donald F. Linton wrote:
>> I implemented the Geocentric Solar Ecliptic (GSE) Frame in the Frames
>> <http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/FORTRAN/req/frames.html#Specifying
>> a New Frame> reference:
>>
>> \begindata
>>      FRAME_GSE                       =  314101
>>      FRAME_314101_NAME           = 'GSE'
>>      FRAME_314101_CLASS          =  5
>>      FRAME_314101_CLASS_ID       =  314101
>>      FRAME_314101_CENTER         =  399
>>      FRAME_314101_RELATIVE       = 'J2000'
>>      FRAME_314101_DEF_STYLE      = 'PARAMETERIZED'
>>      FRAME_314101_FAMILY         = 'TWO-VECTOR'
>>      FRAME_314101_PRI_AXIS       = 'X'
>>      FRAME_314101_PRI_VECTOR_DEF = 'OBSERVER_TARGET_POSITION'
>>      FRAME_314101_PRI_OBSERVER   = 'EARTH'
>>      FRAME_314101_PRI_TARGET     = 'SUN'
>>      FRAME_314101_PRI_ABCORR     = 'NONE'
>>      FRAME_314101_SEC_AXIS       = 'Y'
>>      FRAME_314101_SEC_VECTOR_DEF = 'OBSERVER_TARGET_VELOCITY'
>>      FRAME_314101_SEC_OBSERVER   = 'EARTH'
>>      FRAME_314101_SEC_TARGET     = 'SUN'
>>      FRAME_314101_SEC_ABCORR     = 'NONE'
>>      FRAME_314101_SEC_FRAME      = 'J2000'
>> \begintext
>>
>> Using the epoch: 2017-07-01T00:00:00
>> et = 5.521392681841135e8
>>
>> sv = spkezr( "SUN", et, "J2000", "NONE", "EARTH" )
>>
>>    -2.41323e7  1.37774e8  5.97261e7  -28.9257  -4.24521  -1.83927
>>
>> then
>>
>> M = sxform("J2000", "GSE", et )
>>
>>    -0.158671     0.905874      0.392703     0.0          0.0        0.0
>>    -0.987331    -0.145594     -0.0630798    0.0          0.0        0.0
>>     3.26993e-5  -0.397737      0.9175       0.0          0.0        0.0
>>    -1.90166e-7  -2.80422e-8   -1.21495e-8  -0.158671     0.905874   0.392703
>>     3.0561e-8   -1.7445e-7    -7.56986e-8  -0.987331    -0.145594  -0.0630798
>>    -6.6631e-11  -9.82553e-12  -4.257e-12    3.26993e-5  -0.397737   0.9175
>>
>> M*SV yields
>>
>>    1.5209e8
>>    2.79397e-9
>>    7.45058e-9
>>    0.0217735
>>    6.64746e-15
>>    2.22045e-16
>>
>> I don't understand why I see 21.77 m/s of sunward velocity
>>
>>
>>
>>
>> _______________________________________________
>> Spice_discussion mailing list
>> Spice_discussion at naif.jpl.nasa.gov
>> https://naif.jpl.nasa.gov/mailman/listinfo/spice_discussion
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GSE_instant_vs_MEX.png
Type: image/png
Size: 124310 bytes
Desc: not available
URL: <http://naif.jpl.nasa.gov/pipermail/spice_discussion/attachments/20160129/9e2e9dae/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GSE_MEX_vs_STEREO.png
Type: image/png
Size: 113449 bytes
Desc: not available
URL: <http://naif.jpl.nasa.gov/pipermail/spice_discussion/attachments/20160129/9e2e9dae/attachment-0003.png>


More information about the Spice_discussion mailing list