[Spice_discussion] About handlers loading spk kernels.

[Nat Bachman]

Hi Omar,

Within a program run, SPICE file handles are not re-used.

In your example, the two copies of the file are distinct
as far as the file system is concerned, and SPICE will
assign them distinct handles. The fact that the files
have the same contents is immaterial.

Two SPICE kernels could have identical data but different
comments, so a checksum is not a robust comparison technique.

Whether SPICE recognizes as distinct two different names
that point to the same file, for example

    myfile.bsp
    /home/spice/myfile.bsp

depends on the host file system. In this regard, I have
seen at least one instance of incorrect behavior
of the f2c library, which CSPICE uses: on a Linux system,
two file names such as the above were seen as referring
to distinct files. I do not expect that the f2c libraries
will be modified to fix this problem.

So I recommend avoiding designs that rely on robust
recognition of alternate names for a given SPICE kernel.
The safest approach is to use a unique file name for
each distinct file, although this is not always easy to
enforce.

As you probably already know, CSPICE functions don't support
translation of environment variables that refer to
SPICE kernels (unless this translation is automatically
done by the host I/O system, which is not the case for
Unix or Windows); any required translations must be performed
prior to loading kernels.

Another file system issue to be aware of: deleting
or updating a binary kernel that SPICE has loaded, while
that file remains loaded, should be avoided.
SPICE's data structures can become corrupted
as a result of these actions.

SPICE does not provide a function to determine whether two
loaded kernels having different names actually have
the same contents. There are a few special cases where
SPICE utilities can be used to compare files: you can
use SPKDIFF to compare SPK contents, or you can use
Spy (available from the NAIF server) to dump data from
two SPK files and then compare the dumps.

I recommend not having your application call

    spklef_c

directly. This is a low-level routine that remains
public only for backward compatibility. Calling this
routine makes the kernels it loads invisible to the KEEPER
subsystem---the SPICE subsystem that maintains a database
of kernels loaded via

    furnsh_c

Instead, although in the short run it involves a bit more work,
I recommend loading all kernels via furnsh_c, then using,
as needed,

    ktotal_c
    kinfo_c
    kdata_c

to obtain file handles, file types, or parent meta-kernel names.
To unload files, use

    unload_c (unloads a file)
    kclear_c (clears the whole KEEPER database and kernel pool)

If you want to increase the priority of data provided by
a given kernel, first unload the kernel via

    unload_c

then reload it via furnsh_c. If you fail to unload a kernel,
you can still increase its priority by reloading it, but you'll
use up an extra entry in the KEEPER database. Since CSPICE
is derived from SPICELIB, which is written in ANSI Fortran 77,
all CSPICE data structures in memory, including the KEEPER
database, have limited size.

Please see the API documentation for the SPICE routines
named above, as well as the DAF and Kernel Required Reading,
for further details.

Please let us know if you have further questions about SPICE.

Best regards,

   -Nat Bachman (JPL/NAIF)

Nathaniel.Bachman at jpl.nasa.gov


Omar Andrés Zapata Mesa wrote:
>   Hi everyone.
> I am writing a c++ interface for spice and I have some questions.
> I am loading the kernel using spklef_c(...) and getting the
> handler to control the kernel's pool, the questions are:
> is the handler an unique value for each kernel? Â Â Â 
> If I have kernel.bsp and kernel-copy.bsp (the same just renamed)
> when I load the kernels the handlers are 1 and 2,
> Is the name of the file the criteria to asign the handler?
> 
> I am using md5sum to compare if two kernels are loaded and equal, does 
> the toolkit have some function for that?
> thanks
> 
> -- 
> Omar Andres Zapata Mesa
> Division of computer science Gfif Developers (Gfif Dev)
> http://gfifdev.udea.edu.co <http://gfifdev.udea.edu.co/>
> Systems Engineering Student
> Universidad de Antioquia At Medellin - Colombia
> User Linux  #490962
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Spice_discussion mailing list
> Spice_discussion at naif.jpl.nasa.gov
> http://naif.jpl.nasa.gov/mailman/listinfo/spice_discussion