Invalid cvParam accession "1003028"

[Alex Saltzman]

I have converted raw files to mzML using dockerized msconvert docker-link

I am getting this err when trying to search Orbitrap Exploris data

Is Orbitrap Exploris not supported by tide-search?

Note I am able to run a search against Fusion Lumos data

[Alex Saltzman]

Indeed the search proceeds after I replace with the Fusion Lumos number!

sed -i -e 's/accession="MS:1003028"/accession="MS:1002732"/' my-exploris-file.mzML

[William S Noble]

In principle, tide-search should support any mzML file. The screen shot you sent doesn't seem to be an error message but shows part of the input file. Can you send the tide-search.log.txt file and the associated mzML file so we can see what the error is and try to reproduce it?

Thanks.

Bill

--
You received this message because you are subscribed to the Google Groups "crux-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crux-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crux-users/c7e3e93d-21ac-4458-8484-c8746a197883n%40googlegroups.com.

[Alex Saltzman]

Yes, see attached for the log and parameters used.

[William S Noble]

The error message does seem to be happening inside proteowizard (which Crux uses for parsing):

INFO: Converting ./raw/44461_1/44461_1_EXP_TMT16pro_4mix_1ug_20cmCol_F1.mzML to spectrumrecords format
INFO: Elapsed time starting conversion: 121 s
FATAL: An exception occurred: Invalid cvParam accession "1003028"

Please try the --use-ms-toolkit option.  Meanwhile, we will continue to try to figure out a way to get the version of proteowizard updated in Crux.

Bill

[Alex Saltzman]

Thanks! Using mstoolkit as the parser does work. Unfortunately I am getting SIGSERV (Address boundary error) crash when I try searching the full file: 

(This error doesn't show up in the log)

I can get through a truncated version of the file just fine multithreaded, but it crashes when I up the threads.

I was able to successfully search the entire file using 1 thread, however.

 I haven't tried successfully lowering the thread count to find the maximum that 

Looking through github issues, it appears this is a known issue. 

I could share the whole file through a private link if it would be helpful. 

Alex

[William S Noble]

Yes, alas, threading bugs in general are very hard to track down. This one has eluded us for a while. I don't think another example is needed. You should just proceed with num-threads=1.

Bill