Isis3: New SPICE data available for Voyager

[ascbot]

---

Author Name: Stuart Sides (@scsides)

---

Folks,

FYI I've made a few small tweaks to the Voyager SPICE kernels collection.
Some better data for the spacecraft trajectories at Saturn were added--as
usual, obtained from Bob Jacobson. Otherwise I've added more descriptive
information about this "eclectic" set of data in the top-level aareadme.txt
(found at http://naif.jpl.nasa.gov/pub/naif/VOYAGER/kernels/aareadme.txt)
and in some kernel-specific aareadme files further down in the tree.

Other than ingesting:

• any further spacecraft trajectory SPKs produced by Jacobson (some
  expected),
• any CKs that might be provided by the Rings Node, and
• updated SCLKs made by NAIF each time new clock correlation data are
  received from the project, â?¦

â?¦ NAIF has no specific plans for further augmentations or improvements to
the Voyager kernels collection.

If there are questions or issues regarding these data, please either send
email or we can discuss these at the next PDSMC meeting in Maryland.

--Chuck

[kberryUSGS]

Related to #2853

[jlaura]

Are these kernels being included in ISIS?

[kberryUSGS]

@jlaura The Voyager 2 kernels we are currently providing with ISIS, and that were used with the data for #2853 are out-of-date. I'm not yet sure that updating the voyager 2 kernels will fix Lynn's problem, but it might.

[lwellerastro]

I tried using the kernels from the rings node https://pds-rings.seti.org/voyager/ck/ on an image (different from the ones in #2853) under isis2 since isis3 was not capable of using the data (discrete versus the continuous kernels) and I did not see any difference in the spice. It is 100% possible I did not feed spicelab the proper information or in the right order - it's been a long time since I've done anything in isis2.

I got the impression from the rings node website (after rereading the short discussion there) that the Voyager kernels at Jupiter had not been improved since the column for C-smithed was set to No. If that is the case perhaps the SPK kernel improvements could help.

[kberryUSGS]

Description of kernel updates:

No updates to: fk, ik, didn't change anything in the iak

Updates to:

• sclk updated to: vg200027.tsc, but would not expect this to change anything much.

• spks:

For Jupiter: Jupiter's satellites kernel: jup310.bsp and voyager spk vgr2_jup230.bsp
For Uranus: Not updated, no new kernels available.
For Saturn: Updated to use vgr2_sat337.bsp and sat393.bsp (updated saturn satellite ephemeris.)
For Neptune: Not updated, no new kernels available.

• cks: I did update this to use the rings node kernels. I used spacit to convert the kernels to a form usable to ISIS.

Jupiter: Updated to use: vg2_jup_version1_type2_iss_sedr.bc
Saturn, Neptune, Uranus: did not update to use rings node kernels, but could.

I only tested this setup on exactly one image of Europa, and found only a very slight pointing difference.

To test this, use the data area at: export ISIS3DATA=/work/users/kberry/ISIS3DATAVoyager.

[lwellerastro]

@kberryUSGS I don't know when I can check out what you have under your data area as I have a number of things going on at once. How do you see this playing out?

I doubt that I will re-init my images for these updates since they won't help my problem images and the spice for my usable images is completely off the target so we had to manually move it onto the target via deltack and likely won't be much different with the updates.

I guess, if I confirm that the updates create no conflict with what is already on my image labels, then we can put the new kernels in the system?

Was this post closed just until we figure this out? I'm not sure I understand what closed means under git.

[kberryUSGS]

@lwellerastro I'm so sorry I never responded to this. I think have a better handle on my github notifications situation now. I was thinking that what you said: "if I confirm that the updates create no conflict with what is already on my image labels, then we can put the new kernels in the system?" would be the way forward at the time, but I think @jessemapel may now be updating the voyager kernels as part of #3255

[lwellerastro]

My bad - I never got to testing what you made available in you work area. Actually, @jessemapel is not updating the voyager kernels as part of #3255, only the planetary satellite emphemerides kernel (something along those lines) and the associated planetary (?) kernel de430, which is breaking a number of tests. Which is sort of concerning (for other bodies/projects). I am months into this project at this point and I could have used updates sooner than later (again, by bad, not yours - I could have just tested what you had pointed me to), but just had to move on (and Ken's fix to jigsaw helped me do so, #2591 ...how do I make this a link?), so at this point, other than the kernel/spkwriter issue, I don't think I can handle more "new".

Hold on, I'm seeing the kernel Jesse grabbed is the first one in your list - jup310. Maybe Jesse should know about the others and just grab those? I do have to re-spice all of my data at some point to get to the jup310 kernel and get spkwriter/spiceinit to work properly (what #3255 is about). I'll chat with him this afternoon or tomorrow...I'm sure he would like to wrap up 3255, so he might not jump on pulling new kernels. I'll chat with him and he or I will get back to you so we can get this closed one way or another. Thanks for the response! Having fun with spice yet?

[jessemapel]

@lwellerastro I'm going to look at the new voyager and galileo kernels to see if just updating all of the kernels does fix this.

[jessemapel]

Kernels are updated

[lwellerastro]

@jessemapel , the kernels currently on my Voyager images no longer exist and this is a problem:

Message = "Spice file does not exist
           [/usgs/cpkgs/isis3/data/voyager2/kernels/spk/vg2_jup.bsp]"

I appreciate that there are new kernels to potentially tap into, but shouldn't we be keeping the old ones around for backwards compatibility?

I am currently not in a position right now spice all of my voyager data - each and every image has bad spice so we (mostly Ethan over the course 5+ weeks) moved the spice onto the images using deltack. It's true many programs will use the blob on the image for spice info, but not all do so as the error above indicates (from ckwriter; campt fails as well with a different error). When I re-spiced my Galileo data with the new kernels the dozen or so images that needed special attention via deltack had to be inspected for the new spice position and most had to be readjusted. That was ok for a couple of handful of images, but we can't do that for the many hundreds of voyager images that required the work.

I had intended on working with the current spice and deltack'd updated images, getting them bundled, then making kernels based on that adjustment before re-spicing with new kernels (knowing that I had much more work to do, but I'd at least be set up with the latest kernels even is just as a name on the label). Maybe there is a flaw in that idea (and it's literally what I was testing when I came across the missing kernel problem), but we can not spend any time fixing the spice on these images if it goes somewhere different due to newer spice.

I'm confused why we remove files as we have never done that before so hopefully this was just an oversight.

[jessemapel]

I can add the old kernels back in. What was the campt error? campt should be exclusively using the blobs on the cubes.

[jessemapel]

The kernels are back now.

[lwellerastro]

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

I'll try ckwriter again.

[lwellerastro]

ok, ckwriter is good and I think the campt error is because I let it default to the center of the image and there is no data/spice there. Total rush/pilot error there. Yeah, only half the frame has data - nothing but limb and disk for this data.

Thanks for putting the files back out there. Did any disappear for Galileo in the process?

[jessemapel]

The galileo kernels are still there

[lwellerastro]

Great, and thanks again for reviving the old data - everything appears to be working as expected (writer generated ck and spk kernels being applied via spiceinit to voyager and galileo data).