Make smithed ck kernels for Enceladus available in ISIS

[blandoplanet]

Description
In FY19 the USGS (i.e., @lwellerastro) generated a new set of ck for a subset of Cassini ISS images of Enceladus (n=621, which is most of the moderate to high resolution images). The kernels will soon be available on Astropedia, along with a description of the method by which they were generated. Ideally, these kernels would also be available as an option in ISIS as well (e.g., using 'cksmith=true' in spiceinit). The complication is that the kernels also require a new pck to be specified and it's not clear to me how (or even whether) the pck can be handled.

The kernels are available here...
/work/users/lweller/Enceladus/SmithedKernels/Enceladus_CISS_2019Shape_camera.bc
/work/users/lweller/Enceladus/SmithedKernels/cpck15Dec2017_2019Shape.tpc

At the moment they can applied simply by running
spiceinit from=image.cub ck=Enceladus_CISS_2019Shape_camera.bc pck=cpck15Dec2017_2019Shape.tpc

[lwellerastro]

n=621 should be n=625

[jessemapel]

@blandoplanet Is there any reason why a user would use smithed CKs, but not the updated PCK? There are already some smithed CKs from CICLOPS that are of the form YYDOY_YYDOYcb_ISS.bc. I'm assuming your kernels should take precedence over these?

[blandoplanet]

Users should always use the updated PCK with the new CK. There isn't a case for using the CKs alone.

I am unfamiliar with the CICLOPS CK kernels, and don't know how they were derived or what images they cover. I would argue that the new USGS kernels should take precedence, but that can be discussed.

[jessemapel]

@blandoplanet @lwellerastro How were these images spiceinit'd originally? I'm running into a problem where the segment boundaries in the smithed CK are smaller than the exposure times of the images. For the first image, N1487299402_1, it's time range is 2005-048T02:16:57.245 to 2005-048T02:16:57.295 but the segment boundaries in the CK are 2005-048 // 02:16:57.267 to2005-048 // 02:16:57.273, which doesn't cover the full 50 ms exposure.

For the vast majority of uses, ISIS only needs the center exposure time, which is covered, and I can adjust the DB file that spiceinit uses so it looks like the kernel covers the entire image, but I'm concerned about that being a band-aid fix.

[blandoplanet]

@lwellerastro can provide more details later and correct me where I'm wrong...

We didn't start from the reconstructed kernels. We used updated image locations from Tammy Becker's original (sparser) network (completed in ~early 2018). Ideally we would have reingested with clean data and just applied Tammy's kernels, but a change the mission made (I think to the spacecraft clock) effectively broke that kernel set. So we started from Tammy's images themselves. Tammy would have ultimately started with the reconstructed kernels.

[jessemapel]

For right now I am going to pad the kernel db windows then.

[jessemapel]

So, I've staged the new kernels and updated the kernel DB files. As of right now, users can enter cksmithed=true to get the smithed ck but will need to manually specify the smithed pck. Once #3716 is merged, users will get both when they specify cksmithed=true.

[lwellerastro]

For right now I am going to pad the kernel db windows then.

The image spice history is even more convoluted than what @blandoplanet has conveyed, but that seems besides the point. @jessemapel, I see that New Horizons had a padding problem as well - does that mean you understand the time window issues for both data sets and padding the window solved the problem?

I wonder why the writer programs are not handling this. I thought they had a built-in time padding for the beginning and end of a segment, one that was maybe too big in some cases (it created issues for M3).

[jessemapel]

@lwellerastro My understanding is that the writer programs don't pad because you would have to extrapolate and that could introduce some weird error. Instead you have to pad at spiceinit when you have the full kernels available so you don't need to extrapolate.

[lwellerastro]

I have never used the padding options in spiceinit or know of any use of those parameters for any projects in astro. Perhaps all of the padding Kris mentions below is not quite the same thing as the window padding in the kernel db.

From the documentation History:

Kris Becker | 2011-05-04 | Pad CK records with a small time on each end of CK segment to avoid round off issues.

From Issue #2057:

There are some additional improvements/modifications to ckwriter and spkwriter that should be considered as well:

There is always at least 3 records in the individual ISIS cube kernel segments that pad for roundoff issue. The two added (for framing instruments) before and after the center exposure time are 3 millisecond pad records with constant ephemeris. We need to change these programs to pad around the full exposure duration to make the kernels more generally useful. Also should allow the user to provide the pad time on each end of the kernel with the default set to 0.003 seconds.

[lwellerastro]

What do I have to do to pick up the new kernels? Running under isis4.1.0-RC1.

I have ingested an image that was included in the updated kernels, but when I spiceinit I don't seem to be getting the updates. My test file is available under /work/users/lweller/Isis3Tests/Spiceinit/Enceladus/.

I first ran spiceinit in default mode which resulted in the following kernels information:
spiceinit from=N1858919920_1_defaultspice.cub

Group = Kernels
NaifFrameCode = -82360
LeapSecond = $base/kernels/lsk/naif0012.tls
TargetAttitudeShape = ($base/kernels/pck/pck00009.tpc,
$cassini/kernels/pck/cpck15Dec2017.tpc)
TargetPosition = ($base/kernels/spk/de430.bsp,
$base/kernels/spk/sat425.bsp)
InstrumentPointing = ($cassini/kernels/ck/16328_16333ra.bc,
$cassini/kernels/fk/cas_v40.tf)
Instrument = Null
SpacecraftClock = $cassini/kernels/sclk/cas00172.tsc
InstrumentPosition = $cassini/kernels/spk/200128RU_SCPSE_16329_170-
26.bsp
InstrumentAddendum = $cassini/kernels/iak/IssNAAddendum004.ti
ShapeModel = Null
InstrumentPositionQuality = Reconstructed
InstrumentPointingQuality = Reconstructed
CameraVersion = 1
Source = isis
End_Group

Then a second time asking for smithed kernels:
spiceinit from=N1858919920_1_smithedspice.cub cksmithed=true spksmithed=true

Group = Kernels
NaifFrameCode = -82360
LeapSecond = $base/kernels/lsk/naif0012.tls
TargetAttitudeShape = ($base/kernels/pck/pck00009.tpc,
$cassini/kernels/pck/cpck15Dec2017_2019Shape.-
tpc)
TargetPosition = ($base/kernels/spk/de430.bsp,
$base/kernels/spk/sat425.bsp)
InstrumentPointing = ($cassini/kernels/ck/16328_16333ra.bc,
$cassini/kernels/fk/cas_v40.tf)
Instrument = Null
SpacecraftClock = $cassini/kernels/sclk/cas00172.tsc
InstrumentPosition = $cassini/kernels/spk/200128RU_SCPSE_16329_170-
26.bsp
InstrumentAddendum = $cassini/kernels/iak/IssNAAddendum004.ti
ShapeModel = Null
InstrumentPositionQuality = Reconstructed
InstrumentPointingQuality = Reconstructed
CameraVersion = 1
Source = isis
End_Group

It's interesting when explicitly asking for smithed I pick up our new pck but nothing else. I am expecting to see our kernel names as well as SMITHED for the position and pointing quality keywords. Am I not running this correctly?

Also, should I not expect to pick up smithed kernels for an included image if I just spiceinit in default mode.

[jessemapel]

Smithed is currently set to OFF by default. There's an open issue #3482 to change this though. It hasn't gotten any comment and it is API breaking because it changes a default, so I'd like to see some discussion before it's moved ahead with.

[jessemapel]

I'm going to write a quick script to run through all of the images used in the kernels and see if they pick up the updated kernels.

[jessemapel]

Fix Enceladus Kernels

[jessemapel]

Looks like as part of the data area move, the kerneldbs got overwritten. I've re-updated them and am currently re-checking all of the images that should be covered.

[jessemapel]

Most images are now working, but there's a good number of images with exposure durations >4 seconds. I could pad every single range with about 10 seconds, but I would be very concerned about pulling the wrong images in some cases. I'm currently working on a script that will take each image and determine the proper time range to write to the kerneldb for it.

[jessemapel]

I've updated the kernel DB so that each image is listed in it with a 1 ms padding. I successfully re-ingested and spiceinit all 625 Cassini ISS NAC images from the kernel and they picked up the correct kernels.

This fix will go out with the full release when we push the updated data area. It should already be live at the ASC.