# SPICE module

#### Ajaja

##### Active member
I'm trying to add support for SPICE ephemerides to Orbiter.
First results here: [ame="http://www.orbithangar.com/searchid.php?ID=3329"]SPICE ephemeris module[/ame]

SPICE is NASA's library for archiving data for space missions - spacecrafts, planets, satellites positions, orientations, and other data. In Orbiter it may be useful for computing high-precision positions and velosity of planets/moons.

pluto.cfg
Code:
; === Configuration file for Pluto ===
Name = Pluto
Module = spice
Kernel = F:\Kernels\plu017.bsp
;from ftp://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/satellites/plu017.bsp
Body = PLUTO
Origin = SUN
Barycenter = PLUTO BARYCENTER

; === Physical Parameters ===
Mass = 1.30948769129e22          ; PLU017 GM=873.7674473980320 km^3/s^2
Size = 1.153e6                   ; mean radius
LAN = 3.9851775285
Obliquity = 1.1239564457
SidRotOffset = 3.4371983592
SidRotPeriod = -551858.0547416967

; === Visualisation Parameters ===
AlbedoRGB = 0.3 0.3 0.3
MaxPatchResolution = 8           ; highest sphere patch level

charon.cfg
Code:
; === Configuration file for Charon ===
Name = Charon
Module = spice
Kernel = F:\Kernels\plu017.bsp
;from ftp://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/satellites/plu017.bsp
Body = CHARON
Origin = PLUTO
Barycenter = CHARON

; === Physical Parameters ===
Mass = 1.54595148805e21          ; PLU017 GM=103.1550043961694 km^3/s^2
Size = 603.5e3                   ; mean radius
LAN = 3.9851775285
Obliquity = 1.1239564457
SidRotOffset = 0.2956057056
SidRotPeriod = -551858.0547416967

; === Visualisation Parameters ===
AlbedoRGB = 0.37 0.37 0.37
MaxPatchResolution = 7           ; highest sphere patch level

Last edited:

#### Chode

Beta Tester
I've already started testing this, and so far it looks very good!

I looked specifically at Triton, since I wrote the dll for it in the current Orbiter version, and this SPICE module appears to give a more accurate and up-to-date position for Triton than my dll. This is not really un-expected, since the latest spice kernels from JPL use more recent data than I had when writing the dll.

The ability to import spice kernels for celestial bodies into Orbiter would be a nice feature to have, since it allows you to update the kernels as better ones are made available, independent of the Orbiter version updates.

For spacecraft, this module could potentially allow you to go to any point in the mission, and have your spacecraft at it's historical position and velocity.

Nice work!

Regards

P.S. I plan to continue testing and report on my results.

#### Urwumpe

##### Not funny anymore
Donator
Very nice idea. Maybe some support for spice kernels could also be useful for making vessels.

How about creating the whole solar system by spice kernels instead of the classic ephemeris files? Does somebody already know if SPICE is more accurate when dealing with the moon?

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
This is interesting. But I still need to study the SPICE much more closely. I have been working with my CFlight project http://koti.mbnet.fi/jarmonik/cflight/ and the SPICE could be usefull in that as well. Unless it makes my project obsolete.

Any ideas how much CPU power the SPICE requires in order to compute a state vectors ? Let's say that... How many times per a second an average home computer can compute the state vectors of the Venus using the SPICE ?

Does the SPICE have anything to do with the Horizons ?

#### Ajaja

##### Active member
Any ideas how much CPU power the SPICE requires in order to compute a state vectors ? Let's say that... How many times per a second an average home computer can compute the state vectors of the Venus using the SPICE ?
I use SPICE-library function spkgeo_c(...) in the module. On my CoreDuo 4300 (1.80GHz) 10'000'000 calls of spkgeo_c to compute the state vectors of the Venus relative to Sun (using kernel DE421.BSP) take ~61 seconds (50% CPU - only one core was used in test).

Last edited:

#### martins

##### Orbiter Founder
Orbiter Founder
In the orbiter ephemeris modules, the full perturbation solutions for planetary state propagation are only calculated at fixed intervals (depending on curvature, speed and eccentricity, i.e. generally more frequently for the inner planets). In between, a much faster (hacked together) elliptic interpolation is used. I guess a similar approach could be used here. If the full updates for the various celestial bodies are spread out so that they don't happen in the same frame, the load can be distributed smoothly.

#### Ajaja

##### Active member
I'm afraid, the memory lack will be primary problem, if the SPICE engine will be used with various huge kernels. By the way, are there some samples of these orbiter ephemeris modules source code?

P.S.
I was wrong. There is no problems with memory I loaded into Orbiter HUGE kernel DE408.BSP (~1Gb) - it takes only few megabytes in memory.
Also I compared speed of spkgeo_c function with another SPICE routine - conics_c (determine the state of an orbiting body from a set of elliptic, hyperbolic, or parabolic orbital elements). Conics_c is SLOWER in most tests!!! It win only few seconds in the test with huge DE408-kernel (because spkgeo_c reads a lot of data from hard disk - I set whole interval of the kernel - from 10020 B.C. MAY 26 to 10009 MAY 21).
Source code, I used for test:
Code:
int _tmain(int argc, _TCHAR* argv[])
{
SpiceDouble state[6];
SpiceDouble elts[8];
SpiceDouble lt;
SpiceDouble et1,et2;
SpiceDouble det,dummy=0.0;
clock_t start, finish;

furnsh_c ( "DE408.bsp" );
furnsh_c ( "naif0008.tls" );

//set interval and step
str2et_c ( "10020 B.C. MAY 26 TDB", &et1 );
str2et_c ( "10009 MAY 21 TDB", &et2 );
det=(et2-et1)/10000000.0;

//Determine the set of osculating conic orbital elements that
//corresponds to the state of a body
spkgeo_c ( 299, et1, "ECLIPJ2000",  10, state,  &lt);
oscelt_c(state, et1 ,132712440041.94,elts);

start = clock();
for (SpiceDouble eti=et1;eti<et2;eti+=det)
{
spkgeo_c ( 299, eti, "ECLIPJ2000",  10, state,  &lt);
dummy+=state[0]+state[1]+state[2]+state[3]+state[4]+state[5];  //to avoid loop-optimization
}
finish = clock();
printf("%en",dummy);
printf("%fn",(double)(finish-start)/CLOCKS_PER_SEC );
start = clock();
for (SpiceDouble eti=et1;eti<et2;eti+=det)
{
conics_c(elts,eti,state);
dummy+=state[0]+state[1]+state[2]+state[3]+state[4]+state[5]; //to avoid loop-optimization
}
finish = clock();
printf("%en",dummy);
printf("%fn",(double)(finish-start)/CLOCKS_PER_SEC );

return 0;
}

Last edited:

#### Chode

Beta Tester
Does the SPICE have anything to do with the Horizons ?

As far as I can tell, the group that makes the spice kernals distributed through NAIF (de421, nep068, etc.) is the same group that runs Horizons (the Solar System Dynamics group at JPL). It looks to me that they use these spice files to do the calculations that you get from Horizons.

Regards

#### Chode

Beta Tester
I've done some more testing and I have an interesting result.
In order to directly compare the positions given by the new Spice
module with the default Orbiter positions, I created a Sol.cfg
with two Earths, the second Earth having it's position calculated
with the Spice module and spice kernel de421. I then wrote a little program
that calls both of the Ephemeris functions about 1400 times within the time
frame of 1950 to 2007, writing the difference vector to a file. Over this
entire timeframe, the two positions remain less than about 90 km apart.

What I found is that there is a "systematic" difference between the two positions,
where the Spice position consistently trails the Orbiter Earth position by about
64 km in it's orbit. I'm not sure why this should be, but one possibility I can
think of is that the two time bases are off by about 2 seconds (the time it takes
the Earth to travel 64 km in its orbit).

If you remove this systematic error, then the Orbiter position stays within about
30 km of the Spice position. Since the stated accuracy of the Spice data is
sub-kilometer, this means that the error in the orbiter position for Earth is on the
order of 30 km.

Regards

#### James.Denholm

Out of curiosity, will this need a constant internet connection to run?

Edit: That's a stupid question. Better: Will this need an occasional internet connection.

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
I then wrote a little program
that calls both of the Ephemeris functions about 1400 times within the time frame of 1950 to 2007, writing the difference vector to a file. Over this entire timeframe, the two positions remain less than about 90 km apart.

What I found is that there is a "systematic" difference between the two positions, where the Spice position consistently trails the Orbiter Earth position by about 64 km in it's orbit. I'm not sure why this should be, but one possibility I can think of is that the two time bases are off by about 2 seconds (the time it takes the Earth to travel 64 km in its orbit).

That is very accurare. But Speaking of that 2 seconds. I do remember hearing a news about "re-calibration" of a time reference of somesort. If I remember correctly it counted 2 extra seconds for that day. About 1-2 years ago. Well, This may not have anything to do with the issue here. But maybe something worth of checking ?

#### Ajaja

##### Active member
Chode
You are right. It's good to see in Orbiters camera mode with reduced size of Earths (to 10 kilomiters, for example). But I do not know why does it happen.
I've updated SPICE module on orbithangar. Some small fixes, and I've included source code into archive.

James.Denholm
Addon need only SPICE-kernels (defined in *.cfg). Program do not connect to internet itself. You must download necessary files from ftp manualy.

Last edited:

#### Chode

Beta Tester
That is very accurare. But Speaking of that 2 seconds. I do remember hearing a news about "re-calibration" of a time reference of somesort. If I remember correctly it counted 2 extra seconds for that day. About 1-2 years ago. Well, This may not have anything to do with the issue here. But maybe something worth of checking ?

I think that leap seconds may be the cause of the discrepency. Ephemeris time and UTC do not stay in sync over time. UTC is corrected from time to time by adding a leap second. Leap seconds were added Dec 31 2005, Dec 31 1998, June 30 1997, etc. I'm figuring Orbiter does not account for these leap seconds in converting from UTC to ephemeris time.

To get to the bottom of this, we need to know how Orbiter calculates ephemeris time from UTC or MJD, and how Ajaja does it. Also, we need to know how ephemeris time is defined for the two ephemerides.

Regards

#### Urwumpe

##### Not funny anymore
Donator
In Orbiter it is MJD, not UTC, for the basic ephemeris time. I don't know if it is converted inside the planet modules of Orbiter. MJD does not have leap seconds.

But orbiters UTC calculations might lack leap seconds - also the future leap seconds are not known.

#### Ajaja

##### Active member
I use oapiTime2MJD(simt). Problem is not in leap seconds. They were changing from 10 sec. in 1972 to 33 sec. in 2006, whereas 2 seconds difference between SPICE and Orbiter ephemeris is stable.

#### Chode

Beta Tester
Here's what I'm thinking:

Let's say you make an ephemeris, where you define time as the number of seconds from Jan 1 2000, 0h UTC. This would be a natural place to fix the zero point of time in your ephemeris. Now, let's say you are creating this ephemeris in 1996. You would not know exactly how many seconds will elapse between Jan 1, 1996 0h and Jan 1, 2000 0h, so you would assume it to be just the number of days * 86400. This ephemeris would have a constant 2 second discrepency with an ephemeris created after Jan 1, 2000, since that would be based on the actual moment in time of Jan 1, 2000 0h, which would be 2 seconds different than the earlier ephemeris.

EDIT: the 2 seconds difference comes from the 2 leapseconds added to UTC in the interval 1996 to 2000, in 1997 and 1998.

Regards

Last edited:

#### Chode

Beta Tester
I've done more investigating about "ephemeris time" and how is defined for Spice and Horizons, and found that the correct conversion between ephemeris time and UTC is:

ET = UTC + DELTA_T_A + DELTA_AT
(relativistic correction not included)

where DELTA_T_A is equal to 32.184 and DELTA_AT is equal to 10 plus the number of leap seconds added since Jan 1, 1972, when they started adding them.

A description of this can be found in the spice file naif0008.tls.

So that means today, UTC is 65.184 seconds behind ephemeris time.

This doesn't explain the consistent error between the Orbiter and Spice ephemerides, however.

Regards

#### Ajaja

##### Active member
Error between default Orbiter and Spice ephemerides for Sun position relative to Solar System Barycenter (0,0,0) much more bigger (~1400Km). Very strange...

I've updatet SPICE module to v0.3 on Orbithangar. Now "Barycenter" parameter means barycenter of object (if it has sattelites, if it hasn't - use name of the object). Added optional "ParentBarycenter" parameter, it used only for computing of elliptical orbit befor/after SPICE ephemeris interval. But some problems with this option remains - seems like Orbiter can not process correctly EPHEM_BARYPOS|EPHEM_BARYVEL|EPHEM_PARENTBARY response?
Also, I've added *.cfg for all default orbiter bodyes (including Sun) with modyfied orientations (used IAU orientations at J2000 from pck00008.tpc).
Source code included (by the way, source code of SPICE library available here: ftp://naif.jpl.nasa.gov/pub/naif/toolkit//C/PC_Windows_VisualC_32bit/packages/cspice.exe).

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester

#### Ajaja

##### Active member
I want to add into module ability to compute approximate elliptical trajectories over the kernel interval. But without EPHEM_PARENTBARY it's not possible

For example. Let's take Pluto system. For major body (Pluto) module return EPHEM_BARYPOS|EPHEM_BARYVEL|EPHEM_PARENTBARY (trajectory of PLUTO BARYCENTER around SSB), based on elliptical orbit, computed from position/velocity at ends of kernel interval and specified GM. For Charon/Nix/Hydra it returns EPHEM_TRUEPOS|EPHEM_TRUEVEL|EPHEM_BARYPOS|EPHEM_BARYVEL|EPHEM_BARYISTRUE|EPHEM_PARENTBARY (trajectory of moons around PLUTO BARYCENTER). Seems like Orbiter has all data to compute Pluto position (masses of all bodyes in *.cfg) - but Pluto appears at PLUTO BARYCENTER

Replies
2
Views
3K
General Question Making celestial bodies
Replies
1
Views
1K
Replies
6
Views
3K
Replies
1
Views
2K
Replies
5
Views
1K