[Spice_discussion] JAVA Interface to SPICE
adrian.challinor at osiris.co.uk
Mon Feb 15 00:12:36 PST 2010
>> But I am also interested in how Adrian makes 'proper' Java calls to
>> SPICE. Are you directly talking to the libraries somehow or are you
>> executing SPICE via system calls and then catch the output for further
>> processing (e.g. for the mentioned exceptions)?
I'm sorry I am late in replying - I have been travelling. Please let me
explain. I am not a professional astronomer, though I am a Fellow of
Royal Astronomical Society. I am an IT professional though. I have some
private astronomical research (ie, not for a formal body and not (yet)
for publication). For this I needed an orbital maths library and SPICE
fits the bill. I do know C only too well, but was not wild about
writing a user interface in C. Hence my desire to use JAVA.
What I am doing, slowly as it happens, is when in the JAVA world I need
a SPICE function, I am coding up a formal call as part of a growing JAVA
Class. The class started as a static class, with one static method call
wrapped to one SPICE function, with a bit of C as the glue. The methods
are designed to look like JAVA equivalents. This means that they use
JAVA parameters (Stings, Collections, doubles, booleans) and return a
proper JAVA value (see previous list). This is quite different from the
SPICE functions. Where the logical thing would be to tie more than one
SPICE call together, I have done this in the C interface glue.
Errors, as Michael suspected, are handled via exceptions.
Where I am going next is when I have a logical SPICE object (eg a Body
or an Instrument) that has characteristics that can be defined at the
outset (from a kernel file or from program input) I make a new SPICE
object: so I can have a SPICE object called SpiceBody that represents a
planet or moon, which has the appropriate SPICE methods associated with
it. This way I am maintaining the object orientated approach.
There is a distinct downside to this: the conversion between C and JAVA
structures (arrays, strings, etc) is a performance hit. Its is
suboptimal. It does beg the question whether there should be a push to
write a native JAVA implementation, converting the C code to pure JAVA.
Given that the C code itself is a conversion from FORTRAN, this is a
much bigger task than it sounds - almost better to go back to the
FORTRAN. There are a lot of low-level routine that need to doing like
process the Kernel files - these are very clever and definitely a
non-trivial to convert. I am always left with the question: "is it worth
the effort" when I even think of this.
Over the last couple of months, things slowed down considerably on my
astrophysical, caused be a problem I call "the day job". This is a
project involving geospatial work and meaning I have had to learn a lot
more about low earth orbit satellites than I ever really wanted to!
Still, all good fun.
I also got sidelined looking at a small but fun project: What would
seasons be like on a planet orbiting one of the stars in a multi-binary
star, such as Mizar in Ursa Major.
The main project I am looking at is to optimize space craft propulsion
for solar system and orbital manoeuvres. This, I admit, was inspired by
talking to one of the space craft engineers from the Cassini team when
they visited the Royal Observatory Greenwich last year. This project
will probably revert back to being in C, as I have upgraded my computer
to include parallel processing hardware, but that is accessible only in
C. The idea here is that I can using a parallel linear processing
approach to optimising changes in DeltaV. Rather than serially attacking
the problem, I could start around 16,000 parallel threads and choose
those that are most optimal for further investigation. So the JAVA work
could come to a grinding halt.
Personally, I have no real interest in a Python interface. The same
approach I used for JAVA/SPICE could work for PYTHON/SPACE. If I were to
look at a pure interpreted language, I would be much more likely to
choose RUBY over Python - simply because I have more experience here.
That is in no way a promise to generate a RUBY interface!
Hope thats interesting and I am not treading on anyone's toes with this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Spice_discussion