VICAR reader not working with portion of FITS label

[agicquelb]

Jordan,

I updated from mi-label-1.2.1 to mi-label-1.2.2. No I got the following bug when trying to migrate some (but not all) PDS3 to PDS4 labels.

Unfortunately I can't attach one of thePDS3 label here.

java.lang.NullPointerException at gov.nasa.pds.imaging.generate.label.PDS3Label.setMappings(PDS3Label.java:437) at gov.nasa.pds.imaging.generate.GenerateLauncher.query(GenerateLauncher.java:225) at gov.nasa.pds.imaging.generate.GenerateLauncher.main(GenerateLauncher.java:293)

Engineering Details

After initial triage, it appears this issue is specifically related to the PDS3LabelReader (VICAR), and, more specifically, the EXTENSION_RALPH_HK_TABLE portion of the label.

As noted below, a workaround has been identified per the product tools library.

[acraugh]

@agicquelb - email me a label and I'll attach it...

[acraugh]

@jordanpadams, Here's some additional data:

testData.zip

The Zip contains the .vm file and the label that produced the failure. I don't know what version of java is on the laptop mentioned, but I do know that most of the machines in our linux network show this:

% java -version openjdk version "1.8.0_322" OpenJDK Runtime Environment (build 1.8.0_322-b06) OpenJDK 64-Bit Server VM (build 25.322-b06, mixed mode)

As is annoyingly common, there is no indication of any specific dependencies, requirements, or environmental assumptions for this tool. I don't see any specific actions in the change log that would indicate a conscious change in Java requirements.

We have one machine with a special installation of Java/JDK:

newsbndev> java -version openjdk version "11.0.14.1" 2022-02-08 LTS OpenJDK Runtime Environment 18.9 (build 11.0.14.1+1-LTS) OpenJDK 64-Bit Server VM 18.9 (build 11.0.14.1+1-LTS, mixed mode, sharing)

I've asked @agicquelb to repeat the test on that machine to compare results.

[acraugh]

@jordanpadams, @agicquelb reports that the test also fails on the newsbndev CPU running JDK 11, The command used was:

pds-generate -p lsb_0397097519_0x53c_sci.lbl -t Template_NH_LEISA_data.vm

If there's anything else you need to debug, let us know.

[agicquelb]

I have this java on my laptop:

java version "13.0.1" 2019-10-15 Java(TM) SE Runtime Environment (build 13.0.1+9) Java HotSpot(TM) 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)

[jordanpadams]

@acraugh @agicquelb sorry for the inconvenience. We will take a look and hopefully have a resolution sometime this weekend.

Per this issue, is this the only label that is causing problems? Or are all the labels in your data set causing this error?

[agicquelb]

@acraugh @jordanpadams All the label files in this single sub-directory.

[jordanpadams]

@agicquelb copy. so to clarify, this template has worked on other labels in the past?

sorry for the runaround in questioning :-)

[jordanpadams]

@agicquelb @acraugh after a quick test, looks like we have a workaround for the time being if you switch the label reader to the PDS3 Product Tools library. In hindsight, this should probably be the default reader for the tool, but we did not want to introduce backwards incompatibilities for existing pipelines.

Per the Advanced Usage Guide, here is how you can change the label reader:

# Open $MI_LABEL/bin/pds-generate with your favorite text editor

# Change the following line 

${JAVA_CMD} -jar ${GENERATE_JAR} "$@"

to

${JAVA_CMD} -Dpds.generate.parser.type=product-tools -jar ${GENERATE_JAR} "$@"

Again, I know this is a bit of a kludgy way to handle this, and I will create a couple tickets to improve this, but for now it appears to be a usable workaround. Here is what I got when I ran it with that reader. lsb_0397097519_0x53c_sci.xml.txt

this will give me some more time to debug the issue you are seeing, but, honestly, you are better off using the PDS3 Product Tools library moving forward anyways since it has been more rigorously tested against PDS3 labels.

[acraugh]

Thanks @jordanpadams - the work-around works and we're back in business1

[agicquelb]

Thank you @jordanpadams

[jordanpadams]

@agicquelb going to keep this open since it is still a bug, we just have a workaround