Update or remove smithed Enceladus kernels: cksmithed=true produces undesirable results

[blandoplanet]

ISIS version(s) affected: 4.1.0 and above I think. Tested on 6.0.0

Description
In 2019 the USGS (@lwellerastro) generated updated kernels (ck and an associated pck) for a subset of Cassini ISS images of Enceladus. These were added to ISIS in release 4.1.0, enabling their use with the 'cksmithed=true' flag when running spiceinit. It was verified at the time of implementation that the kernels worked properly (i.e., both that the images were picking up the correct ck and pck and that the projected images were properly located on Enceladus). Unfortunately, these kernels are now broken - most likely from an update to the Cassini spk that was made in 2020 after end of mission. The result is that projected images no longer align when cksmithed=true is used. Users therefore expect that they are getting improved image locations but are still getting what are effectively uncontrolled images.

How to reproduce

1. Pull Cassini images from the PDS and ingest with ciss2isis.
2. Run spiceinit with cksmithed=true.
3. Project the images and drop into a GIS.
4. Compared to updated level 1 images (i.e., from the control solution) available in /work/users/lweller/Enceladus/MrgGapDenseNets/TargetBody/SalihFreeUpdate/Updated_Lev1/

There are example cases staged in /work/users/mbland/Enceladus-ISS/kernel_check/ (see README files)

Possible Solution
This appears to be a kernel issue rather than an actual software issue. When comparing the kernel groups of @lwellerastro's Lev1 and a "clean" version where cksmithed=true was used there are two differences that stand out. First, the control solution uses de405 whereas the cksmithed version picks up de430. Second, Lynn's version uses an spk with a 2018 delivery date (e.g., 180628RU_SCPSE_09317_09339.bsp) whereas the cksmithed version picks up the newer spk with a 2020 delivery date (e.g., 200128RU_SCPSE_09296_09334.bsp for the same image). I attempted to force the cksmithed version to pick up the de430 kernel using the tspk= flag in spiceinit, which appeared to work properly (i.e., it appears in the kernel group) but made no difference in the image locations (see cubes in /work/users/mbland/Enceladus-ISS/kernel_check/tspk-check/). This suggests that the spk is the problem.

Solutions:

1. Have spiceinit point to the OLD 2018 version of the spk when cksmithed is used.
2. Remove the Enceladus kernels altogether

Additional context
Two different groups have contacted me about "problems" with the kernels. It would be better to not have them available at all then to have broken kernels available.

[astrostu]

I don't know the details of how this works, but is it possible to still have the kernels available, but if you use these updated ones to use the OLDER SPKs? Or would that be too complex to get people to do it properly? [D'oh, I see that as your first possible solution]

Second idea: Since these kernels were ostensibly produced via a control network that is still perfectly valid, could you re-SPICEINIT the images with the latest SPK, run JIGSAW with the old network, and output new kernels to put into the ISIS distribution?

[lwellerastro]

@blandoplanet the location you pointed to for the updated which were the basis for the kernels is incorrect - that is an intermediate product used to solve for the location of the prime meridian.

These are the updated cubes and input into ckwriter:
/work/users/lweller/Enceladus/MrgGapDenseNets/TargetBody/2019SHAPE_PM/Updated_Cubs/*cub

This file was produced by ckwriter when the camera kernel was created and specifies the base kernel information for every image in the kernel:
/work/users/lweller/Enceladus/MrgGapDenseNets/TargetBody/2019SHAPE_PM/Enceladus_CISS_2019Shape_camera_summary.txt

Here are the spk kernels used for the various images:

egrep "kernels/spk" /work/users/lweller/Enceladus/MrgGapDenseNets/TargetBody/2019SHAPE_PM/Enceladus_CISS_2019Shape_camera_summary.txt | sort -u
    $base/kernels/spk/de430.bsp  - applied to all images
    $cassini/kernels/spk/180628RU_SCPSE_05034_05060.bsp
    $cassini/kernels/spk/180628RU_SCPSE_05060_05081.bsp
    $cassini/kernels/spk/180628RU_SCPSE_05186_05205.bsp
    $cassini/kernels/spk/180628RU_SCPSE_06240_06260.bsp
    $cassini/kernels/spk/180628RU_SCPSE_08067_08078.bsp
    $cassini/kernels/spk/180628RU_SCPSE_08220_08272.bsp
    $cassini/kernels/spk/180628RU_SCPSE_08272_08294.bsp
    $cassini/kernels/spk/180628RU_SCPSE_08294_08319.bsp
    $cassini/kernels/spk/180628RU_SCPSE_09317_09339.bsp
    $cassini/kernels/spk/180628RU_SCPSE_10132_10146.bsp
    $cassini/kernels/spk/180628RU_SCPSE_10216_10256.bsp
    $cassini/kernels/spk/180628RU_SCPSE_10326_10344.bsp
    $cassini/kernels/spk/180628RU_SCPSE_10344_11003.bsp
    $cassini/kernels/spk/180628RU_SCPSE_11003_11041.bsp
    $cassini/kernels/spk/180628RU_SCPSE_11246_11267.bsp
    $cassini/kernels/spk/180628RU_SCPSE_11267_11303.bsp
    $cassini/kernels/spk/180628RU_SCPSE_11303_11337.bsp
    $cassini/kernels/spk/180628RU_SCPSE_11337_11357.bsp
    $cassini/kernels/spk/180628RU_SCPSE_12077_12098.bsp
    $cassini/kernels/spk/180628RU_SCPSE_12116_12136.bsp
    $cassini/kernels/spk/180628RU_SCPSE_15295_15310.bsp
    $cassini/kernels/spk/180628RU_SCPSE_16329_16363.bsp

The spk varies according to the image which makes it more difficult to force isis to do things manually. You need to know which of the above listed kernels was applied to which image. All of this is in the summary files from ckwriter, but I don't recall if we shared that online somewhere.

[blandoplanet]

Thanks @lwellerastro. I've updated the directory I listed above with the proper cubes for comparison.

@astrostu, regarding your second solution - yes, that's certainly one possibility but will require time (and funding) to do, which is challenge given that this project ended several years ago. Probably not a lot of time, but there are always complications. It seems like we should have a simple way to tell spiceinit to use a specific "set" of kernels (i.e., see @lwellerastro's post regarding needing to know which spk is "right" for a given image, which seems to precludes batch processing - or else maybe I'm missing something). I.e., you can specify a specific pck, can you say "check this set of spks for the correct one." Otherwise we will have to re-jigsaw every time there's an update to a mission spk (maybe that's not common enough to worry about). A third solution (perhaps best) is to just serve the updated data itself (e.g., the ARD approach) and not have users worry about kernels.

[jessemapel]

I think this is possible but it may be a little tricky or take some code changes on our end:

Have spiceinit point to the OLD 2018 version of the spk when cksmithed is used.

I'm adding this to the list of reasons why the predict/recon/smithed setup is troublesome. See #3482

[acpaquette]

I can confirm that the spks are causing the differences between the original cubes that were used in the control network produced in 2018/2019, and new cubes that used the smithed kernels but new spks. I don't think there is a super clean solution to this, that I can think of.

We could try to add a dependency key into kernel selection groups in the kernel db files, but this doesn't account for the use of MANY different spks for all of the cubes used in the network over a range of time. All spks could be written into a single spk and made the dependency for the smithed file but that's a lot of additional moving parts and pieces into a kernel selection system that seems to be showing some clear limitations. Not to mention that file may be pretty big.

Something else that could maybe be done is allow spiceinit to use a fuzzy file find in the spk field instead of expecting a single file. This would be a way to limit the kernel selection in various missions like Cassini that have overlapping spks for certain time frames. It would still require people to know exactly what kernels need to be used with certain images.

Combining both may lead to something that could work, but it may only be applicable to Cassini images which is somewhat concerning to have code in something as general as spiceinit/KernelDB to handle a particular mission case. Something to consider going forward but that seems to be the best software solution I can think of.

[blandoplanet]

I agree that having Cassini-specific code within spiceinit is not a good solution. Based on your comments, I would recommend just pulling the kernels and waiting until a more general solution to this problem (which potentially affects other data sets - e.g., Titan) is found.

[acpaquette]

@lwellerastro @blandoplanet The kernels have been removed and the kerneldb file updated. I have tested this on one test image and it is picking up the spk that is expected. This more or less closes this issue for the time being.

[acpaquette]

Also, so the information is available somewhere, I have disabled the Cassini kernel update script within Astro. This prevents the new spks causing this problem from being downloaded, but also prevents other new kernels from entering the data area

[lwellerastro]

Also, so the information is available somewhere, I have disabled the Cassini kernel update script within Astro. This prevents the new spks causing this problem from being downloaded, but also prevents other new kernels from entering the data area

@blandoplanet, is this something we really want? Sure, the new kernels are breaking our smithed kernels, but new kernels are generally better so I'm not sure we wouldn't want to pick them up. Or maybe I'm not understanding what is being said here.

[blandoplanet]

@lwellerastro @acpaquette I think this change is okay. Since the mission is done I don't expect there to be any new updates to the Enceladus/Cassini kernels unless someone else (including us) makes new smithed kernels and we explicitly want to add them. In that case I'm assuming we can revert this change.

[acpaquette]

@lwellerastro The job can be re-enabled when necessary and then we can remove the kernels again as necessary

[lwellerastro]

@acpaquette, I am sufficiently confused between this post and the Titan kernels post that I have to ask which new spk's are we talking about as far as preventing downloads are concerned? Astro's or the mission? Sorry to be dense, I'm just confused.

[blandoplanet]

I have confirmed that trying to use the smithed kernels results in ISIS using the default kernels. That is, running 'spiceinit from=foo.cub cksmithed=true' produces the same result as simply running 'spiceinit from=foo.cub'. This is the desired result (unfortunately).