Problem with precursor selection in MSconvert

support
Problem with precursor selection in MSconvert Liyan Chen  2021-03-25 03:01
 

Hello Skyline developers,

I have a project where the DDA spectra libraries and quantitative DIA runs were acquired some time ago. Recently I thought of using PECAN workflow to improve library coverage and re-process the DIA files. I thought having an inclusion for iRT peptides into PECAN GPF runs would help to improve RT alignment in case of LC drift (true enough we saw a delay of 4-5 min). I did these on an Orbitrap Fusion:
Experiment 1: DDA, triggering MS2 if iRT peptides are detected (max 5 scans loop)
Experiment 2: MS1 on GPF range
Experiment 3: overlapping 4 m/z GPF isolation windows

I thought to then selectively demultiplex GPF windows in MScovert while preserving iRT MS2 scans, and I'm running into problems with this. Here are some of the parameters I tested on the 900-1000 GPF run.

--filter "mzPrecursors [487.3,644.8,683.8,547.3,669.8,683.9,699.3,726.8,622.9,636.9,776.9]mode=exclude" --filter "demultiplex optimization="overlap_only"

--filter "mzPrecursors [487.3,644.8,683.8,547.3,669.8,683.9,699.3,726.8,622.9,636.9,776.9]mode=exclude" --filter "demultiplex minWindowSize=2"

These gave the same error:
Error writing run 1 in "20210318_NAFLD_Depleted_3_30k_Pecan_900_1000.raw":
SpectrumToIndices() Number of demultiplexing windows changed. Minimum window size or window boundary tolerance may be set too low.

Then I thought to have the GPF windows as mzPrecursor inclusion instead:
--filter "peakPicking [vendor msLevel=1-2]" --filter "mzPrecursors[902.6602,906.6620,910.6638,914.6656,918.6675,922.6693,926.6711,930.6729,934.6747,938.6766,942.6784,946.6802,950.6820,954.6838,958.6857,962.6875,966.6893,970.6911,974.6929,978.6947,982.6966,986.6984,990.7002,994.7020,998.7038,1002.7057,900.6593,904.6611,908.6629,912.6647,916.6666,920.6684,924.6702,928.6720,932.6738,936.6756,940.6775,944.6793,948.6811,952.6829,956.6847,960.6866,964.6884,968.6902,972.6920,976.6938,980.6957,984.6975,988.6993,992.7011,996.7029,1000.7048]mode=include" --filter "demultiplex optimization=overlap_only" --filter "demultiplex minWindowSize=2"

resulting in the error:
[SpectrumListFactory] Unknown wrapper: mzPrecursors[902.6602,906.6620,910.6638,914.6656,918.6675,922.6693,926.6711,930.6729,934.6747,938.6766,942.6784,946.6802,950.6820,954.6838,958.6857,962.6875,966.6893,970.6911,974.6929,978.6947,982.6966,986.6984,990.7002,994.7020,998.7038,1002.7057,900.6593,904.6611,908.6629,912.6647,916.6666,920.6684,924.6702,928.6720,932.6738,936.6756,940.6775,944.6793,948.6811,952.6829,956.6847,960.6866,964.6884,968.6902,972.6920,976.6938,980.6957,984.6975,988.6993,992.7011,996.7029,1000.7048]mode=include

Removing demultiplex optimization and keeping only min window size appeared to work:
--filter "peakPicking [vendor msLevel=1-2]"--filter mzPrecursors[902.6602,906.6620,910.6638,914.6656,918.6675,922.6693,926.6711,930.6729,934.6747,938.6766,942.6784,946.6802,950.6820,954.6838,958.6857,962.6875,966.6893,970.6911,974.6929,978.6947,982.6966,986.6984,990.7002,994.7020,998.7038,1002.7057,900.6593,904.6611,908.6629,912.6647,916.6666,920.6684,924.6702,928.6720,932.6738,936.6756,940.6775,944.6793,948.6811,952.6829,956.6847,960.6866,964.6884,968.6902,972.6920,976.6938,980.6957,984.6975,988.6993,992.7011,996.7029,1000.7048]mode=include" --filter "demultiplex minWindowSize=2"

... though his produced an output mzML file that was twice the size of the original .raw file (1.02GB vs 478 MB). Importing the mzML into Walnut gets stuck at "reading standard format FASTA database" on the console with no progress in the bar showing "Converting files" on the right over the afternoon. I recall from a previous exercise on Walnut should display a xxxx/xxxxx spectra converted, and feel like the conversion didn't really proceed correctly. Is there a way to salvage my GPF files?

Is there any way to save my GPF runs?

 
 
Nick Shulman responded:  2021-03-25 05:23
It sounds like you might have gotten something which worked in that last step, but then you might have run into a Walnut bug that caused it to hang.

It sounds like you are doing three things with MSConvert:
1. centroiding scans using the --filter peakPicking" (this step has to be performed on the original .raw file)
2. Remove iRT MS2 scans
3. Demultiplex remaining overlapping MS2 scans

You might find it easier if you produce a .mzML file after each of those steps, and use that mzML file as the input to the next step, so that you can see whether msconvert produced the right thing. If you want to look at the contents of a mzML file, we recommend "SeeMS.exe" which is part of ProteoWizard.

My guess would be that when you were using the filter where you were using the filter with the "exclude" you were not actually getting rid of all of the iRT MS2 scans, and those extra scans would cause the demultiplex filter to get confused.

With your second-to-last attempt, did you really have two '--filter "demultiplex..."' items on the commandline? I would not expect that to work, because I think the second filter would cause it to try to demultiplex spectra that had already be demultiplexed. (I'm not sure why the error would be "Unknown wrapper").

It would probably be easier for us to answer your questions if we could see your files. You can upload them here:
https://skyline.ms/files.url

-- Nick
 
Liyan Chen responded:  2021-03-26 04:27

Hi Nick, thanks for responding.

Yes, I did have two of "--filters". I had thought that using both in a series would mean "demultiplex any overlapping windows with a minimum size of 2", instead of them being two sequential commands.

I looked at the output from the last attempt with --filter "mzPrecursor[.....]mode=include" and --filter "demultiplex minWinDowSize=2" in seeMS. It seems like msconvert ran without using filters as I still get these in the mzML:

  • iRTs
  • 4 Da GPF windows
  • additional precursors that are neither iRT or GPF windows (something is likely wrong with my trigger settings)

I have uploaded the file: Depleted_30k_Pecan_900_1000.zip
It was acquired on Xcalibur 4.4.16.14 with Tune 3.4.3072.18

 
Nick Shulman responded:  2021-03-26 08:12
I ran msconvert with your last set of filters, and it looks to me like it worked perfectly, demultiplexed the 4 Dalton isolation windows (turning each into two 2 Dalton windows), and removed all the other MS2 spectra.

This is the commandline I used:
msconvert.exe 20210318_NAFLD_Depleted_30k_Pecan_900_1000.raw --filter "peakPicking [vendor msLevel=1-2]" --filter "mzPrecursors [902.6602,906.6620,910.6638,914.6656,918.6675,922.6693,926.6711,930.6729,934.6747,938.6766,942.6784,946.6802,950.6820,954.6838,958.6857,962.6875,966.6893,970.6911,974.6929,978.6947,982.6966,986.6984,990.7002,994.7020,998.7038,1002.7057,900.6593,904.6611,908.6629,912.6647,916.6666,920.6684,924.6702,928.6720,932.6738,936.6756,940.6775,944.6793,948.6811,952.6829,956.6847,960.6866,964.6884,968.6902,972.6920,976.6938,980.6957,984.6975,988.6993,992.7011,996.7029,1000.7048]mode=include" --filter "demultiplex minWindowSize=2"

This is the .mzML file that I got:
https://proteome.gs.washington.edu/~nicksh/liyan/20210318_NAFLD_Depleted_30k_Pecan_900_1000.mzML

-- Nick