Dear Hannes, sorry for this problem you had, and thanks so much for tracking this down exactly and sending us the offending code and solution. After investigating this a bit more we’ve determined that the problem was introduced in a check-in to trunk on Oct 2. Yesterday we checked in some new code that fixes this problem and adds some additional functionality as well from other development. We did not use your patch exactly as is, but thank you for sending it.
Please try updating to the latest trunk and using that code, and let us know if you have further trouble with it. A note to everyone else: if you compiled TPP yourself from trunk during the month of October, please recompile with the latest trunk to fix this problem. Official TPP releases are not affected by this problem as far as we know. We plan to release TPP 5.1 next week and this will be fixed. Thanks, Eric *From:* [email protected] [mailto: [email protected]] *On Behalf Of *Hannes Roest *Sent:* Tuesday, October 24, 2017 7:38 AM *To:* spctools-discuss <[email protected]> *Subject:* Re: [spctools-discuss] spectrast produces empty output file Dear Eric I have now tracked down the problem to a bit of logic in TPP in mzParser/RAMPface.cpp 501 scanHeader->precursorMZ = ( p.isoMZ > 0 ? p.monoMZ : p.mz ); basically what this assumes is that whenever p.isoMZ is set, then the precursorMZ is best set to p.monoMZ. The problem is that this logic fails for the files that I have tested where p.isoMZ is set but p.monoMZ is set to zero. This happens for the attached mzML and mzXML files both. It seems for the mzML file there is some quirky logic in ./mzParser/saxmzmlhandler.cpp which sets m_precursorIon.isoMZ when the tag MS:1000827 is encountered but this leads further down to not settting m_precursorIon.monoMZ since neither of the conditions is fulfilled. In the end, both parsers fail to ensure that if p.isoMZ is larger than zero that p.monoMZ is set. This of course leads to setting the precursorMZ of the scanHeader to zero on which spectrast relies. I attach a patch that ensures that in either case the monoMZ is set if the isoMZ is set. Best Hannes On Saturday, October 21, 2017 at 2:24:29 AM UTC-4, Hannes Roest wrote: Dear Eric I see now the same thing: $ /home/hr/openmsall/source/THIRDPARTY/Linux/64bit//spectrast -V -sLtestLib.splib spectra.mzXML SpectraST started at Sat Oct 21 02:18:54 2017. VERBOSE MODE... Library File loaded: "testLib.splib". Sorting query spectra in all mzXML files by precursor m/z before searching...DONE! Now searching query: spectra.00001.00001.536870927 (PrecursorMZ = 8.98729e-315; PrecursorCharge = 536870927) Found 0 candidate(s)... Comparing... DONE! Top hit: NO_MATCH Now searching query: spectra.00002.00002.0 (PrecursorMZ = 8.98729e-315; PrecursorCharge = 2,3,4,5,6) Found 0 candidate(s)... Comparing... DONE! Top hit: NO_MATCH Now searching query: spectra.00003.00003.0 (PrecursorMZ = 8.98729e-315) Found 0 candidate(s)... Comparing... DONE! Top hit: NO_MATCH Finished searching "spectra.mzXML" (3 spectra searched.) Output written to "/home/hr/openmsall/builds/openms/spectra.pep.xml". Total Number of Searches Performed = 3; Run Time per Search = 0.6667 seconds. Total Run Time = 2 seconds. SpectraST finished at Sat Oct 21 02:18:56 2017 without error. so clearly there is a parsing error with the mzXML file. It seems that precursor charge and precursormz are not initialized properly here, but they are in the file. Do you see what is going on here? The mzXML file is based on this file: https://github.com/OpenMS/OpenMS/blob/develop/src/tests/topp/THIRDPARTY/spectra_comet.mzML which I converted to mzXML. The file appears to be an LTQ Velos file that was generated by XCalibur and converted with proteowizard. Thanks for looking into this Hannes On Fri, Oct 20, 2017 at 6:57 PM, Eric Deutsch > I ran SpectraST on your file with –V and it seems to show that it is not > reading the precursor mz from you file somehow. All the precursormzs in the > verbose output are 0. I peeked in the file and I do see precursor mzs in > there, but I don’t know if they are encoded correctly. > > > > Where did this mzXML file come from? > > > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Hannes Roest > Sent: Friday, October 20, 2017 3:15 PM > To: spctools-discuss <[email protected]> > Subject: Re: [spctools-discuss] spectrast produces empty output file > > > > Dear Eric > > > > Thanks for your analysis > > > > 1. I found that mzXML worked better with SpectraST and the mzML file did not > work at all: > > > > $ spectrast -sLtestLib.splib spectra.mzML > > SpectraST started at Fri Oct 20 18:06:18 2017. > > Library File loaded: "testLib.splib". > > Total Number of Searches Performed = 0; Run Time per Search = inf seconds. > > Total Run Time = 2 seconds. > > SpectraST finished at Fri Oct 20 18:06:20 2017 without error. > > > > $ spectrast -sLtestLib.splib spectra.mzXML > > SpectraST started at Fri Oct 20 18:07:06 2017. > > Library File loaded: "testLib.splib". > > Sorting query spectra in all mzXML files by precursor m/z before > searching...DONE! > > Searching...10%...20%...30%...DONE! > > Finished searching "spectra.mzXML" (3 spectra searched.) > > Output written to "/home/hr/openmsall/builds/openms/spectra.pep.xml". > > Total Number of Searches Performed = 3; Run Time per Search = 0.6667 > seconds. > > Total Run Time = 2 seconds. > > SpectraST finished at Fri Oct 20 18:07:08 2017 without error. > > > > 2. Yes there are only two as comet did only find matches for 2 spectra. > However, searching a library of 2 spectra against a file of 3 spectra > should still work? > > 3. These are "MaxQuant compatible CR". I have removed those but without any > change in result. Unfortunately. > > > > Hannes > > > On Friday, October 20, 2017 at 5:57:45 PM UTC-4, Eric Deutsch wrote: > > Hi Hannes, I had a quick peek at your file and while I didn’t do any testing > a few things come to mind. > > > > 1) It could be that because you’re using mzXML (you meant to use mzML, > didn’t you? ;-) SpectraST might not be not detecting that these are HCD > spectra when building the library? The peptides are labeled (CID) when I > they should be labeled (HCD) I assume? When creating the library, maybe > -cIHCD would help? Just guessing > > > > 2) Unless I mis-count, there are only 2 spectra in the sptxt? > > > > 3) The mzML has some unusual carriage returns in the third spectrum. It > could be causing some problem possibly.. > > > > I would investigate those first, but maybe it’s something else.. > > > > Eric > > > > > > > > > > From: [email protected] [mailto:[email protected] <[email protected]>] On > Behalf Of Hannes Roest > Sent: Friday, October 20, 2017 1:58 PM > To: spctools-discuss <[email protected]> > Subject: [spctools-discuss] spectrast produces empty output file > > > > Dear Henry > > I am trying to set up a minimal example for a spectral library search, but I > cannot get it to work. I have a spectral library and a corresponding mzXML > file: > > $ spectrast -sLtestLib.splib spectra.mzXML > SpectraST started at Fri Oct 20 16:43:54 2017. > Library File loaded: "testLib.splib". > Sorting query spectra in all mzXML files by precursor m/z before > searching...DONE! > Searching...10%...20%...30%...DONE! > Finished searching "spectra.mzXML" (3 spectra searched.) > Output written to "/home/hr/openmsall/builds/openms/spectra.pep.xml". > Total Number of Searches Performed = 3; Run Time per Search = 1 seconds. > Total Run Time = 3 seconds. > SpectraST finished at Fri Oct 20 16:43:57 2017 without error. > > however, the resulting file spectra.pep.xml appears to be empty. Is there > any reason for this or any parameter I can change to make this example work? > Note that I generated the spectral library from that same mzXML file > (searched with comet) and I expect that the spectra match perfectly, so I > find an empty result file an unexpected outcome. > > Thanks > > Hannes > > -- > You received this message because you are subscribed to the Google Groups > "spctools-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/spctools-discuss. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "spctools-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/spctools-discuss. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "spctools-discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/spctools-discuss/MMwABWl4Iqs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/spctools-discuss. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/spctools-discuss. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/spctools-discuss. For more options, visit https://groups.google.com/d/optout.
