NAIF errors after initializing with ck/spk-writer kernels

[lwellerastro]

ISIS version(s) affected: 5.0.2, isis7.0.0-RC2

Description
Camera and Spacecraft kernels generated for Cassini ISS images of Titan early last month generate NAIF errors when applied to newly ingested images as well as certain types of existing images.

Spiceinit runs without errors, but programs like qview and campt produce the following NAIF error message:

  Group = Error
    Program = campt
    Code    = 1
    Message = "An unknown NAIF error has been encountered. The short
               explanation provided by NAIF is [SPICE(ZEROVECTOR)]. The Naif
               error is [SURFPT: The input vector is the zero vector.]"
    File    = NaifStatus.cpp
    Line    = 100
  End_Group

How to reproduce
See data under /work/users/lweller/Isis3Tests/Spiceinit/WriterKernels/.
There is also a proc.scr file with information on source data for some of the tests.

ciss2isis from=N1509137653_2.LBL to=N1509137653_2_ingest_kernspice.cub

spiceinit from=N1509137653_2_ingest_kernspice.cub ck=Titan_CISS_2022_ck.bc spk=Titan_CISS_2022_spk.bsp

campt from=N1509137653_2_ingest_kernspice.cub

  Group = Error
    Program = campt
    Code    = 1
    Message = "An unknown NAIF error has been encountered. The short
               explanation provided by NAIF is [SPICE(ZEROVECTOR)]. The Naif
               error is [SURFPT: The input vector is the zero vector.]"
    File    = NaifStatus.cpp
    Line    = 100
  End_Group

Additional context
The images used in creating the ck and spk kernels were processed under isis4.x.x and isis5.0.2. They were originally ingested and spiced in June of 2020 under isis4.1.0. There were bundled and updated with jigsaw under isis5.0.2 in February 2022. The kernels were created under isis5.0.2 in early April 2022. I can supply the list of images and writer commands if that is useful. It took many hours for the writer programs to run on these 6000+ images.

ckwriter fromlist=updated_CISS_Titan_FFCombined7_Thin_PixReg_SubReg_Ground.lis \
    to=Titan_CISS_2022_ck.bc summary=Titan_CISS_2022_ck_summary.txt

spkwriter froml=updated_CISS_Titan_FFCombined7_Thin_PixReg_SubReg_Ground.lis \
    to=Titan_CISS_2022_spk.bsp summary=Titan_CISS_2022_spk_summary.txt type=9

I used type=9 for the spacecraft kernels only because it was used on past data sets (decision made by those more knowledgeable). Maybe this is part of the problem? I will create a type=13 version and see if that makes a difference and will report here after. But I did have success using the both kernels as noted below, but the input image seemed to matter, which is what I find odd. Plus the answer was not as expected.

I was originally testing the validity of the kernels when I ran into problems. The data have a long, somewhat complicated processing history so I initially made a copy of an existing, pre-jigsaw file and applied the kernels directly to it. See proc.scr and copy_N1509137653_2.cub. I did not encounter any errors using this method, but the geometry applied to this image using the kernels does not match that of the jigsaw updated image and is likely a result of new Cassini spacecraft kernels, a problem described in issue #4922.

As an additional test I decided to apply the kernels to a freshly ingested image and ran into the NAIF errors.
I encountered the same error when I made a copy of my jigsaw updated image and applied the kernels to it. See copy_jigsawed_N1509137653_2.cub and the source information in proc.scr.

I wonder if somehow the mixing of isis versus ale spice handling is playing any part in this.

Please let me know if more/different information is needed when this is pursued.

[jessemapel]

My first guess is an SPK issue as SURFPT is the routine that intersects a position and look vector with an ellipsoid. it is somehow being passed a 0 position vector. I'll do some more poking around.

[lwellerastro]

There were no errors after applying it to a copied version of the jigsaw input image. Errors on some input but not others is what's kind of concerning me, but maybe that's a red herring.

Update: I ran the same tests using only the ckwriter generated kernel and I no longer get the NAIF error. So there is something going on with the spk kernel and perhaps I should create a version using the default type=13.

That being said, the geometry information after running spice using the ck kernel on various versions of the same image (freshly ingested, copy of jigsaw input image, copy of jigsaw updated image) is not the same across the board. The ingested image and the copy of the jigsaw updated image produce the same geometry, but the copy of the jigsaw input image is different and has source=ale on the labels whereas the other two do not (also seeing FrameTypeCode=2 in BodyRotation table for ingested image and the copy of the jigsaw updated image, but FrameTypeCode=3 in the ale image). Is this a different problem?

Note: the geometry output among the various spiced images produces different results even if I let spice default. The ingested image and the copy of the jigsaw updated image produce the same geometry, but the copy of the jigsaw input image is different and has source=ale on the labels whereas the other two do not. I don't understand.

[lwellerastro]

I created a type=13 spk kernel for my Titan network of images and that too is generating NAIF errors when applied to newly ingested images.

[lwellerastro]

I created ck and spk kernels for a small set of updated Kaguya TC images and performed tests similar to Titan. I encountered no issues using the new kernels on ingested images or copies of the pre-jigsaw images. In both cases, the resulting images matched the jigsaw updated images that the kernels were based upon.

I was not able to create a single ck or spk kernel for my test images because the times the for the Kaguya images overlap (totally unexpected, but it is a widespread thing), so each image had its own set of kernels. Not sure that matters, but thought I'd mention it.

Additionally, I noted that every image involved with the testing always maintained Source=isis unlike the Titan data which mysteriously switched to ale in one case. Again, not sure that has anything to do with the Titan issue, but thought I would mention it anyway. Not sure when to expect isis vs ale honestly.

[lwellerastro]

I realize there is lot to my messages above so I thought it might help to boil things down to a single image case.

I created a ck and spk kernel for one of my updated images, then ingested a fresh version of the image and spiced applying the newly created image kernels. This is enough to create the noted errors when programs like qview or campt are used. I did all of this under isis7.0.0.

The input/output data can be found under my work users area under Isis3Tests/Spiceinit/WriterKernels/SingleImage.
See the text file proc.scr for the processing steps (creating and applying the kernels).

I created both a camera and spacecraft kernel for the image, but as @jessemapel pointed out in reply, it appears the spacecraft kernel is generating the errors.

[amystamile-usgs]

This is what I have figured out so far. When running spiceinit
spiceinit from=N1509137653_2_ingest_kernspice.cub ck=Titan_CISS_2022_ck.bc spk=Titan_CISS_2022_spk.bsp

the computed state through spkez_c results in nan positions.

The input variables for spkez_c are:

et: 1.83717e+08
target: -82
observer: 606
refFrame: J2000
abcorr: NONE
hasVelocity: 62
lightTime: -9.63407e-06

with the following results:

et = 183716769.8124677539
J2000 x-position (km):                    nan
J2000 y-position (km):                    nan
J2000 z-position (km):                    nan
J2000 x-velocity (km/s):                  nan
J2000 y-velocity (km/s):                  nan
J2000 z-velocity (km/s):                  nan

When running spiceinit without the spkwriter kernel:
spiceinit from=N1509137653_2_ingest_kernspice.cub ck=Titan_CISS_2022_ck.bc

The inputs for spkez_c were:

et: 1.83717e+08
target: -82
observer: 606
refFrame: J2000
abcorr: LT+S
hasVelocity: 62
lightTime: -9.63407e-06

with the following results:

et = 183716769.8124677539
J2000 x-position (km):       69519.7375863155
J2000 y-position (km):     -141708.0811042481
J2000 z-position (km):        3117.9943072365
J2000 x-velocity (km/s):        -2.5646972102
J2000 y-velocity (km/s):         4.9785958907
J2000 z-velocity (km/s):        -0.0956049246

The only difference I see between the two input variables is abcorr but my understanding is that it is always set to NONE when using a spkwriter kernel.

Since spkez_c is calculating the states using SPK files that have been loaded through furnsh_c, my guess is the problem lies in the kernel calculation itself. I am not sure why nan results are not causing any SPICE errors. I am also not sure how I could even troubleshoot this since I cannot see what spkez_c is doing on the backend.

@jessemapel Do you have any suggestions for solving this or have seen spkez_c return nan results and know the reason?

[jessemapel]

This is really strange. The only things I can think of are:

1. Crack the kernel open and check that the data inside of it is doesn't have any errors in it.
2. Send this off to NAIF since we have a reproducible error with just CSPICE routines.

[amystamile-usgs]

I reached out to NAIF and they ran spkdump on Titan_CISS_2022_spk.bsp and responded with It appears the SPK contains invalid data. The segment covers a time interval of 0.006 TDB seconds, with a polynomial degree of 1.

@lwellerastro could you direct me to the images used to create the Titan_CISS_2022_spk.bsp kernel?

[lwellerastro]

Hi @amystamile-usgs the image list for the writer commands below can be found under /work/projects/titan/lweller/All_CB3_MT1/FindFeatures/

ckwriter fromlist=updated_CISS_Titan_FFCombined7_Thin_PixReg_SubReg_Ground.lis \
    to=Titan_CISS_2022_ck.bc summary=Titan_CISS_2022_ck_summary.txt

spkwriter froml=updated_CISS_Titan_FFCombined7_Thin_PixReg_SubReg_Ground.lis \
    to=Titan_CISS_2022_spk_type13.bsp summary=Titan_CISS_2022_spk_type13_summary.txt type=13

Notice that the images in the list points to an area on /scratch that houses the updated images. There are nearly 7000 images in the input list and each of the commands above took hours to run.

That data have had to undergo a lot of reprocessing in order to use them including applying intermediate improved geometry by way of deltack.

Here's the very condensed version of processing:

• basic ingestion, spice and calibration (ciss2isis, spiceinit, cisscal, camstats, footprintinit)
• extensive processing to remove noise and atmosphere (noisefilter, ratio with other CISS images, flatfield removal,trim, etc.)
• deltack for improved geometry
• jigsaw

Please let me know if you have additional questions or need to have access to any of the other stages of processing.

[lwellerastro]

Hi @amystamile-usgs, this can all be reproduced without working with the kernel that was built upon 7000 images. It can be reproduced with a single CISS image.

There is an example under my work users area Isis3Tests/Spiceinit/WriterKernels/SingleImage/ImageKernel/. See proc.scr for the simple processing details, but in a nutshell

• ingest image and make a copy of it
• spiceinit ingested image using system defaults
• run campt to confirm it's ok
• run spkwriter and create a kernel for the image
• run spiceinit on the copied ingested image and apply the spk kernel
• run campt and get the following error

  Group = Error
    Program = campt
    Code    = 1
    Message = "Requested position does not project in camera model; no surface
               intersection"
    File    = CameraPointInfo.cpp
    Line    = 343
  End_Group

Although this is not an identical error as produced by the larger kernel, this seems relevant to me and might help unearth the problem that seems to be coming from either spiceinit, spkwriter or how isis is intersecting bodies. Note that there is no shape model for Titan, only the ellipsoid information is loaded when spiced.

I hope this helps some!

[jessemapel]

@amystamile-usgs and I looked into this a bit more today.

The problem, in the single image case, is that spkwriter is writing the position of Cassini relative to Titan (NAIF ID 606) but labeling it in the kernel as the position relative to the Saturn Barycenter (NAIF ID 6). There's a small bit of code in all of the Cassini camera models that tells spkwriter to do this (added in 31cda9f). We aren't 100% certain why this is done, but it appears to be an attempt to match the format of the original Cassini kernels which contain the position of Cassini relative to the Saturn Barycenter.

There are two apparent fixes here:

1. Remove the code in the Cassini models that tells spkwriter to label the positions as relative to Saturn Barycenter. This will result in kernels that contain the position of Cassini relative to Titan.
2. Modify spkwriter to load a kernel containing the position of Saturn Barycenter relative to the Solar System Barycenter (likely by loading the TSPKs from the cube label) and then make some SPICE calls to get the position at the required times. Then, do the math to find the position of Cassini relative to the Saturn Barycenter and write that out. This will result in kernels that contain the position of Cassini relative to Saturn Barycenter.

The first option will be easier, but will result in smithed SPKs that are a slightly different format from the original kernel data set. The second option will be harder, but it will result in smithed SPKs that are the same format as the original kernel data set and they will need to be used with that same original kernel data set or we could encounter problems like #4922.

So, the question is, @lwellerastro what do you want your smithed SPKs to look like?

[jessemapel]

Additional question for @lwellerastro and possibly @blandoplanet: Have you used spkwriter to create smithed kernels of any other moons of Saturn with Cassini data? I'm surprised we didn't encounter this issue with Enceladus kernels.

[lwellerastro]

@jessemapel, I haven't a clue. Seems like option 2 makes more sense, but Brent will have to chime in since he understands the implications better. He is getting notifications for this post, but I will email him to bring this to his immediate attention.

To be clear about some things (for everyone's benefit), the single image case image would have picked up the most recent/up to date (and hopefully last) Cassini spacecraft kernel that is now breaking Enceladus. I fully intend on reprocessing my Titan images to pick up this kernel to hopefully avoid the Enceladus kernel problem. The 7000 image kernels I created earlier this year had the previous version of the spk kernel. Though I don't think it matters either way since it seems more to do with kernels written relative to Saturn vs Titan, but I thought I'd mention it anyway.

Additional question for @lwellerastro and possibly @blandoplanet: Have you used spkwriter to create smithed kernels of any other moons of Saturn with Cassini data? I'm surprised we didn't encounter this issue with Enceladus kernels.

I have created kernels in ISIS for Enceladus and now Titan. It's possible Tammy and/or others have worked with other bodies, but I'm not sure.

Edit - I believe we only created a camera kernel for Enceladus and provided an updated tpc kernel. We are solving for spacecraft for Titan because we have ground points to RADAR mosaics.

[KrisBecker]

This might be related to the explanation in #3482, specifically the Loss of Ephemeris Data section in one of the comments.

Please try applying the SPK smithed kernels in the spiceinit EXTRA parameter instead of the SPK parameter.

[amystamile-usgs]

@KrisBecker I don't believe that is the root of this problem. I tried running spiceinit with the EXTRA parameter instead of the SPK parameter and we still see the same results. This is due to spkwriter writing the state positions based on the center body of Titan but also writing that the center body is Saturn Barycenter (due to the camera model hardcoding this center body). We speculate that the hardcoded center body is to match the original Cassini kernels. Therefore the spkwriter kernels are simply incorrect positions based on the center body.

[lwellerastro]

I can confirm @amystamile-usgs results - I still get intersection errors on the most simplest case.

spiceinit from=N1560476854_1_extrakern.cub extra=Titan_N1560476854_1_default_spk.bsp ck=Titan_N1560476854_1_default_ck.bc

campt produces the following error whether I include the ck kernel or not in the above command: "Requested position does not project in camera model; no surface intersection"

[jessemapel]

I agree that the problem here is in spkwriter and not spiceinit. However, if we go with solution 2, we should follow Kris's recommendation of passing the kernels as extra on top of the existing kernel data set.

Also, it sounds like we didn't write smithed SPKs for Enceladus so that explains why we didn't encounter this. My understanding is that ckwriter already has this type of functionality built into it.

[blandoplanet]

@jessemapel regarding option 1 above. What are the consequences of having a "slightly different format" for the kernels? Option 1 seems much easier, but I don't understand the ramifications.

[jessemapel]

@amystamile-usgs Had some discussion with @blandoplanet @lwellerastro and Brent.

We're going to move forward with solution 1, removing the explicit SPK center definitions. We need to check that all of the image geometry is still correct with this approach though.

[lwellerastro]

Hi - I continue to have problems with my data under isis7.1.0-RC1 while working with newly created kernels (spk in particular) based on my entire dataset. I am getting the same SPICE(ZEROVECTOR) errors as described in my original post. Note that this is also the case when I set extra=newSPKkernel instead of spk=newSPKkernel.

I needed to reprocess all of my data to pick up the latest (and hopefully last) mission spk kernel and I did so under isis7.0.0 while awaiting these changes. My understanding was only the writer programs were being adjusted so I did not think this would be a problem, but could it be?

Under isis7.0.0:

• spiceinit to pick up new mission spk's
• deltack to pickup improved geometry from a collaborator
• photrim
• jigsaw and update

Under isis7.1.0-RC1

• ckwriter on the updated images
• spkwriter on the updated images
• test kernels
  • ciss2isis to ingest a titan image
  • spiceinit pointing to new kernels
  • campt fails with
    An unknown NAIF error has been encountered. The short
    explanation provided by NAIF is [SPICE(ZEROVECTOR)]. The Naif
    error is [SURFPT: The input vector is the zero vector.]"

I noticed in the release notes " Removed SpkCenterId functions in Cassini camera models due to spkwriter writing positions of Cassini relative to Titan but labeling it in the kernel as the position relative to the Saturn Barycenter". That seems to indicate the change is to the camera model, not just the writer programs.

Do I need to reprocess my images again under isis7.1.0 or is something else going on here?
My new kernels are under the titan project work area here: /lweller/All_CB3_MT1/NewMissionKernels/
See Titan_CISS_2022_ck.bc and Titan_CISS_2022_spk.bsp and the *_summary.txt files. The input list of images for each run is named updated_CISS_Titan_FFCombined7_Thin_PixReg_SubReg_Ground.lis.

I need to know sooner than later if I have to reprocess my images under the latest version since I have other work to do with this data this fiscal year. Thank you.

[jessemapel]

You shouldn't need to re-process your imagery. The camera model was updated, but not the parts that are persisted on Cube files, just some hard-coded labels that ckwriter and spkwriter look at. So, your processing should be correct. There could be multiple problems here and we only fixed one of them.

[lwellerastro]

Well, there might be something to doing everything under 7.1 because I repeated the single image test (ingest, spice, create kernel, apply new kernel to newly ingested image, campt) and it works without error. Camera information matches between ingested/spice and ingested/spice w/new kernel as well.

[jessemapel]

it sounds like there may be some bad ephmerides on the images somehow. Very strange.

[lwellerastro]

Defaulting via spiceinit, but that is followed by a "direct" single location deltack then bundle, but I'm not sure that plays into it at all.

[lwellerastro]

This appears to be a problem specifically with the jigsaw updated images.

I tested using a single deltack'd image (input into jigsaw):

• created ck and spk kernels for image
• applied the new kernels to an ingested image
• campt works and output matches the deltack image which kernels were based upon

Tested using a jigsaw output updated image:

• created ck and spk kernels for image
• applied the new kernels to an ingested image
• campt fails
  Message = "An unknown NAIF error has been encountered. The short
  explanation provided by NAIF is [SPICE(ZEROVECTOR)]. The Naif
  error is [SURFPT: The input vector is the zero vector.]"

All of this was done via isis7.1.0 but the kernels were based upon isis7.0.0 deltack and jigsaw.

Is it worth running jigsaw/updating via isis7.1.0 and seeing if that makes some sort of difference?
Should this be a new post?

[jessemapel]

If it doesn't take very long that would be fine, but I don't expect things to just be fixed in 7.1. I think narrowing it down to jigsaw gives us plenty to go off of.

[github-actions]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[blandoplanet]

This has not been resolved but is a high priority

[amystamile-usgs]

@lwellerastro I am having trouble accessing the titan project folder. Is there another place I could access the ck/spk kernels and jigsaw images?

Nevermind, I was able to get to the folder.

[amystamile-usgs]

@lwellerastro So far I have pinned down that these jigsawed cubes have invalid velocity data for the instrument position and this is why we are seeing invalid values in the spkwriter that is carrying over to campt.

Seems like I need to start debugging this in jigsaw. Do you happen to have the original jigsaw commands you used to create these cubes?

[lwellerastro]

Hi @amystamile-usgs, below is the jigsaw command I used when updating the images. Very standard command used for framing camera that I work with. When I bundle for line scan I would solve for camera accelerations. This is super normal and I have built good kernels on commands like this for years.

jigsaw froml=updated_CISS_Titan_FFCombined7_Thin_PixReg_SubReg_Ground.lis cnet=CISS_Titan_FFCombined7_Thin_PixReg_SubReg_Ground.net \
        onet=JigOut_CISS_Titan_FFCombined7_Thin_PixReg_SubReg_Ground.net \
        radius=yes update=yes errorprop=no \
        sigma0=1.0e-10 maxits=10 \
        camsolve=angles twist=yes \
        spsolve=position \
        camera_angles_sigma=1 \
        spacecraft_position_sigma=2000 \
        point_radius_sigma=2000 \
        point_latitude_sigma=8000 point_longitude_sigma=8000 \
        file_prefix=RadAngTwist_SpkPos_Ground

If you need to review the images before being updated by jigsaw, see the file list CISS_Titan_FFCombined7_Thin_PixReg_SubReg.lis in the same directory (titan project work area/lweller/All_CB3_MT1/NewMissionKernels). We can use chat if you need more details on locations.

[lwellerastro]

@amystamile-usgs I ran tabledump name=InstrumentPosition on one of my updated Titan images, and as you already confirmed via the kernels above, there is a bunch of information missing:

cat tbldump_instpos_N1509135956_2_jigkern.csv
J2000X,J2000Y,J2000Z,J2000XV,J2000YV,J2000ZV,ET
nan,nan,nan,nan,nan,nan,183715072.81547

but it is there prior to being updated:

cat tbldump_instpos_N1509135956_2_spiced.csv
J2000X,J2000Y,J2000Z,J2000XV,J2000YV,J2000ZV,ET
73868.73995451,-150163.04906303,3280.9575399262,-2.5607932864925,4.986094028286,-0.096463600936781,183715072.81547

Clearly jigsaw is the culprit for the bad kernels, but it feels very Cassini ISS Titan specific because I've been running table dump on various other jigsaw updated datasets and they all seem to have valid output (well, no nan's). These are images that in some cases had spacecraft position solved for, but others did not. A mix of framers and line scanners.

I'm not sure it's helpful at all, but I have jigsaw updated images of Enceladus acquired by Cassini ISS (same camera as the Titan data), that have good InstrumentPosition output, but I did not solve for spacecraft for those data.

[amystamile-usgs]

I agree there's something unique with Cassini ISS Titan and jigsaw going on here.

[lwellerastro]

While looking for other data to run tests on, it was determined that Galileo SSI images of Europa had similar problems where information was omitted (nan) after solving for spacecraft position and being updated by jigsaw.

A spacecraft kernel generated for one of the updated images produced similar errors to the Titan data after applying the kernel to an image and running campt.

See data under my user work area Isis3Tests/Jigsaw/Galileo/

[lwellerastro]

After data loss and some other software issues, the full Titan dataset has been reprocessed and updated by jigsaw using isis8.0.0-RC2.

Confirming here that jigsaw NAN InstrumentPosition velocities have been corrected and the image tested in this comment now produces valid output via tabledump:

tabledump from=N1509135956_2.sharp.cub to=tbldump_instpos_jigsaw_N1509135956_2.csv name=InstrumentPosition

cat tbldump_instpos_jigsaw_N1509135956_2.csv 
J2000X,J2000Y,J2000Z,J2000XV,J2000YV,J2000ZV,ET
73868.654790768,-150162.92778655,3280.9288490726,-2.5607932864925,4.986094028286,-0.096463600936781,183715072.81547

Also have confirmed that kernels based on jigsaw updated images produce expected results.
Thanks!