Missing isolation width offsets for SPS masses
radusuciu opened this issue · 8 comments
Hi, I recently encountered an error when trying to process some TMT SPS-MS3 datasets with OpenMS (see: OpenMS/OpenMS#6856), and I believe it is related to the fact that ThermoRawFileParser outputs a constant -0.5 value for both the upper and lower isolation width offsets. Changing the sign of the values is sufficient to allow processing to continue (though I'm not yet convinced this is a good idea..).
I saw that you've indicated in a comment that these values are not available in the raw file, but was wondering if that is still the case. msconvert seems to output values but I am not familiar enough with the raw->mzML conversion process to know if that ThermoRawFileParser can access the same underlying data.
Edit: seem like msconvert may also not deal with these cases very well: ProteoWizard/pwiz#2062
Thank you for your continued work on this project!
Hi @radusuciu,
thank you for using ThermoRawFileParser.
Looking at the snippet you have provided in the OpenMS issue I have to admit that I cannot come up with any answer to that. Only the first mass in the SPS mass list contains isolation window offset properties (similar to any other MSn precursor). Having a value of -0.5 means that for some reason the RAW file reported -1 as the width of the precursor isolation window. Sometimes -1 is used as no-value by Thermo, however, it has not seen it being used in isolation window context.
Do you observe negative isolation margins for all spectra or it is only a few?
Which version of ThermoRawFileParser are you using? (Version 1.3.2 is fairly old, there has been a couple of updates to the way isolation window width is parsed in the later versions: see #152 for details, i.e. it might be fixed already)
Could you share an exemplary RAW file?
Hi, thank you for the quick response!
I observe negative isolation margins for all MS3 scans in this particular file - only on the first SPS mass as you pointed out. I have not yet tried other files. I can't share the particular raw file I've been working with, but I should be able to dig something up that was acquired within the same run and will share after confirming that it has the same issue. Do you have a preferred upload location?
I've tried 1.2.3, 1.3.1, 1.3.2, 1.4.0 and 1.4.2 and see it with all versions >= 1.3.1
Thanks!
I do not have any preferred upload provider, so anything that can do the job.
Having an example would be very helpful since it does seem to be an issue only with some files - I have downloaded a couple of SPS files from PRIDE and they do not have any negative isolation margins after converting them to mzML and IsobaricAnalyzer processes them without any troubles.
May I email you a link to the file, and if so, is the email tagged in git commits in this repo fine? Unfortunately we did not have a HeLa or similar dataset acquired with the same settings, but I've gotten permission to share so long as it's not publicly available. Thanks!
I've also looked at a few SPS files from PRIDE and was not able to replicate the issue so it might be something specific to our methods.
Hi @radusuciu,
thank you for sharing the file. Unfortunately, I could not find the reason for the negative isolation window - it might be some glitch or something. Thus, I just have implemented a workaround - negative window width values will be treated as none-existing and thus won't be output to mzML. Additionally, the window information will be propagated from the first SPS precursor to all subsequent SPS precursors. You can get an updated (pre-release) version from https://syddanskuni-my.sharepoint.com/:u:/g/personal/vgor_bmb_sdu_dk/EZxcUErXrxtPivPLCD-bchQB7aC5GLNUoe06YmA55lsjeA?e=1SHq6y
Please, let me know if it works for you.
That solution sounds perfect! Thank you very much for taking a look at that raw file... I still don't have a clue why it is the way it is, but I'll definitely let you know if I stumble upon the answer. In the acquisition method settings the SPS isolation width is greyed out and preset to 2. This was using Xcalibur 4.5.
I will test and report back.
Alright, I have converted the same file I shared with you with the pre-release and tested with an internal pipeline, sage, and the quantms pipeline. I did not perform a detailed comparison to ensure that the data did not change at all but everything executed without errors and the numbers look good.
Thank you again for working on this!
Released in version 1.4.3