[Spice_discussion] JAVA Interface to SPICE

[Adrian Challinor]

>> 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)?
>>  
>> Michael
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.


Adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://naif.jpl.nasa.gov/pipermail/spice_discussion/attachments/20100215/5699f2cf/attachment.html