SPICE
-
Topic authorchris
- Site Admin
- Posts: 4211
- Joined: 28.01.2002
- With us: 22 years 9 months
- Location: Seattle, Washington, USA
SPICE
I've added support for SPICE ephemerides to Celestia. SPICE is NASA's library for archiving data for space missions--spacecraft and planet positions, orientations, and other data.
SPICE is one of the easiest to use and best documented software libraries I've ever worked with. The documentation is comprehensive and very easy to read--a lot of it is worthwhile reading even if you're not writing code.
Here's how a SPICE orbit appears in an ssc file:
SpiceOrbit
{
Kernel "de403_2000-2020.bsp"
Target "Pluto Barycenter"
Origin "Sun"
BoundingRadius 40
Period 248.0
}
The Kernel field is the name of a SPICE kernel file containing
ephemeris data. There's a repository of SPICE kernels here:
ftp://naif.jpl.nasa.gov/pub/naif/
Celestia searches for SPICE kernels in an add-on's data directory.
Target is the name of the that the orbit is for; origin is the object
that the orbit will be referred to. The names are not Celestia SSC
names but standard NAIF name strings. There's a list here:
http://www.gps.caltech.edu/~marsdata/req/naif_ids.html
The reference plane for SpiceOrbits is always the J2000 ecliptic. For
moons, make sure that the OrbitReferencePlane is set to "ecliptic"
The BoundingRadius of the orbit needs to be supplied in order for
culling to work. As far as I can tell, there's no way to extract this
from the SPICE kernel file. Period is optional; it's used by Celestia
only for orbit path rendering. If it's set to zero or not given at
all, the orbit is assumed to be an aperiodic trajectory. The units for
BoundingRadius and Period are AU and years for bodies that directly
orbit a star, and kilometers and Earth solar days for other bodies.
The switch in units is for consistency with other Celestia orbits--I
wish I hadn't used two different unit systems in ssc files, but it's a
bit late to go back now.
The current implementation should not be considered final, and I
welcome suggestions for improvements to the SPICE orbit ssc
definition.
--Chris
SPICE is one of the easiest to use and best documented software libraries I've ever worked with. The documentation is comprehensive and very easy to read--a lot of it is worthwhile reading even if you're not writing code.
Here's how a SPICE orbit appears in an ssc file:
SpiceOrbit
{
Kernel "de403_2000-2020.bsp"
Target "Pluto Barycenter"
Origin "Sun"
BoundingRadius 40
Period 248.0
}
The Kernel field is the name of a SPICE kernel file containing
ephemeris data. There's a repository of SPICE kernels here:
ftp://naif.jpl.nasa.gov/pub/naif/
Celestia searches for SPICE kernels in an add-on's data directory.
Target is the name of the that the orbit is for; origin is the object
that the orbit will be referred to. The names are not Celestia SSC
names but standard NAIF name strings. There's a list here:
http://www.gps.caltech.edu/~marsdata/req/naif_ids.html
The reference plane for SpiceOrbits is always the J2000 ecliptic. For
moons, make sure that the OrbitReferencePlane is set to "ecliptic"
The BoundingRadius of the orbit needs to be supplied in order for
culling to work. As far as I can tell, there's no way to extract this
from the SPICE kernel file. Period is optional; it's used by Celestia
only for orbit path rendering. If it's set to zero or not given at
all, the orbit is assumed to be an aperiodic trajectory. The units for
BoundingRadius and Period are AU and years for bodies that directly
orbit a star, and kilometers and Earth solar days for other bodies.
The switch in units is for consistency with other Celestia orbits--I
wish I hadn't used two different unit systems in ssc files, but it's a
bit late to go back now.
The current implementation should not be considered final, and I
welcome suggestions for improvements to the SPICE orbit ssc
definition.
--Chris
- t00fri
- Developer
- Posts: 8772
- Joined: 29.03.2002
- Age: 22
- With us: 22 years 7 months
- Location: Hamburg, Germany
Chris,
good to see the start of all this great stuff so FAST!
Did you enter the same speed of light into astro.cpp as the SPICE guys use?
How about attending some neat Astrodynamics conference once a year in Europe? . I forsee a dramatic development speedup this way...
I read somewhere that they want your talk submitted by middle of September?
Bye Fridger
good to see the start of all this great stuff so FAST!
Did you enter the same speed of light into astro.cpp as the SPICE guys use?
How about attending some neat Astrodynamics conference once a year in Europe? . I forsee a dramatic development speedup this way...
I read somewhere that they want your talk submitted by middle of September?
Bye Fridger
One thing I'm troubled about here is the accuracy of SPICE data. I had to use this a lot when I was doing my PhD when processing ISIS images of Ganymede, and it was really painful - I know that the SPICE for Galileo and Voyager was awful, the camera pointing was totally wrong in the files that came with ISIS - I had to actually go straight to the guy whose job it was to compile the data and get corrected values from him. It was bad enough that if you used the default dataset to process image mosaid then you'd end up with badly warped/distorted results because ISIS thought the limb of the planet was somewhere totally different to where it actually was (because its coordinate system for reprojecting the images was wrong, because the planet wasn't where it thought it was). It was a nightmare.
Granted, this was largely the camera pointing info on the spaceprobes that was wrong, but I think the data for the locations of the satellites that they were looking at (and where the probes were) was out as well. This was about 6 or 7 years ago though, maybe things have improved since then...
Granted, this was largely the camera pointing info on the spaceprobes that was wrong, but I think the data for the locations of the satellites that they were looking at (and where the probes were) was out as well. This was about 6 or 7 years ago though, maybe things have improved since then...
My Celestia page: Spica system, planetary magnitudes script, updated demo.cel, Quad system
-
Topic authorchris
- Site Admin
- Posts: 4211
- Joined: 28.01.2002
- With us: 22 years 9 months
- Location: Seattle, Washington, USA
t00fri wrote:Chris,
good to see the start of all this great stuff so FAST!
Did you enter the same speed of light into astro.cpp as the SPICE guys use?
I didn't check, but it should be the same. There is very close agreement between SPICE ephemerides and the VSOP87 calculations that suggest everything is right. I'll be performing some more rigorous tests, however.
How about attending some neat Astrodynamics conference once a year in Europe? . I forsee a dramatic development speedup this way...
I read somewhere that they want your talk submitted by middle of September?
Correct . . . I may not have that much time for coding tonight
--Chris
-
Topic authorchris
- Site Admin
- Posts: 4211
- Joined: 28.01.2002
- With us: 22 years 9 months
- Location: Seattle, Washington, USA
hank wrote:Will the current CVS build successfully on Mac OS X with SPICE enabled?
Not yet, but I need to get this working soon, since I'll be bringing my Powerbook to present and demo Celestia for the ESA in a couple weeks. It should just be a matter of modifying the project files and downloading the Mac OS X CSPICE library from NAIF/JPL.
--Chris
I noticed that the celestia executable build with SPICE is pretty big.. ~2.4 MB for SPICE an 1.6 MB without.
is this normal? is there a way not to include the spicelib into the executable but load it like an external lib/dll ?
is this normal? is there a way not to include the spicelib into the executable but load it like an external lib/dll ?
most recent celestia win32-SVN-build - use at your own risk (copy over existing 1.5.1 release)
Chris has only just started integrating Spice. There's a lot more work to be done, although he hasn't revealed all of his plans
I'm sure that however it's done, Spice support will be an option. However, people who use it won't care about the size of the executable. Spice kernels are quite large, typically 2-3 MB for only a month of ephemerides for Cassini, Saturn and some of its moons. Some are much larger.
I'm sure that however it's done, Spice support will be an option. However, people who use it won't care about the size of the executable. Spice kernels are quite large, typically 2-3 MB for only a month of ephemerides for Cassini, Saturn and some of its moons. Some are much larger.
Selden
I've not felt any downsides of the big executable yet... just curious why it's so big.
also the spice-kernels are "addons" so a few megs won't matter compared to the gigabytes of extra data out there
what I'm still not sure about is if SPICE can support fictional orbits and space-ship trajectorys since the NAIF list and names are compiled into the core (at least that how it looks to me).
so is SPICE restricted to our solar-system only?
also the spice-kernels are "addons" so a few megs won't matter compared to the gigabytes of extra data out there
what I'm still not sure about is if SPICE can support fictional orbits and space-ship trajectorys since the NAIF list and names are compiled into the core (at least that how it looks to me).
so is SPICE restricted to our solar-system only?
Last edited by phoenix on 19.09.2006, 22:46, edited 1 time in total.
most recent celestia win32-SVN-build - use at your own risk (copy over existing 1.5.1 release)
-
Topic authorchris
- Site Admin
- Posts: 4211
- Joined: 28.01.2002
- With us: 22 years 9 months
- Location: Seattle, Washington, USA
phoenix wrote:I've not felt any downsides of the big executable yet... just curious why it's so big.
also the spice-kernels are "addons" so a few megs won't matter compared to the gigabytes of extra data out there
what I'm still not sure about is if SPICE can support fictional orbits and space-ship trajectorys since the NAIF list and names are compiled into the core (at least that how it looks to me).
so is SPICE restricted to our solar-system only?
Not at all . . . You can define new objects IDs in your spice kernel. See this document for more information about it:
http://www.gps.caltech.edu/~marsdata/req/naif_ids.html
HORIZONS can produce SPICE SPK files for real bodies or user-specified ones (integrating the trajectory from an initial position and velocity.)
--Chris
I notice nobody's commented on the problems I had with SPICE and NAIF data... unless anyone's got solid evidence that the SPICE data is accurate I don't think we should be assuming that it is (especially for ongoing missions - I had huge problems with the SPICE and NAIF data that came with ISIS for Galileo and Voyager) - just because it's 'official" doesn't means it's accurate.
So has anyone verified that the SPICE data is accurate yet?
So has anyone verified that the SPICE data is accurate yet?
My Celestia page: Spica system, planetary magnitudes script, updated demo.cel, Quad system
The two comparisons that I've made for Titan flybys using Celestia's Spice implementation have produced results very similar to those annonced by the Cassini team. Celestia does not yet implement Spice object orientation, though, just trajectories.
Specifically, using the Spice kernel 050216AP_SCPSE_05042_05071.bsp for the flyby of February 15, 2005, Celestia shows a minimum distance of 1579 km while the NASA article at http://saturn.jpl.nasa.gov/news/press-r ... newsID=543 claims 1577 km.
Using the Spice kernel 050922R_SCPSE_05225_05245.bsp
I see the minimum distance between Spice_Cassini and Spice_Titan
at August 22, 2005 08:53:33 UTC to be 3660.4 km,
which seems to be in reasonably good agreement with
the 3660 km at 8:54 claimed on the Web page
http://saturn.jpl.nasa.gov/news/sig-eve ... newsID=597
I don't know what causes the 2 km discrepancy for the February flyby. It could be that the kernel I used isn't the final one. I got it from the NAIF ftp site. In contrast, the kernel used for the other test came from the official Cassini data set 6 available from the PDS repository. I'll look again for a PDS kernel for the February flyby.
You do have to be careful to write the SSC files so all the appropriate barycenters are used. It isn't quite as obvious as one might like.
Here's the SSC file that I've been using. I change only the kernel name for the different tests.
Specifically, using the Spice kernel 050216AP_SCPSE_05042_05071.bsp for the flyby of February 15, 2005, Celestia shows a minimum distance of 1579 km while the NASA article at http://saturn.jpl.nasa.gov/news/press-r ... newsID=543 claims 1577 km.
Using the Spice kernel 050922R_SCPSE_05225_05245.bsp
I see the minimum distance between Spice_Cassini and Spice_Titan
at August 22, 2005 08:53:33 UTC to be 3660.4 km,
which seems to be in reasonably good agreement with
the 3660 km at 8:54 claimed on the Web page
http://saturn.jpl.nasa.gov/news/sig-eve ... newsID=597
I don't know what causes the 2 km discrepancy for the February flyby. It could be that the kernel I used isn't the final one. I got it from the NAIF ftp site. In contrast, the kernel used for the other test came from the official Cassini data set 6 available from the PDS repository. I'll look again for a PDS kernel for the February flyby.
You do have to be careful to write the SSC files so all the appropriate barycenters are used. It isn't quite as obvious as one might like.
Here's the SSC file that I've been using. I change only the kernel name for the different tests.
Code: Select all
Barycenter "Spice_Sun" "Sol"
{
SpiceOrbit
{
Kernel "050216AP_SCPSE_05042_05071.bsp"
Target "0"
Origin "10"
BoundingRadius 1e10
}
}
Barycenter "Spice_Earth_Barycenter" "Sol"
{
OrbitBarycenter "Sol/Spice_Sun"
OrbitReferencePlane "ecliptic"
SpiceOrbit
{
Kernel "050216AP_SCPSE_05042_05071.bsp"
Target "3"
Origin "0"
BoundingRadius 1e10
}
}
"Spice_Earth" "Sol"
{
Color [0 1 0]
Radius 7000
OrbitBarycenter "Sol/Spice_Earth_Barycenter"
OrbitReferencePlane "ecliptic"
SpiceOrbit
{
Kernel "050216AP_SCPSE_05042_05071.bsp"
Target "399"
Origin "3"
BoundingRadius 1e10
}
}
"Spice_Moon" "Sol/Earth"
{
Color [0 1 0]
Radius 2000
OrbitBarycenter "Sol/Spice_Earth_Barycenter"
OrbitReferencePlane "ecliptic"
SpiceOrbit
{
Kernel "050216AP_SCPSE_05042_05071.bsp"
Target "301"
Origin "3"
BoundingRadius 1e10
}
}
"Spice_Saturn_Barycenter" "Sol"
{
Color [1 1 1]
Radius 100
OrbitBarycenter "Sol/Spice_Sun"
SpiceOrbit
{
Kernel "050216AP_SCPSE_05042_05071.bsp"
Target "6"
Origin "0"
BoundingRadius 1e10
}
}
"Spice_Saturn" "Sol"
{
Color [1 1 0]
Radius 80000
OrbitBarycenter "Sol/Spice_Saturn_Barycenter"
OrbitReferencePlane "ecliptic"
SpiceOrbit
{
Kernel "050216AP_SCPSE_05042_05071.bsp"
Target "699"
Origin "6"
BoundingRadius 1e10
}
}
"Spice_Cassini" "Sol/Saturn"
{
Color [1 1 1]
Radius 0.011
OrbitBarycenter "Sol/Spice_Saturn_Barycenter"
OrbitReferencePlane "ecliptic"
SpiceOrbit
{
Kernel "050216AP_SCPSE_05042_05071.bsp"
Target "-82"
Origin "6"
BoundingRadius 1e10
}
}
"Spice_Titan" "Sol/Saturn"
{
Color [1 0 1]
Radius 2575
OrbitBarycenter "Sol/Spice_Saturn_Barycenter"
OrbitReferencePlane "ecliptic"
SpiceOrbit
{
Kernel "050216AP_SCPSE_05042_05071.bsp"
Target "606"
Origin "6"
BoundingRadius 1e10
}
}
Selden
So the Cassini SPICE data looks like it works... has anyone tried any others? Voyager? Galileo? Anything else?
My Celestia page: Spica system, planetary magnitudes script, updated demo.cel, Quad system
-
Topic authorchris
- Site Admin
- Posts: 4211
- Joined: 28.01.2002
- With us: 22 years 9 months
- Location: Seattle, Washington, USA
Joe wrote:To compile the CVS source with SPICE enabled, I need cspice.lib. Anyone would point me to the right direction for this file?
By default, Celestia builds without SPICE support. To enable it in
Windows, uncomment this line in src/winbuild.mak:
SPICE=enable
The required library for Windows and include files can be found here:
http://www.celestiaproject.net/~claurel/celest ... -win32.zip
Just unpack the file into your base Celestia build directory, fix the
Makefile, and you're ready to go . . .
--Chris