ckwriter & spkwriter can't make kernels for Chandrayaan-1 M3 jigsawed images
Both ckwriter and spkwriter produce warnings about time overlap conflicts for some 36 pairs of jigsaw updated M3 images I am passing to the programs. In all but one pair the image data do not actually overlap (the pair that do share duplicate data is: M3T20090420T051311 duplicates data in M3T20090420T051214). Some of these segments butt right up against each other in time when considering the Start/StopTime, but have more wiggle room when considering the SpacecraftClockStart/Stop times.
Here are my command lines for each program:
ckwriter froml=updated_lev1_Del_5.lis to=M3_prelim_ck.bc summary=M3_prelim_summary_ck.txt overlap=warning
spkwriter froml=updated_lev1_Del_5.lis to=M3_prelim_spk.bsp type=9 summary=M3_prelim_summary_spk.txt overlap=warning
The input/output files can be found under /work/projects/m3/lweller/PDSLOC_Products/Control/KernelTest/.
Also of note is the Start/StopTime padding is not the same at each end. When I compare the StarTime on the label of an image to what is recorded in the writer summary output file the difference is -0.003 (which Kris confirms is the correct value). However when StopTime is compared the difference is 0.206. Kris think there may be something other than padding coming into play and will add notes or a new post to explain.
I have also included links to other kernel related posts to this one as reference for project history and other unresolved kernel related problems.
There are some additional improvements/modifications to ckwriter and spkwriter that should be considered as well:
1) 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.
2) Both apps include the exhaustive listing of all kernels that were applied in spiceint in the kernel history section. Turns out, this is not such a good thing, particularly when a large number of files are provided in the list. They are already writing this information to an external text file. We should simply supply some basic text description, perhaps what is contained in the header info before individual segments (cube ephemeris) info is written.
3) Lots of input images to these programs can cause them to run for a very long time. We need to investigate ways to improve runtimes for many files. Note that every file loads and unloads kernels, which is likely the cause of the problem (history activity can also contribute).
4) We should test for a NAIF limit of 100K segments/kernel. If they exceed this maximum, either abort w/error message or break up the kernels into several output files.
Let me know if you have any questions.
#7 Updated by Lynn Weller 10 months ago
New location of jigsaw updated images: /work/projects/m3/lweller/JBLOC_Products/Updated/
There are 859 isis cube files in this directory and nothing more. The following file (sorry for the rotten name) points to the updated images: /work/projects/m3/lweller/JBLOC_Products/updated_lev1_prelim100Ground_addback_Del_5.lis
My commands would be the same as listed in the original post.
#12 Updated by Stuart Sides 3 months ago
- Status changed from In Progress to Resolved
It was thought the time padding ckwriter and spkwriter programs were adding to the start and end times for the M3 images was causing this problem. It turns out the M3 files actually have overlapping times. The decision was made to write a single ck and spk for each M3 image. The ISIS3 kernel database files should easily handle the 800+ kernels.