Exporting tag matches fails

[compomics]

Exporting tag matches fails

[hbarsnes]

It seems like DeNovoGUI v1.16.0 is using an older version of our utilities backend library. This makes it a but difficult to figure out which line the error message actually refers to. I've therefore just released DeNovoGUI v1.16.1 with a newer version of the utilities library. Would you mind repeating the test with this updated version and send me the new stack trace? This should make it simpler to locate the source of the null pointer.

[bittremieux]

Here you go:

Tue Jun 12 16:05:01 PDT 2018: DeNovoGUI version 1.16.1.

java.lang.NullPointerException
	at com.compomics.util.experiment.massspectrometry.SpectrumFactory.fixMgfTitle(SpectrumFactory.java:1127)
	at com.compomics.util.experiment.massspectrometry.SpectrumFactory.getPrecursor(SpectrumFactory.java:632)
	at com.compomics.util.experiment.massspectrometry.SpectrumFactory.getPrecursor(SpectrumFactory.java:298)
	at com.compomics.util.experiment.massspectrometry.SpectrumFactory.getPrecursor(SpectrumFactory.java:559)
	at com.compomics.util.experiment.massspectrometry.SpectrumFactory.getPrecursor(SpectrumFactory.java:313)
	at com.compomics.denovogui.io.TextExporter.exportTags(TextExporter.java:311)
	at com.compomics.denovogui.gui.ResultsFrame$49.run(ResultsFrame.java:2329)

So the NPE occurs at line 1127. Presumably there is a problem looking up the MGF file in the mgfIndexesMap? Either an incorrect MGF file name or the map doesn't contain the expected values?

[hbarsnes]

The mgfIndexMap is index by the mgf file name and not the path to the mgf file, hence there should not be any problems moving from Windows to Linux.

And the only two things that can be null for the given line (if (mgfIndexesMap.get(fileName).getIndex(spectrumTitle) == null)) is the mgfIndexesMap itself or the returned value from the get method. The mgfIndexesMap cannot be null as it is used to load the data in the results dialog (which is shown before the given export can be selected).

So are sure that you are providing the correct mgf file? As the only way I've been able to reproduce the stack trace above is if I choose a different mgf file when reloading the results and then try to export the tag matches.

[bittremieux]

I point DeNovoGUI to the same MGF files that were used for the identification (in a different location of course). This seems to work as expected because after loading the identification results the viewer in the bottom panel correctly shows the spectra and the corresponding peak assignments. It's only when I try to export the tag matches that there's an indication something went wrong.

Maybe I'll grab and run the source myself to debug a bit if I have some time this week.

[hbarsnes]

If the files are not too large you could send them to me and I can try to reproduce the error on my side as well?

[bittremieux]

Ok, after some effort with the debugger stepping through the code I think I've got it. The error seems to be caused by the different separator character between Windows and OS X (Unix).

The problem is caused by some Windows file names being included when the results are loaded, see the screenshot:

You can see that three MGF files are loaded but they are each present twice in the spectrumIdentificationMap, once with only the file name and once with their full path (including D:\ before the file name in this case).
Because this full path is invalid after switching to a different computer the tag export fails.

The full file names including path seem to come from importing the Novor results.
In the NovorIdFileReader the MGF file name is read from the Novor output file, after which the file name is extracted on line 177.
However, on OS X the File.getName() method checks for a forward slash as separator character (see also line 215), while the file name uses a backward slash as separator as it originates from Windows. Consequently, the directory isn't split from the file name, leading to the issues down the road when trying to export the tags.

It might be that some of the importers for subsequent search engines have the same problem as in that case they will use the full path that was already put in the map by the Novor importer. I didn't check that though.
In any case, some importers use the correct file name as those are in the map. Meanwhile at least the Novor importer doesn't extract the file name correctly, possibly some other ones as well.

[bittremieux]

I quickly checked and the other file importers don't seem to have the same problem. In fact, you guys already seem to have an OS-independent file name function compomics.util.Util.getFileName. So you should just use that on line 177 in NovorIdFileReader to fix the bug. Yay!

[hbarsnes]

Thanks! I've just released a new version of DeNovoGUI (and also PeptideShaker) that includes this fix. :)