Sciex 7500 RT Ranges Converted Incorrectly

[PMSeitzer]

Scheduled data collected on the Sciex 7500 is formatted using a one-sided RT range tolerance value.

msconvert is currently treating this one-sided RT range tolerance value as though it were a complete RT range, and defines the RT range based on centering the RT transition value on the one-sided RT range tolerance.

For example, a transition has an RT of 16.9 minutes, with an RT range tolerance of 60 seconds. The correct RT range for this transition should be 15.9 min - 17.9 min (60 seconds on either side).

msconvert is currently computing the RT range as 16.4 min - 17.4 min (30 seconds on either side, centered at correct transition value).

Here is a real example of the RT range being incorrectly parsed from an mzML file generated by msconvert:

 <chromatogram index="6" id="- SRM SIC Q1=330.4 Q3=167.1 sample=17 period=1 experiment=1 transition=4 start=16.4 end=17.4 ce=20 name=11,12-EET-d11 (330/167)" defaultArrayLength="100">

This snippet comes from the file X0198-eicosanoids-in-macrophages-X0198-12_APP_medium_1mL-1.mzML
which is available in this google drive:
https://drive.google.com/drive/folders/1R9C0dZqDGAlGYLvj-h9Jh_HWs2SQuSTQ

Which @chambm has access to.

Apparently, this is a known problem that the folks at Sciex warn their customers about, since it frequently causes a lot of confusion.

I used the proteowizard version released after #2272 (see PR #2273).

Thank you in advance - the latest proteowizard has been working very well for sciex 7500 data, with the exception of the RT range issue.

[PMSeitzer]

Here is a screenshot of the aforementioned 11,12-EET-d11 transition shown in the sciex software:

[PMSeitzer]

Here is what the transition data looks like in the sciex software:

Note the Retention time tolerance (+/- s) field, which actually refers to the one-sided tolerance (total RT range is 2 times this value).

[chambm]

Is this a problem that only affects the 7500 or are we calculating it wrong for all Sciex MRM files?

[PMSeitzer]

Good question, but unfortunately I don't know - my group only has the 7500 and haven't checked other Sciex instruments.

[PMSeitzer]

Hey @chambm, We reached out to Sciex to see if they could provide some files from other Sciex instruments from scheduled MRM runs. Hopefully, they'll add some to the google drive folder (https://drive.google.com/drive/folders/1R9C0dZqDGAlGYLvj-h9Jh_HWs2SQuSTQ). If you have time to look into the issue sometime soon, I'd greatly appreciate it.

[cmsand]

Hi @chambm, we've been talking to Sciex about this issue and we strongly believe the problem is that their new software, SCIEX OS, writes retention time windows into both the wiff and wiff2 files as +/- ranges, whereas the old software, Analyst, writes retention time windows as a complete range. So all instruments running SCIEX OS will likely have this same issue (read: newer models). Sciex is expanding this new software to more instrument models, so I expect this problem will only become more prevalent.

Sciex has agreed to fix this internally, but we still need a solution in the interim. Is it possible to create an option to double the RT window size from Sciex files? That would give us a fix now and allow us to process data. A flag that can be turned on and off would be best, so we can turn it off when Sciex comes through with their fix.

I have asked Sciex to provide an example data file collected from their older Analyst software and will comment back here when data is added. Until then our data created from SCIEX OS can be found here: https://drive.google.com/drive/folders/1R9C0dZqDGAlGYLvj-h9Jh_HWs2SQuSTQ.

This work is greatly appreciated!

[cmsand]

Based on a conversation with David Cox from Sciex I believe @brendanx67 has been working with them on this issue.

[PMSeitzer]

@brendanx67 and @chambm Any updates on this issue? If there's any way I can help speed up the process let me know, I'd be happy to help

[PMSeitzer]

Hey @chambm and @brendanx67 ,
Hope you are both doing well.
If there's any way either of you can work on this issue, I would greatly appreciate it. However, I understand if you're busy, and I'm happy to take a stab at the issue.
Would you mind directing me to relevant parts of the code? This would save me some time as I look through the proteowizard code base.
Any response you could provide, even if it's to tell me that you don't have bandwidth to work on this right now, would really help me out. Thank you!

[chambm]

We're still working on it. We'd like to have an automatic fix to adjust the RT window only for files that were acquired with the affected SCIEX OS versions.

[chambm]

@PMSeitzer @cmsand See if the build here fixes it for you (after it finishes building):
#2488

You only provided an unscheduled MRM file as far as I can tell, so I couldn't test on your file.

[chambm]

@david-cox-sciex I just noticed you did some stuff in their Google Drive share yesterday. Looks like we were working on the same thing independently. Did you ever get a different version for the bug fix? It's a potential problem if the bug was fixed in 3.0 or 2.9 or something but the automatic detection code thinks not.

@PMSeitzer Oh, I forgot to mention that I accidentally committed some test code back in November. Since then, RTWindows for WIFF files have been assumed to be half-width instead of full-width. So if you had msconvert newer than that it should have already been fixed for you (at the cost of breaking Analyst-collected files!)

[cmsand]

Thank you @chambm for the work, and apologies about the unscheduled data files! Yes, recently @david-cox-sciex has been helping with this issue. Some recent updates:

• We upgraded our SciexOS software to ver 3.1
• During the upgrade testing we learned that our RT windows are not actually getting cut in half, but rather that after conversion all positive mode transitions get cut to 1 min wide windows, and all negative mode transitions get cut to either a 1.333 min window (in ver 3.0) or a 1.666 minute window (in ver 3.1). Most of our RT windows were set to +/-60 seconds, so it appeared as if they were getting cut in half
• I added a .wiff file in the google drive that was collected with ver 3.1 on a scheduled MRM method. You can use this file for testing. It contains data files for 40 injections. The first 20 samples were acquired with 1 min windows for pos mode and 1.66 min windows for neg mode. The second 20 injections were acquired with our usual windows (typically 2 min wide). https://drive.google.com/drive/folders/1zMbXsJtAOcttKpDrb1pcF04tZS-neRhj
• We just downloaded the newest version of proteowizard (3.0.23038) and it did not fix the issue for us.

See example chromatogram below. This is data from sample 40 of the example 3.1 data. Transition 1-Methyl-Histidine 3 which should have an RT window of +/- 80 seconds, but only shows a window of +/- 30 seconds. It was converted with the following command: "C:\Program Files\ProteoWizard\ProteoWizard 3.0.23038.42ca1b6\msconvert.exe" "D:\SCIEX OS Data\Metabolomics core\Data\20230202_Post-Pump-Repair_Testing.wiff" --32 --mzML -o "D:\proteowizard_test_20230208" --ignoreUnknownInstrumentError

[cmsand]

It's worth noting that the first 20 samples in the 3.1 example .wiff data I shared were collected with 1 min RT windows for positive transitions and 1.66 min windows for negative transitions to determine if the mzML files would maintain those same window lengths. And, in fact, they do. All 40 of the mzML data files have the same RT windows (within rounding error) after conversion despite samples 21-40 being collected with wider RT windows.

[chambm]

Ah, several things here.

1. OS 3.1 is when David told me the bug was fixed, so if the WIFF was collected with 3.1 or later, it won't apply the time adjustment.
2. The fix is not in the latest public download because the pull request (PR) hasn't been merged yet. Sorry I didn't make that clear. You'll need to download the MSI file built just for that PR from: https://teamcity.labkey.org/viewLog.html?buildId=2273693&buildTypeId=bt83&tab=artifacts&guest=1
3. The fix is only going to either divide the window by 2 or not. I have no idea what could be causing 160 windows to show up as 60 second windows. Are you talking about the chromatogram id start= and end= attributes, or about the binary arrays for the chromatograms?
4. Can you send a scheduled MRM file from before 3.1?

[cmsand]

@chambm, thanks for the response

• I added a new folder to the google drive that has some example data collected with OS 3.0 https://drive.google.com/drive/folders/1eNixuOzPtT64AtM09gYKdbhkRhKoAGBg
• The trunctated RT windows are in both the binary arrays and the start= and end= attributes in the mzML. However, our visualization software (MAVEN) only utilizes the binary data.
• We're committed to using OS3.1 at this point unless there's a clear reason to revert (it was not easy to update and we're at least stuck with OS3.1 until ~mid-march due to an ongoing study)

[cmsand]

I forgot to mention. In the OS3.0 example data I shared, the sample named Sample + Supermix would be the best reference data file to use. It should be very similar to the OS3.1 example data I also shared.

[chambm]

I also see the same RTWindows widths in all the 3.1 samples I checked (several sample numbers < 20 and > 20). Are you sure this isn't an instrument method or acquisition issue?

[cmsand]

Here is an example from Sample 40 of the OS3.1 data from the google drive folder. The transition 1-Methyl-Histidine 3 is shown from the .wiff file in the Sciex Explorer software (above), and after conversion to mzML (below). I believe the acquisition is fine because I am able to see the full RT window from the .wiff data file. Once it's converted to mzML the RT window truncates.

@david-cox-sciex was able to reproduce this issue on his end with the same data. Dave, any initial thoughts on what's going on?

[chambm]

Can you check the MRM Detection window? Another user with this problem just said that's what they found to be overriding the RTWindow when retrieving the chromatogram data.

[chambm]

Try the msconvert build from this PR's installer you can download here: https://teamcity.labkey.org/viewLog.html?buildId=2276603&buildTypeId=bt83&tab=artifacts&guest=1

It should fix the partial MRM array issue if I'm not mistaken.

[cmsand]

@chambm It seems that build of proteowizard required .NET Framework 4.8 to run. The 7500 computer was installed with 3.5 and updating caused connection issues with SciexOS3.1, so we had to revert before testing conversion. We're getting in touch with Sciex to see if there's a way we can update our .NET framework. Is there a way to get an msconvert build compatible with an older version of .NET?

Re: your question about the MRM Detection Window. We can't find any option to control that parameter in OS3.1. Is that something set in the Sciex software or by Proteowizard?

[chambm]

Yes we recently upgraded the .NET requirement. But before that, for several years it required .NET 4.7.2 instead, so you can't merely have 3.5. In any case you can install ProteoWizard on another computer and convert files there. I think that's how most users run it since they have often access to raw data but not the instrument computers.

I don't know anything about the MRM detection window, but it was something another user mentioned having this issue with partial MRM arrays. Can you SEE the value, even if you can't change it?

[cmsand]

Pulling in @PMSeitzer for help to test the new Proteowizard build on another computer since we all run Macs, and Ive never done that install outside Windows.

@chambm, not, we can't even see the value. The only access to RT windows that we have (or that we know of) is in the MRM method table which are the values we've been referring to. Will ping Sciex to see if we're missing something.

[PMSeitzer]

Hi @chambm and @cmsand , I built the custom proteowizard on a different windows 10 VM. Proteowizard was able to install successfully, and convert the files properly with no error, but unfortunately, the transitions still have rt width of 1 min exactly:

Here is the command I used:

"C:\Program Files\ProteoWizard\ProteoWizard 3.0.23041.1518511\msconvert.exe" "20230202_Post-Pump-Repair_Testing.wiff" --32 --mzML -o "output_dir" --ignoreUnknownInstrumentError

Here is an example chromatogram index header from an output mzML file. Note the rt start= and end= values amount to an RT window of 1 min.

<chromatogram index="2" id="SRM SIC Q1=170.11 Q3=96 sample=3 period=1 experiment=1 transition=0 start=5.57 end=6.57 ce=25 name=1-Methyl-Histidine 3" defaultArrayLength="75">

[PMSeitzer]

@chambm It might also be worth mentioning that when I tried the same conversion command on a wiff2 file, I saw this error message:

[Reader_ABI::read] Error opening run 1 in "20230202_Post-Pump-Repair_Testing.wiff2":
[WiffFile2Impl::setSample()] Object reference not set to an instance of an object.
[Reader_ABI::read] Error opening run 2 in "20230202_Post-Pump-Repair_Testing.wiff2":
[WiffFile2Impl::setSample()] Object reference not set to an instance of an object.
[Reader_ABI::read] Error opening run 3 in "20230202_Post-Pump-Repair_Testing.wiff2":
[WiffFile2Impl::setSample()] Object reference not set to an instance of an object.
[Reader_ABI::read] Error opening run 4 in "20230202_Post-Pump-Repair_Testing.wiff2":
[WiffFile2Impl::setSample()] Object reference not set to an instance of an object.
[Reader_ABI::read] Error opening run 5 in "20230202_Post-Pump-Repair_Testing.wiff2":
...

[chambm]

I think that is correct according to this:

It's worth noting that the first 20 samples in the 3.1 example .wiff data I shared were collected with 1 min RT windows for positive transitions and 1.66 min windows for negative transitions to determine if the mzML files would maintain those same window lengths. And, in fact, they do. All 40 of the mzML data files have the same RT windows (within rounding error) after conversion despite samples 21-40 being collected with wider RT windows.

Can you check one of the negative polarity chromatograms and samples > 20?

[PMSeitzer]

Here is a negative polarity chromatogram:

Every color series is a different sample, and the range of data is abruptly truncated at 5.92 and 7.59 in every sample.

From 20230202_Post-Pump-Repair_Testing-Test Sample 38.mzML:

        <chromatogram index="156" id="- SRM SIC Q1=808.2 Q3=408.1 sample=38 period=1 experiment=2 transition=65 start=5.92667 end=7.59333 ce=45 name=Acetyl-CoA n" defaultArrayLength="114">

the RT window is always the same for each sample - 1 min for positive transitions, and 1.66 for negative. This is true for all samples, regardless of injection number.

I have added the output as a folder output_conversion_20230214_msconvert_3.0.23041.1518511 in the data directory:
https://drive.google.com/drive/folders/1R9C0dZqDGAlGYLvj-h9Jh_HWs2SQuSTQ

[chambm]

Clearly something in the API thinks that all those samples are 1 min for positive and 1.6 minutes for negative transitions. It doesn't seem to be a SciexOS <3.1 bug. I've pushed a new fix which seems to workaround that issue by just telling it to get the XIC from the entire time range instead of what the RTWindow says. It's currently in msconvert.exe only: --ignoreScheduledLimitsForChromatograms. It'll be available when that PR finishes building. Let me know if it works for you.

[chambm]

@david-cox-sciex Is Sciex tracking this as a bug? Because the data was clearly recorded for twice as long as the RTWindow suggests for the 20230202_Post-Pump-Repair_Testing.wiff file for the second half of the samples (21-40).

[PMSeitzer]

@chambm Tested the PR for msconvert 3.0.23048.489631b, Very happy to report that with this new build and CLI option --ignoreScheduledLimitsForChromatograms the resulting data looks correct.

Here are screenshots of the 1-Methyl-Histidine 3 and Acetyl CoA n transitions:

Note RT windows of 2.7 and 3.1 minutes (4.7-7.4) and (5.2-8.3), instead of previous truncated 1 and 1.6 minutes.