SDK Question How to calculate Sun elevation

[cristiapi]

Looking carefully at those definitions, I'm pretty sure that my x-y-z co-ordinate system matches those definitions - at least, in the principle of what is going on. So it is a little disturbing that there is still a sizeable difference.

However, there may be some subtle differences in interpretation in calculating instantaneous angular momentum, e.g.:

1. When calculating the instantaneous angular momentum vector, should one subtract off the Sun's instantaneous position/velocity; or should one reference the Solar System barycentre - i.e., the global coordinate system's origin (0,0,0)?

The former.

2. Does SPICE use mean orbital elements to calculate the Sun's position - or does it use a full ephemeris solution?

The latter. The data files used to calculate the geometric state of the bodies consists of many Chebyshev polynomials fitted to the numerical integration (the difference could range from sub-meter to 100 m for Neptune system).

2. Does Orbiter use the same spin axes for bodies as SPICE?

The problem is almost surely here.

SPICE uses PCK data (text) file (currently: "pck00010.tpc") which contains the orientation and size/shape data for natural bodies.
We can bet that the spin exes are different, but do know a method to see those differences?


Here is how SPICE calculate Ls (the procedure seems terribly complicated to me, but you probably understand all the steps):

1) Calculate a 3x3 matrix that transforms positions in inertial coordinates to positions in body-equator-and-prime-meridian coordinates [this should be NPOLE at step 4].

2) Get the geometric state of the body relative to the Sun.

3) Get the unit direction vector UAVEL parallel to the angular velocity vector of the orbit. This is just the unitized cross product of position and velocity.

4) We want to create a transformation matrix that maps vectors from basis REF [the global frame] to the following frame:

Z = UAVEL
X = NPOLE x UAVEL
Y = Z x X

Calculate TRANS, the transformation matrix. A "two-vector" frame with the unit orbital angular velocity vector UAVEL as the primary vector and the spin axis NPOLE as the secondary vector. The primary vector is associated with the +Z axis; the secondary vector is associated with the +Y axis.

5) Get the state of the Sun in global frame and transform the position of the Sun into the "orbit plane and equinox" frame; we get POS.

6) Convert POS (rectangular coordinates) to range, right ascension, and declination.

Ls it the right ascension.

 

[Keithth G]

Yes, I think the problem lies in the orientation of the rotation axes.

1) Calculate a 3x3 matrix that transforms positions in inertial coordinates to positions in body-equator-and-prime-meridian coordinates [this should be NPOLE at step 4].

2) Get the geometric state of the body relative to the Sun.

3) Get the unit direction vector UAVEL parallel to the angular velocity vector of the orbit. This is just the unitized cross product of position and velocity.

4) We want to create a transformation matrix that maps vectors from basis REF [the global frame] to the following frame:

Z = UAVEL
X = NPOLE x UAVEL
Y = Z x X

Calculate TRANS, the transformation matrix. A "two-vector" frame with the unit orbital angular velocity vector UAVEL as the primary vector and the spin axis NPOLE as the secondary vector. The primary vector is associated with the +Z axis; the secondary vector is associated with the +Y axis.

5) Get the state of the Sun in global frame and transform the position of the Sun into the "orbit plane and equinox" frame; we get POS.

6) Convert POS (rectangular coordinates) to range, right ascension, and declination.

Ls it the right ascension.

This is almost exactly the algorithm I have used. Differences are in the order in which some of the components are calculated; and that Orbiter uses a left-handed rather than right-handed coordinate system.

Spot checks for Earth
Since the spin axis of Earth is well known, and solstice and equinox dates are tabulated for many years with high accuracy, I did some spot checks for the year 2010 using my algorithm:

For the Spring Equinox, 2010, the error in solar longitude was 1 arc second. For the Summer solstice, the error was 7 arc seconds; and for the Autumn equinox, the error was again 1 arc second.

Since the tabulated times available for the solstices and equinoxes was only tabulated to the nearest minute, these small angular differences can easily be attributed to the lack of precision with which the times of the equinoxes and solstices was given.

I also did some spot checks of the spin axis for Mars. As yet, I can't get any alignment with tabulated values. I may have a look at this again tomorrow.