Smithed New Horizons kernels for LORRI and MVIC

[rbeyer]

Description
Incorporate team-produced smithed CK and SPK kernels for New Horizons LORRI and MVIC images.

The New Horizons team created smithed CK and SPK kernels for LORRI and MVIC images in the process of creating their mosaics and terrain models detailed in Schenk et al. (2018a & 2018b), and are in the process of starting to work with the PDS and NAIF to include these kernels in an official PDS delivery from the team.

In parallel with that activity, I have been authorized to release these kernels so that we can get them integrated into ISIS in parallel with the PDS process. It is possible that the filenames or structure of these kernels may change as a result of the PDS process.

Also, due to some limitations in the way the ISIS jigsaw program worked in ISIS (version 3.5.2), we have several 'sets' of kernels that must be applied under the right conditions. One cannot simply use them all, or dump them into a single meta-kernel, but must select the right `set' depending on the use case (because they are mutually exclusive, more details in the README). This aspect is likely to be the most challenging part of integrating these kernels into ISIS, as you either have to incorporate complicated code to recognize the right 'use case' or provide sufficient instructions for users to 'do it themselves.'

To faciliate this work, we created .par files which we use like a meta-kernel for spiceinit for each of the cases, and I have a Python 3 wrapper around spiceinit that attempts to divine the right information from the labels to point the -par argument of spiceinit to the right set of kernels, but the user must still specify Pluto or Charon (as some images have both objects in them, and depending on which object one wants to work with, the right set of kernels must be chosen), which may be a starting point for the logic that may be needed to incorporate into the system.

The draft kernels, and a README describing them are available at https://byss.arc.nasa.gov/rbeyer/NHkernels/ or as a single tarball at: https://byss.arc.nasa.gov/rbeyer/NHkernels.tgz

[jessemapel]

@rbeyer ~Can you provide more detail about the logic required for kernel selection? We already have the ability to check specific lable values when determining what kernels to load. I am unsure how complex we can make checks, but there is some level of functionality there.~

edit: nevermind I just read the README, I think we can handle this. The KernelDbs that spiceinit uses are able to select kernels based on instrument ID, target, and time range.

[rbeyer]

Also realized that there are not currently good radii values for Pluto and Charon submitted to NAIF (also working on that). This nh_pcnh_006.tpc file is a PCK that probably needs to go into the newhorizons/ data area until the 'formal' version works through the system and is available from NAIF. I don't think there are any other supporting kernels that are needed, but I could be wrong.

[jessemapel]

@rbeyer Where is that PCK available at NAIF? I don't see it in the PDS archive that they point to https://naif.jpl.nasa.gov/pub/naif/pds/data/nh-j_p_ss-spice-6-v1.0/nhsp_1000/data/pck/

[rbeyer]

Also realized that there are not currently good radii values for Pluto and Charon submitted to NAIF (also working on that).

It is not at NAIF.

It is one of the things that the New Horizons team needs to get delivered (hence "working on it") to NAIF. The contents could be assembled from the papers that are quoted in the attached kernel, so it isn't 'secret' knowledge, it just isn't conveniently already at NAIF. You could also imagine that this information would go to create a new pck0011 in the 'base' kernel directory, not sure how NAIF will handle it when we submit. Most likely it will go into a separate New Horizons place to start and may eventually get added to pck0011, not sure what the vetting process is to version bump the main solar system pck, but we did fly by a 'new' planetary system, so that should count for something.

[Kelvinrr]

@rbeyer Do you have example images that were used in the solution I can use for testing? Just that I can run through spiceinit and make sure the correct kernels are being used. So one Lorri image with pluto target, Lorri with Charon target, MVIC with pluto target, MVIC with Charon target (presumably need ones for each color channel + panchromatic detector ).

Alternately pointing me to an area of image IDs or similar for images used in the solution would also be helpful.

[rbeyer]

Sure. I think you're just after a list that you can grab from the PDS, but let me know if you want me to send actual files, or processed cubes.

Names below in parentheses (e.g. PELR_P_LEISA_HIRES) are observation sequences, and many possible images may be part of such a sequence. They will all have similar REQID fields in the original FITS files.

LORRI with Pluto: lor_0299177087 (part of PELR_P_LEISA_HIRES) LORRI with Charon: lor_0299175643 (part of PELR_C_LEISA_HIRES) MVIC color with Pluto: mc0_0299178092, mc1_0299178092, mc2_0299178092, mc3_0299178092 (the four MVIC filters for PEMV_01_P_COLOR2) MVIC pan with Pluto: mp1_0299178832 (PEMV_01_P_MPAN1) MVIC color with Charon: mc[0-3]_0299176432 (four MVIC filters for PEMV_01_C_COLOR_2) MVIC pan with Charon: mp1_0299180334 (PEMV_01_C_MVIC_LORRI_CA)

Let me know if any of this is unclear or if I missed the mark.

[jessemapel]

@Kelvinrr If you look at the comments on the kernel files ckwriter and spkwriter should add a list of exactly which images were used in the solution and how they were spiceinit'd.

[Kelvinrr]

@rbeyer The kernels are all in and Lorri is tested working fine with the images you supplied. Although, it seems like the mvic images you gave are not within the time ranges of the images used in the solution? Looking at the comments for the CK kernels for MVIC Pan, for example, I have four images: pmc_195_1_8832l1, pmc_195_2_9552l1, pmc_195_1_1303l1 and pmc_195_2_1722l. None of these I can find anywhere (the product ID format seems different than the MVIC images I've seen so far). I downloaded the entire MVIC Pluto Encounter and Cruise dataset from the small bodies node and they don't seem to exist there?

Any idea on how I can find these images to test they get spiceinit-ed correctly?

[rbeyer]

Sigh (not your fault @Kelvinrr).

You can see that these kernels (based on the username in the comments file) were created by Paul Schenk at the LPI. Paul doesn't like to use the PDS filenames (because you could argue that they lack useful context information), and so he typically converts the PDS filenames (which are based on the spacecraft clock) to a name format that is more convenient for him, and that is where those filenames come from.

So here's your decoder: pmc_195_1_8832l1 = mp1_0299178832 pmc_195_2_9552l1 = mp2_0299179552 pmc_195_1_1303l1 = mp1_0299181303 pmc_195_2_1722l = mp2_0299181722

One of these, mp1_0299178832, was one I pointed out above. Are you saying that you can't get it to clear through spiceinit when using the plu_MVI_170425_pan.bc and plu_MVI_170425_pan.bsp?

And when you say 'testing and working' does this mean that the programs runs, or that you then compare the map-projected image to the global mosaic that we released via the PDS?

[Kelvinrr]

So I just made sure ISIS is picking up the appropriate kernels in running spiceinit, I generally trust that ISIS works properly downstream and the kernels are correct. I'm more worried about getting MVIC at least spiceiniting with the SMITHED kernels. The problem seems to be the times are not lining up as mp1_0299178832 starts ever so slightly before the start time of the kernels. mp1_0299178832's start time = 2015-07-14T11:21:59.146 and kernel start time = 2015 JUL 14 11:23:08.188510 TDB. Forcing the start time gets the cubes grabbing the smithed kernels just fine.

Were the mvic images altered in any way other than the bundle and IDs?

[rbeyer]

Hunh.

I do not believe that the images were altered in any other ways. A two-minute start difference is ... significant. I will try and see if I can track this down on my side, but I may not get to it until this afternoon or next week.

[jessemapel]

@Kelvinrr I saw a similar difference when updating the Enceladus kernels. The kernelDB files store times in TDB which is about 70 seconds off from UTC. Try converting both times to ET and checking.

[Kelvinrr]

@jessemapel Seems to be the thing, 2015 JUL 14 11:23:08.188510 TDB translates to 2015-07-14T11:22:00.00475 UTC which is a lot closer (although not exact, .8 seconds off) to 2015-07-14T11:21:59.146 UTC start time in the image. I'm willing to take this as the accepted solution and pad the time windows if there is no issue with it.

Seems there needs to be a more robust solution later in using the same time for both.

[rbeyer]

I'm not sure what calculations you're doing, but in the FITS labels for mp1_0299178832, STARTMET= 299178838.132. When I convert that SCLK time to Ephemeris Time, and then on to UTC time via the SPICE toolkit, I get 2015 JUL 14 11:21:59.878 (just as reported above).

When I take the plu_MVI_170425_pan.bc file (with the naif0012.tls LSK and the new-horizons_1121.tsc SCLK), and run it through the SPICE toolkit's ckbrief command with -utc, I get this:

Object: -98000 Interval Begin UTC Interval End UTC AV

---

2015-JUL-14 11:22:00.004 2015-JUL-14 11:24:26.049 Y 2015-JUL-14 11:34:00.004 2015-JUL-14 11:40:51.097 Y 2015-JUL-14 12:03:11.004 2015-JUL-14 12:06:49.173 Y 2015-JUL-14 12:10:10.004 2015-JUL-14 12:13:51.383 Y

This also shows a difference between the start time of the observation and the start time of the kernel, but by less than a second, which is consistent with what you're reporting above.

I suspect that the 'start time' reported in the label is the time that the electronics start warming up, and photons are not captured until a short time later (hence the difference). I can tell you that when these kernels are loaded manually into spiceinit with this image, they seem to work fine.

[Kelvinrr]

I simply converted the TDB times in our SPICE .db files (a metadata file containing start and stop times for segments in a binary kernel) to UTC using the SPICE tool kit with the same clock kernels you used. Seems like we computed the same thing in a different way. In either case, I added slight padding to the kernel DB files which seems to have MVIC images spiceinit-ing correctly.

[Kelvinrr]

I'm going to close this for now as things seem to be working and if after the next data release you see an issue feel free to re-open.