rca / pyspice

Python wrapper around the NAIF CSPICE library

SPICE toolkit Python Module

Python wrapper around the NAIF CSPICE library. Released under the BSD license, see LICENSE for details.

Building PySPICE

First, download the cspice toolkit and extract it to the directory "cspice" in this directory right alongside the setup.py file. Once the cspice source is there, run setup.py like so:

python setup.py build_ext

Then install:

python setup.py install

64 bit vs 32 bit

CSPICE is published in both 64 and 32 bit versions. Make sure that you compile PySPICE with a Python bit architecture that fits to the CSPICE you have downloaded, otherwise you will get warnings at compile time (not so bad) and errors of missing links in the library at run time (basically, you can't import spice.

Manual Instructions

Though it shouldn't be necessary, here are the old step-by-step instructions.

In order to build this module, first generate the extension code using the mkwrapper.py script. This is done running mkwrapper.py with the path to the CSPICE toolkit directory as an argument and redirecting the output to "spicemodule.c":

python mkwrapper.py /path/to/cspice > spicemodule.c

Once the C file is generated, the module can be compiled:

python setup.py build_ext -I/path/to/cspice/include -L/path/to/cspice/lib

Then the module can be installed using:

python setup.py install --prefix=/installation/path

If the installation path used is not standard, add the path to your PYTHONPATH environment variable. In bash:

export PYTHONPATH=/installation/path/lib/python<version>/site-packages:${PYTHONPATH}

or *csh:

setenv PYTHONPATH /installation/path/lib/python<version>/site-packages:${PYTHONPATH}

Usage

berto:~$ python Python 2.4.2 (#2, Sep 30 2005, 21:19:01) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from spice import * >>> furnsh("/home/berto/tmp/insitu/kernels/load.mk") >>> utc2et("2004-06-11T19:32:00") 140254384.18462521

Some things to keep in mind

The python wrapper drops the _c suffix in all function names, so the function utc2et_c becomes utc2et.

Also, the CSPICE toolkit passes both inputs and outputs into a SPICE function:

SpiceDouble et;
SpiceChar * utc = "2004-06-11T19:32:00";

utc2et_c(utc, &et);

printf("et: %f\n", et);

But, in Python, the outputs are returned:

utc = "2004-06-11T19:32:00"

et = utc2et(utc)

print "et: %f" % et

If a function returns multiple values they are returned in a tuple:

target_pos, light_time = spkpos(target, sc_et, frame, aberration, sc_name)

print "light time: %f" % light_time
print "xyz: [%e, %e, %e]" % target_pos

In the case above, the target position and light time are returned in a tuple. Additionally, target_pos itself is a tuple; its individual elements can be accessed like this:

print "x position: %d" % target_pos[0]

Tuples act just like arrays.

Enjoy!

pyspice's Issues

Rename project.

@drbitboy suggested a better name to avoid conflict with another PySPICE -- python-based tools for the SPICE circuit software -- would be Spyce.

Thoughts? If we do go through with this idea, it might make sense to move over to an organization of that name and make this project an entity of its own.

Thoughts?

Cant import part from shared library

Hi! I compiled the shared library from ngspice (master) and enabled shared library flag.
Successfully found those on my Ubuntu16.04 under /usr/local/lib :

libngspice.so, libngspice.so.0, libngspice.so.0.0

In jupyter I included the library as following as in the example of the diode in 8.2.1 and changed this line to:
libraries_path = os.path.join(os.path.dirname('/usr/local/lib/'), 'libraries')
spice_library = SpiceLibrary(libraries_path)

When I try spice_library['1N4148'] I get the key error because spice_library has no entry of this part.
When I open interactive python console and look into the class of spice_library I have only two empty subclasses:
models subcircuits

Could anyone tell me what I am missing?

install in anaconda + brew environment?

Im on a mac, mavericks 10.9.4, anaconda latest version, brew latest version

For now, I've installed cspice with brew

but now I'm not sure what to do, as I'm by no means a python or linux expert

Can someone point me in the right direction?

subpnt return not as expected

subpnt should return

• the coordinates of the subpnt in the coordinate frame chosen at call-time of subpnt,
• the epoch when photons left the ground (i think),
• the vector from the surface point to the observer

So, following the example on
http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/IDL/info/mostused.html#K
(the example for calculating sub-observer and sub-solar points
in IDL one receives:
IDL> print, scraft
2226.3949 -2455.4832 735.82877
(which makes sense in terms of known Mars' radius)
IDL> print, trgepc
1.9194127e+08
IDL> print, srfvec
-259.37184 286.06031 -86.741119
(which has a vector_norm (vnorm) of around 398 km, so very reasonable for MGS)

but in python, with the same kernels, one receives:
In [19]: pnt = subpnt("Near point:ellipsoid",'Mars',et,'IAU_MARS','LT+S','MGS')
In [20]: print pnt
((-259.3718430329991, 286.0603065386822, -86.74111942755394), 2.132997621e-314, (6.9532229752806e-310, 6.953222975366e-310, 6.95323682690823e-310))

I am using 64-bit python from Enthought.

Cells are not working (yet?)

The following code returns a segmentation fault, simply because SPICE cells are not supported:

startUTC = "25 FEB 2013 00:00:00"
endUTC   = "28 FEB 2013 00:00:00"

startET = utc2et(startUTC)
endET   = utc2et(endUTC)

c = wninsd(startET,endET)

At least we could implement a more graceful failure.

PySPICE fails to install

I'm having some trouble getting PySpice installed on my machine.
It compiles without warning:

$ CSPICE_SRC=/home/fmullall/apps/cspice/
$ export CSPICE_SRC
$ python setup.py build_ext
running build_ext
building '_spice' extension
creating build
creating build/temp.linux-x86_64-2.7
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/home/fmullall/apps/cspice/include -I/usr/include/python2.7 -c pyspice.c -o build/temp.linux-x86_64-2.7/pyspice.o
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/home/fmullall/apps/cspice/include -I/usr/include/python2.7 -c spicemodule.c -o build/temp.linux-x86_64-2.7/spicemodule.o
creating build/lib.linux-x86_64-2.7
gcc -pthread -shared build/temp.linux-x86_64-2.7/pyspice.o build/temp.linux-x86_64-2.7/spicemodule.o -L/home/fmullall/apps/cspice/lib -L/usr/lib64 -lcspice -lpython2.7 -o build/lib.linux-x86_64-2.7/_spice.so

and installs without incident:
$ python setup.py install --prefix=~/.local/
running install
running build
running build_py
creating build/lib.linux-x86_64-2.7/spice
copying spice/objects.py -> build/lib.linux-x86_64-2.7/spice
copying spice/init.py -> build/lib.linux-x86_64-2.7/spice
copying spice/misc.py -> build/lib.linux-x86_64-2.7/spice
running build_ext
running install_lib
copying build/lib.linux-x86_64-2.7/_spice.so -> /home/fmullall/.local//lib64/python2.7/site-packages
running install_egg_info
Removing /home/fmullall/.local//lib64/python2.7/site-packages/Spice-1.0-py2.7.egg-info
Writing /home/fmullall/.local//lib64/python2.7/site-packages/Spice-1.0-py2.7.egg-info

But when I run it, I get an error message:
$ PYTHONPATH=$PYTHONPATH:/home/fmullall/.local/lib64/python2.7/site-packages/
$ python -c 'import spice'
Traceback (most recent call last):
File "", line 1, in
File "spice/init.py", line 3, in
from misc import *
File "spice/misc.py", line 3, in
from _spice import *
ImportError: dynamic module does not define init function (init_spice)

The readme files suggests this might be a 32/64 bit problem, but cspice
is compiling 64 bit as well, as best I can tell. Any ideas what I'm doing wrong?

Python 3 support?

So I am trying to use PySpice in Python 3, I made a new Fork from drbitboy's most recent work and I have made all of the necessary changes to all of the python files (except for any changes to mkwrapper.py, see below). As of now I have it successfully compiling and installing the library on OSX 10.9 (with python 3.3.1) , but if I try to import spice you can see the attached image:

I also tried installing it on a 32bit ubuntu 12.04 LTS VM, with Python 3.2 and got a similar error (except with pystring_fromstringandsize) and a couple of warnings during compiling.

I have never used the Python API, so I am not sure what exactly has changed between python 2 and 3. Any chance that this could be looked into? I will of course continue to try things, but I would appreciate some assistance or suggestions of what to look at.

using f2py to fill in the gaps

Hey all, so since getting my python 3 version working, I have been struggling to figure out a way to get the rest of the functions in the exclude list for the wrapper working. I really want to be able to write out CK kernels (ckw0# functions) using pyspice, I even went so far as to start a rewrite of the entire spice library in python, which is kind of nuts I admit. But earlier today I successfully figured out how to use f2py (http://cens.ioc.ee/projects/f2py2e/) to get a few of those functions working, for example mxmtg and mxvg. All I really needed to do was add a few "intent" lines to both fortran files for the "out" matrix/vector. It should be possible to do this for the entire fortran toolkit, I just haven't written any code to do this for me. Would it be possible to combine the c wrapper with the parts generated by f2py?
Also on an aside, I am not too familiar with how c works, but why is this wrapper wrapping the functions that end with "_c.c", which are just wrappers of the f2c generated code files which end is just ".c". Since python is written in C, wouldn't it be better to wrap the f2c generated code? Maybe because we are preserving Spice types (ie SpiceDouble)?
Edit: I didn't write what I meant to ask here, I was thinking since the .c files are already pure C code (or mostly so), wouldn't it be easier to wrap those functions instead of wrapping the _c.c ones?

Problem in compiling the PySpice: os.waitpid OSError: No child processes

Hi,

I'm trying to compile the PySpice in my Windows 8 x64, with the x64 version of Python and cspice.
However, in build_cspice() I get the following error:

   In setup.py:
   os.waitpid(makeall.pid, 0)[1]
   OSError: [Errno 10] No child processes.

I identify the problem to be related with calling a inexistent csh installation path:

    os.chdir(CSPICE_SRC)
    makeall = Popen('/bin/csh makeall.csh', shell=True)
    status = os.waitpid(makeall.pid, 0)[1]

I see that the sentence was exclusively written to linux. How could I proceed?

Bad wrapping of gfoclt_c

The wrapper code for gfoclt_c is broken. The argument cnfine is actually supposed to be BOTH an input and an output. The wrapper considers it only an input and thus when the routine is called it tries to read a null pointer and segfaults.

I don't know if PySPICE has a preferred method for handling arguments that are both Input and Output.

The help text correctly lists it as I-O:

In [106]: spice.gfoclt?

Type:             builtin_function_or_method
Base Class:       <type 'builtin_function_or_method'>
String Form:   <built-in function gfoclt>
Namespace:        Interactive
Docstring:
    -Abstract

       Determine time intervals when an observer sees one target
       occulted by, or in transit across, another.

    -Brief_I/O

       VARIABLE        I/O  DESCRIPTION
       --------------- ---  -------------------------------------------------
       SPICE_GF_CNVTOL  P   Convergence tolerance.
       occtyp           I   Type of occultation.
       front            I   Name of body occulting the other.
       fshape           I   Type of shape model used for front body.
       fframe           I   Body-fixed, body-centered frame for front body.
       back             I   Name of body occulted by the other.
       bshape           I   Type of shape model used for back body.
       bframe           I   Body-fixed, body-centered frame for back body.
       abcorr           I   Aberration correction flag.
       obsrvr           I   Name of the observing body.
       step             I   Step size in seconds for finding occultation
                            events.
       cnfine          I-O  SPICE window to which the search is restricted.
       result           O   SPICE window containing results.

getnaifspicetoolkit.py, KeyError: 'X86_64' on Mac (10.9) x86_64

On a Mac OS 10.9:

$ uname -a
Darwin gothmog.maiar.lan 13.0.2 Darwin Kernel Version 13.0.2: Sun Sep 29 19:38:57 PDT 2013; root:xnu-2422.75.4~1/RELEASE_X86_64 x86_64

Running getnaifspicetoolkit.py produces

$ ./getnaifspicetoolkit.py
Traceback (most recent call last):
  File "./getnaifspicetoolkit.py", line 278, in <module>
    main(sys.argv[1:])
  File "./getnaifspicetoolkit.py", line 206, in main
    nstkurl = getnstkurl(force=testOption,log=True)
  File "./getnaifspicetoolkit.py", line 159, in getnstkurl
    subdir='_'.join([ dSys1[opsys][machine], dSys1[opsys]['sis2'], compiler, unbit ])
KeyError: 'X86_64'

This patch seems to correct it.

--- a/getnaifspicetoolkit.py
+++ b/getnaifspicetoolkit.py
@@ -100,7 +100,7 @@ Index of http://naif.jpl.nasa.gov/pub/naif/toolkit/C/:
   ###   SUNOS and SUN4U => SunSPARC_Solaris
   ###

-  dSys1 = dict( OSX=dict( I386='MacIntel', PPC='MacPPC', sis2='OSX', zSfx='tar.Z' )
+  dSys1 = dict( OSX=dict( I386='MacIntel', X86_64='MacIntel', PPC='MacPPC', sis2='OSX', zSfx='tar.Z' )
               , LINUX=dict( I386='PC', X86_64='PC', sis2='Linux', zSfx='tar.Z' )
               , CYGWIN=dict( I386='PC', X86_64='PC', sis2='Cygwin', zSfx='tar.Z' )
               , WINDOWS=dict( I386='PC', X86_64='PC', sis2='Windows', zSfx='zip' )

tests/horizons.py demo of pulling SPK from JPL Horizons not working any more.

It seems that the telnet interface to JPL Horizons has changed a bit, so the prompts that horizons.py is looking for (via pexpect) when getting an SPK for a comet or asteroid aren't working.

Sample error message, while trying to retrieve comet 67P/Churyumov-Gerasimenko:

$ python horizons.py 900647
('900647_pexpect.bsp', 0, ['Horizons lookup FAILED status=1, URL=,?,: \r\n \r\r\nHorizons> SPK\r\n \r\r\n>EXACT< name search [SPACE sensitive]:\r\r\n NAME = SPK;\r\r\nContinue [ =yes, n=no, ? ] : ', 'SPK retrieval not attempted', 'SPICE Body ID not attempted'])

In addition, I don't see any way to download a binary SPK any more.

A first cut at a fix is in this pull request. It now gets an ASCII transfer file (comet_pexpect.xfr) now, rather than comet_pexpect.bsp

drbitboy#2

$ python horizons.py 900647
('900647_pexpect.xfr', -1, ['Horizons lookup status=0, URL=ftp://ssd.jpl.nasa.gov/pub/ssd/wld29182.15', '### Retrieved SPK (URL=ftp://ssd.jpl.nasa.gov/pub/ssd/wld29182.15) as 900647_pexpect.xfr', '### Retrieved SPICEID -1; status=SUCCESS'])

Manual installation fails in mkwrapper.py

Dear all, I would like to make you aware that the manual installation as described in ReadMe.rst fails because mkwrapper throws an exception in line 837. The problem occurs while the wrapper tries to determine the size of one function parameter that is defined in the cspice header SpiceZpr.h. The function is "void edterm_c(...)". The problem is that the last input parameter is "SpiceDouble termpts [ ][3]" and the wrapper tries to identify the size of this array. However, because the first bracket is empty, instead of an integer, the wrapper gets an empty string. With the empty string, the wrapper cannot continue to work and throws the exception.

I tried to run everything on Windows and on Linux. The same error occurs in both cases.
I hope that I can add to the progress of this great project with this comment. I would really like to see SPICE for Python.

Cheers