Voy2isis ingestion error leading to spiceinit failure

[blandoplanet]

ISIS version(s) affected: ISIS3.8.1. Error apparently did NOT occur with an older versions (maybe 3.4.13 see details below)

Description
On certain PDS images (*.imq see below), when running Voy2isis I receive the following warning:

Group = Warning Message = "The INSTRUMENT_NAME for [./c2061155.img] is empty.The InstrumentId in the output cube will instead be set to [Unknown] and the labels will not translate." End_Group USER ERROR Instrument ID [Unknown] does not match Narrow or Wide angle camera. The cube was created, but the labels were not translated.

The cubes were indeed created, but when I subsequently run spiceinit I get the following error:

ERROR An time string that was either not a time(N/A) or incorrectly formatted was passed into a naif routine. The short explanation provided by NAIF is [SPICE(UNPARSEDTIME)]. The Naif error is [The input string contains an unrecognizable substring beginning at the character marked by : "1979-07-08T08:26:23"].

We (really @lwellerastro, who discovered the problem) have a work around because she found "clean" .cub files in one of Tammy's old directories. These seem to have been generated with ISIS3.4.13 (according to cathist). However, external users won't be able to use these images, which will be included in the Europa project.

How to reproduce
The 3 images for which this problem occurs (there are likely more) can be found in /work/users/mbland/Europa-Voyager/failing. They are c2061155.imq, c2061159.imq, c2061203.imq. Using ISIS3.8.1 on Astrovm4 run

voy2isis from=c2061155.imq to=c2061155.cub spiceinit from=c2061155.cub

The old "clean" versions of the cubes can be found in /work/projects/EuropaBasemap/Europa_processed/VGR/

Possible Solution
@lwellerastro noticed a difference in the 'SpacecraftClockCount' between the old "clean" cubes and the cubes now coming out of voy2isis. The new cubes have a '.' in the count, which is probably causing a read error (unexpected character). This almost certainly traces back to the instrument warning on ingest. It's not clear why the Instrument name is empty.

Additional context
From @lwellerastro: There are a number of redmine posts (not all made it to github it looks like) that sort of have to do with this problem, #4421 in particular. There are some voy2isis Brian Burns posts (closed) that have problems with ingesting pds data that required translation table changes that might not be helping. Could be red herring as Ken says, so maybe not worth knowing about. Brian did point out that the rings node as reprocessed the data and have created and archive containing .img/.lbl files but wasn't able to ingest them using voy2isis (#4345 on redmine and #2252 on github), and our response was probably wouldn't happen since it would require a program change. Understandable. However, their labels are good for these problem children, but we can't use them.

[lwellerastro]

Some additional notes:

• I have attempted to run pds2isis on these image in an attempt to "see" the label information and got the following error message:

"Unknown label type in [/pds_san/PDS_Archive/Voyager/vg_0024/europa/c2061xxx/c2061155.- imq]. It is possible the label file does not describe an image product (IMAGE, CUBE, or SPECTRALCUBE)" File = ProcessImportPds.cpp

• I have run cathist on each of the "clean"/usable images and they were all successfully ingested and spiced on 2018-06-21 using isis3.4.13. That version no longer exists so I tried to use the closest available version in time isis3.5.2 to run pds2isis and voy2isis and got errors consistent with those already reported.

This leads me to believe a change in a translation table is causing the problem.

Here is the full path for the "clean", previously successfully ingested and spiced images:

/work/projects/EuropaBasemap/Europa_processed/VGR/c2061155_init.cub /work/projects/EuropaBasemap/Europa_processed/VGR/c2061159_init.cub /work/projects/EuropaBasemap/Europa_processed/VGR/c2061203_init.cub

Note that InstrumentId is valid in each of these.

I also ran caminfo with originallabel=true on these and they all have a valid value for INSTRUMENT_NAME. The caminfo output files are under /work/users/lweller/Isis3Tests/Voy2isis/ and named info.pvl. Maybe there is something useful in these for you - I haven't figured out another way to "view" the pds label since there is none (only the .imq).

[kberryUSGS]

This might be a side-note, as the problem I list below might be fixed by fixing the InstrumentId problem:

I can reproduce everything with a recent build of dev and the test data, except that the spiceinit error I get is a little bit different than the one listed above. Notably, it has a "Z" in it, which is an error I've seen before elsewhere (and we can fix):

**ERROR** An time string that was either not a time(N/A) or incorrectly formatted was passed into a naif routine. The short explanation provided by NAIF is [SPICE(UNPARSEDTIME)]. The Naif error is [The input string contains an unrecognizable substring beginning at the character marked by <Z>: "1979-07-08T08:26:23<Z>"].

[lwellerastro]

@kberryUSGS , this sounds familiar... I'm not finding it in my work area at the moment, but I've seen this error as well while trying to work with some problem voyager images. I tried to edit the StartTime to get rid of the Z but that cascaded into other problems so I left it alone. But it was on images different than the ones in this post because they got through ingestion. I think there are some general issues with some of the voyager PDS labels.

[kberryUSGS]

Looking into this more, it actually looks like a problem with the .imq data's header to me. Both the INSTRUMENT_NAME (needed) and the NOTE (not needed) don't match when I compare the original labels (via catoriglab) from the old, working cubes in /work/projects/EuropaBasemap/Europa_processed/VGR/ with the new, failing cubes. Notably, the INSTRUMENT_NAME isn't even set in the image headers for the failing .img files.

If I view the header of the .imq files, I see the following. It isn't formatted nicely, but INSTRUMENT_NAME is not set to anything and doesn't even have an = sign

5^@CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL^@%^@/*          
FILE FORMAT AND LENGTH */^@2^@RECORD_TYPE                      = VARIABLE_LENGTH&^@RECORD_BYTES                     = 836&^@FILE_RECORDS                     = 860%
^@LABEL_RECORDS                    = 54^@D^@/*          POINTERS TO STARTING RECORDS OF MAJOR OBJECTS IN FILE */%^@^IMAGE_HISTOGRAM                 = 55^@%^@^ENCODING_HISTOGRAM              = 57^@%^@^ENGINEERING_TABLE               = 60
^@%^@^IMAGE                           = 61^@!^@/*          IMAGE DESCRIPTION  */^@,^@SPACECRAFT_NAME                  = VOYAGER_24^@MISSION_PHASE_NAME               = JUPITER_ENCOUNTER)^@TARGET_NAME                      = EUROPA^@/^@IMAGE_ID                         = '0748J2-002'^@K^@IMAGE_NUMBER                     = 20611.55 /*FLIGHT DATA SUBSYSTEM (FDS)*/^@7^@IMAGE_TIME                       = 1979-07-08T08:26:23Z^@7^@EARTH_RECEIVED_TIME              = 1979-07-08T09:17:59Z^@^O^@INSTRUMENT_NAME^@(^@SCAN_MODE_ID                     = '1:1')^@SHUTTER_MODE_ID                  = NAONLY^@&^@GAIN_MODE_ID                     = LOW<^@EDIT_MODE_ID                     = '1:1' /*FULL RESOLUTION*/)^@FILTER_NAME                      = VIOLET^@$^@FILTER_NUMBER                    = 13^@EXPOSURE_DURATION                = 0.3600 <SECONDS>^@&^@NOTE                             = "?";^@/*          DESCRIPTION OF THE OBJECTS CONTAINED IN FILE */^@2^@OBJECT                           = IMAGE_HISTOGRAM&^@ ITEMS                           = 256.^@ ITEM_TYPE                       = VAX_INTEGER%^@ ITEM_BITS                       = 32^@
^@END_OBJECT5^@OBJECT                           = ENCODING_HISTOGRAM^@&^@ ITEMS                           = 511.^@ ITEM_TYPE                       = VAX_INTEGER%^@ ITEM_BITS                       = 32^@
^@END_OBJECT4^@OBJECT                           = ENGINEERING_TABLE&^@ BYTES                           = 242/^@ ^STRUCTURE                      = 'ENGTAB.LBL'^@
^@END_OBJECT(^@OBJECT                           = IMAGE;^@ ENCODING_TYPE                   = HUFFMAN_FIRST_DIFFERENCE^@&^@ LINES                           = 800&^@ LINE_SAMPLES                    = 800%^@ LINE_SUFFIX_BYTES               = 36^@3^@ SAMPLE_TYPE                     = UNSIGNED_INTEGER^@$^@ SAMPLE_BITS                     = 8.^@ SAMPLE_BIT_MASK                 = 2#11111111#1^@ ^LINE_SUFFIX_STRUCTURE          = 'LINESUFX.LBL'^@

For comparison, I know that this data is very old, but just as an example, if I download: https://pds-imaging.jpl.nasa.gov/data/voyager/vg_0007/europa/c2061xxx/c2061155.imq voy2isis runs without error and spiceinit runs successfully.

[lwellerastro]

huh, I couldn't eve get catoriglab to run on our local pds file - "Could not find OriginalLabel or OriginalXmlLabel in input file".

I just tried to ingest and spice the imq that Tammy and Glenn downloaded a couple of years ago (also under /work/projects/EuropaBasemap/Europa_processed/VGR/) and it works fine as well.

I think the problem may be with our local PDS voyager data since that is where I was pulling the data from. I'll check the other two files and let you know if other nodes have successful ingest and spice.

Could it be this easy?!

[kberryUSGS]

@lwellerastro :+1:

re: catoriglab, I just ran catoriglab fr=c2061155.cub and catoriglab fr=c2061155_init.cub using the cubes provided in this ticket and it "just worked" for me.

[lwellerastro]

@kberryUSGS , just so we're clear, those were originally processed by Tammy and Glenn a couple years ago and are the one ones @blandoplanet refers to as the "clean" images, or the ones that worked. I'm trying to figure out where they pulled their data from, but it's clear it was not from our local PDS SAN. I side-tracked myself going through Tammy's old directories (but I found some other good stuff I could use for the project)...

[lwellerastro]

Confirmed - the imq's downloaded by Tammy and Glenn ingest with no problems. There are no notes on where the data came from, so I'll check with Glenn. @kberryUSGS confirmed the JPL node has good data, so that is a start.

I will report the problem with our local PDS SAN to the proper folks.

In the meantime I will re-run my level 1 processing script against data that comes from a different node to ensure there are no problems. I'll try to get that done today so that we can close this post asap.

Thanks for digging into this Kristin!

[lwellerastro]

For comparison, I know that this data is very old, but just as an example, if I download: https://pds-imaging.jpl.nasa.gov/data/voyager/vg_0007/europa/c2061xxx/c2061155.imq voy2isis runs without error and spiceinit runs successfully.

Huh, how is this working for you @kberryUSGS ? Nothing but errors when I pull from jpl's node (starting at the imaging nodes voyager page: https://pds-imaging.jpl.nasa.gov/volumes/voyager.html)

I downloaded the following to /work/users/lweller/Isis3Tests/Voy2isis/jpl_dwnload/ on astrovm5 using conda isis3.9.0: wget https://pds-imaging.jpl.nasa.gov/data/vg1_vg2-j-iss-2-edr-v3.0/vg_0024/europa/c2061xxx/c2061155.imq wget https://pds-imaging.jpl.nasa.gov/data/vg1_vg2-j-iss-2-edr-v3.0/vg_0024/europa/c2061xxx/c2061159.imq wget https://pds-imaging.jpl.nasa.gov/data/vg1_vg2-j-iss-2-edr-v3.0/vg_0024/europa/c2061xxx/c2061203.imq

I guess the real question is - how did you find your way to a different archive? I am wondering if I really want this data despite the fact it can be ingested. Is it fundamentally different from the archives the imaging node is pointing folks to (don't expect you to answer this)? I want to chat with @blandoplanet about this and see what he thinks. I'll also have a look at the "preferred" archives to see if it can shed light on what edr-v3.0 is all about (at least what jpl is referring to its archive as).

My overarching thought on getting this problem posted is these 3 images are in a network (previous and new) that we will be creating smithed kernels for and at the moment, no one can pull the data from the pds imaging node, ingest into isis and use the updates.

I'll take a closer look at the archive you pulled from to try and get a better understanding of things.

[kberryUSGS]

@lwellerastro I found my way to the older archive by googling "c2061155.imq." I guess I just got lucky that the archive I ended up in contained a version of the .imq file that happened to work with ISIS.

If I wget the same (more up-to-date) .imq files that you pulled down, I still get the errors listed in this ticket as well. These headers (via lessing the .imqs) are missing a value for INSTRUMENT_NAME. If we want these files in the archive to successfully be ingested into ISIS as is, we could potentially add the ability to ingest without this information, but would need to find an alternative way to determine whether the InstrumentId in ISIS should be set to NARROW_ANGLE_CAMERA or WIDE_ANGLE_CAMERA.

[lwellerastro]

@kberryUSGS, we have these files on the pds as well, they are under volume vg_0007 as opposed to volume vg_0024, which is where I and others have pulled from (new volume, presumably better data). I was able to successfully ingest vg_0007 images via voy2isis. I also called spiceinit, which ran, but I get the following error message for all three images:

Error                     = "The ck rotation from frame -32100 can not be
                             found due to no pointing available at
                             requested time or a problem with the frame"

I brought the images into qview and they appear to have lat/lon info despite the message. Camstats also returns values, so I don't know what that error means. I will try and compare these to the "clean" files we have on disk. I won't be reprocessing everything as I thought I might - not worth it, no time, and using older data is not preferable, but might be the best option for these 3 files.

I am not opposed to the idea of ingesting without adding Instrument_Name, but I would understand why others might not like the idea. That sort of information is included in the imgindex (or cumindex) for most archives and is definitely there for these images as I have already checked. The program editlab would allow a user to add it in. It would not be the first time a user has had to tweak the label. In fact, I think we would normally use the keyword=Unknown in cases like this, or where the target is not know. Maybe this is the solution?

[kberryUSGS]

To respond to the second paragraph first, what you're proposing: add InstrumentId = Unknown, translate the rest of the label normally, and have the user run editlab to fix this sounds reasonable to me! Adding an additional (optional) parameter to voy2isis to set the InstrumentId when it can't be determined from the label is also a potential option. Though it would probably for most usecases involve running voy2isis twice -- first, to realize that it fails with a "no InstrumentId found" error, and second to re-run it with the InstrumentId explicitly set with the optional parameter. For the third potential option I can think of, I'm still trying to figure out if there is a consistent way to automatically determine whether to set InstrumentId to NARROW_ANGLE_CAMERA or WIDE_ANGLE_CAMERA in the absence of an INSTRUMENT_NAME value in the input imq.

[lwellerastro]

I have pulled the 3 images in question off of the earlier version in which they appear (vg_0007) and by all rights they are identical to the "clean" images that were previously processed - dn's are the same and spice is essentially the same (barring possible slight differences from new kernels). I can only assume that the previous work encountered the same problems and used the older versions to work around it, but there is no documentation.

It appears the data under vg_0024 has corrupt headers, so I will report to local pds folks and let them sort it out. We will document where we pulled these files for the Europa project and call it good enough.

I am still not opposed to ingesting and setting InstrumentId=Unknown, but I''m not sure that will get consensus support. If "no", then I think we should add something to my original post (right at the top) that points interested parties to the older data so they don't have to go through the entire post for that information.

And @kberryUSGS got her thoughts in before I could my in.... all good ideas.

[lwellerastro]

sheesh! Of course we are already making InstrumentId=Unknown (because, duh)! However, changing it to the appropriate value does not help (and now I am remembering I have done this already, but can't find where).

cp c2061203_vg0024_voy2isis.cub editlab_c2061203_vg0024_voy2isis.cub editlab from=editlab_c2061203_vg0024_voy2isis.cub options=modkey grpname=Instrument keyword=InstrumentId value=NARROW_ANGLE_CAMERA spiceinit from=editlab_c2061203_vg0024_voy2isis.cub

Message = "An time string that was either not a time(N/A) or incorrectly formatted was passed into a naif routine. The short explanation provided by NAIF is [SPICE(UNPARSEDTIME)]. The Naif error is [The input string contains an unrecognizable substring beginning at the character marked by : "1979-07-08T08:32:47"]"

The headers are clearly garbage. I haven't tested the other two images, but I suspect the have the same problem.

Let's document this and close the post - garbage in, garbage out.

[jlaura]

@kberryUSGS @lwellerastro Nice job working through this one!

@ladoramkershner @Kelvinrr Is this post a candidate example for the FAQ? The topic itself is specific to Voyager, but the general issue is, I believe, broadly describable as a label issue that is causing problems with a subset of the data. I don't want to hijack this thread with a discussion (maybe post on astrodiscuss?), but wanted to draw your attention to this conversation.

[kberryUSGS]

@lwellerastro :+1: I noticed this, too. Right now, ISIS does set InstrumentId=Unknown, but when it doesn't find an InstrumentId, it stops further translating the label and doesn't get to the point of stripping the "Z" off the time, which is why you get the later spiceinit error. @lwellerastro Any ideas on where to document this? Sometimes things like this seem to get documented on the ingestion application pages? Or is just documenting this on the top of this post like you suggested enough?

[lwellerastro]

when it doesn't find an InstrumentId, it stops further translating the label and doesn't get to the point of stripping the "Z" off the time,

@kberryUSGS, would it be a pain/disaster to make the program finish translating to at least get the rest of the label in a proper state? It is likely always preferable/recommended to work with the latest version of an image than an older version, so it would be nice to work the volume 24 images. But if doesn't seem reasonable to everyone or folks think other potential problems would arise then I'll work with the older data.

Any ideas on where to document this?

I was just suggesting some summary in my original post so if others run into this problem they will hopefully find this via a search. There are lots of reasons an image might fail ingestion due to bad label information, but I'm not sure we spell that out on our ingest documentation, but maybe that is also a good place to put it.

[kberryUSGS]

@lwellerastro I was hoping to be able to answering this before the meeting today, but I'm still waiting on ISIS to compile after having made some minor changes. I'm not sure whether or not we'll have enough information to keep translating the labels such that spiceinit will run and produce the correct results if we don't know whether it's WAC or NAC.

[kberryUSGS]

After the stand-up yesterday, it was decided that a new parameter would be added to voy2isis to specify the IMAGE_NAME if it is missing from the input label.

I updated voy2isis to allow this option. voy2isis in graphical mode now looks as follows:

Running voy2isis on one of the failing images without specifying the INSTRUMENT_NAME now has an updated error message as follows:

(ISIS3) bash-4.4$ voy2isis fr=c2061155.imq to=c2061155-fail.cub
Group = Warning
  Message = "The INSTRUMENT_NAME for [./c2061155.img] is empty.The
             InstrumentId in the output cube will instead be set to [Unknown]
             and the labels will not translate. To create a cube with
             translated labels, re-run this application with INSTRUMENT set to
             NAC or WAC."
End_Group
**USER ERROR** Instrument ID [Unknown] does not match Narrow or Wide angle camera. The cube was created, but the labels were not translated. To create a cube with translated labels, re-run this application with INSTRUMENT set to NAC or WAC.

And then re-running as prompted with INSTRUMENT=NAC succeeds:

(ISIS3) bash-4.4$ voy2isis fr=c2061155.imq to=c2061155-succeed.cub instrument=nac

And the cubes are identical to the 'clean cubes' specified in this ticket:

(ISIS3) bash-4.4$ cubediff from=c2061155-succeed.cub from2=../clean/c2061155_init.cub
Group = Results
  Compare = Identical
End_Group

[lwellerastro]

@kberryUSGS , follow up question - was that successfully ingested image run through spiceinit? Simply to confirm that the time, etc. was translated properly.

[kberryUSGS]

spiceinit results for c2061155-succeed.cub:

Group = Kernels
  NaifFrameCode             = -32101
  LeapSecond                = $base/kernels/lsk/naif0012.tls
  TargetAttitudeShape       = $base/kernels/pck/pck00009.tpc
  TargetPosition            = ($base/kernels/spk/de430.bsp,
                               $base/kernels/spk/jup310.bsp)
  InstrumentPointing        = ($voyager2/kernels/ck/vg2_jup_qmw_na_fc-32100_t-
                               2.bc, $voyager2/kernels/fk/vg2_v02.tf)
  Instrument                = $voyager2/kernels/ik/vg2_issna_v02.ti
  SpacecraftClock           = $voyager2/kernels/sclk/vg200011.tsc
  InstrumentPosition        = $voyager2/kernels/spk//vgr2_jup230.bsp
  InstrumentAddendum        = $voyager2/kernels/iak/voyagerAddendum004.ti
  ShapeModel                = Null
  InstrumentPositionQuality = Reconstructed
  InstrumentPointingQuality = Reconstructed
  CameraVersion             = 1
End_Group

This is different than the current kernels group on the clean cube, but if I re-spiceinit the clean cube, I get the same set of kernels.

@lwellerastro @blandoplanet Any feedback or requested changes about any of this? The added parameter name, error messages, or anything else? I didn't provide any information about where to find the INSTRUMENT_NAME in any of the documentation if it's missing from the label, just the option to specify it.

[lwellerastro]

@kberryUSGS - all thumbs up. I like the improved error message and the new parameter. Folks can get the necessary information from the pds archive index file (which is on every volume) no big deal. I suppose that is the only thing I might add to the documentation - "users are encouraged to find this information in the pds data volume index.tab file", or something along those lines.

The clean file was run a summer or two ago so it would have the old ephermerides file (and any associated files it requires), so that's all good. When I worked with the vg_0007 data and compared to the "clean" files, cubediff's were "identical", so dn's were the same, and like what you are reporting, kernels are different which results in slightly different geometry which is also expected.

This all looks good to me!

[AustinSanders]

@kberryUSGS It looks like input and truth data never got checked in for voy2isis instrumentname test

[acpaquette]

The fix is present in the code base and the test passes. I'm going to call this ticket good and close it again.

[blandoplanet]

Have we verified that spiceinit runs on the cubes in the original post?

[lwellerastro]

@blandoplanet I confirmed a few posts up (Nov. 6) and just confirmed again. The changes are successful - if instrument name is missing/unknown voy2isis throws a meaning error and the program will ingest properly if the user sets the parameter instrument to NAC or WAC.