Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

minWindowSize #2744

Open
jsalbin1 opened this issue Oct 11, 2023 · 9 comments
Open

minWindowSize #2744

jsalbin1 opened this issue Oct 11, 2023 · 9 comments

Comments

@jsalbin1
Copy link

I am attempting to convert DIA files from a Fusion Lumos to mzML with MSConvert 3.0.23208-1321c92. When I attempt to convert, I get the error:

"Error writing run 1: SpectrumToIndices() Number of demultiplexing windows changed. Minimum window size or window boundary tolerance may be set too low."

I have found several threads suggesting that the solution is to run on command line and add minWindowSize to the demultiplexing filter. I have tried this by editing the demultiplexing filter from:

--filter "demultiplex massError=10.0ppm removeNonOverlappingEdges=true"
to
--filter "demultiplex massError=10.0ppm removeNonOverlappingEdges=true minWindowSize=100"

When I do this, however, I get the same error regardless of what number I use as minWindowSize. Is there another solution for this error?

@chambm
Copy link
Member

chambm commented Oct 11, 2023

This often indicates the isolation scheme is not correct for what the demultiplexer works with. Can you share what your isolation windows are?

@jsalbin1
Copy link
Author

They're the overlapping windows from the default DIA template in XCalibur; I've attached an Excel sheet with the specific values.
Defaul_Windows_XCalibur.xlsx

@chambm
Copy link
Member

chambm commented Oct 11, 2023

I sorted by m/z and these windows are weird:

Start End
396.431 400.431
400.4328 404.4328
400.4337 408.4337
404.4346 408.4346
408.4365 412.4365
408.4373 416.4373
412.4383 416.4383
416.4401 420.4401

The 8mz windows are interleaved with the 4mz windows?

@jsalbin1
Copy link
Author

That's the way it's set up in the template method in XCalibur. There's a full scan, then the windows from Rows 1-75, then another full scan, then the windows in Rows 76-227.

I've tried several things to get around this over time. I'm not sure that the DIA windows are the part that is causing an issue with MSConvert. A method with the same windows will convert and give interpretable data if I replace the template method full MS scans with tSIM scans centered on 400-1000. Does that point to a known issue?

@chambm
Copy link
Member

chambm commented Oct 11, 2023

Full MS1 scans shouldn't interact with the demultiplexing at all. This is almost certainly about there being two sets of windows
that overlap with different widths. The demultiplexer can not work with a 400-408 window mixed with a 400-404 and 404-408 window. It should be 400-408, 408-416, 416-424, ..., for the first cycle, then 404-412, 412-420, 420-428, ... for the second cycle.

@chambm
Copy link
Member

chambm commented Oct 12, 2023

Note you may be able to demultiplex the file if you calculate the isolation window midpoints for either the 4mz windows or the 8mz windows, and then feed those to an mzPrecursor filter (available on the command-line only) with a tight mzTol value. For the subset of windows above, for just the 4mz windows, do something like:
--filter "mzPrecursor [398,402,406,410,414,418] mzTol=1da"
Then you can do --filter "demultiplex" after the mzPrecursor filter.

@chambm
Copy link
Member

chambm commented Oct 12, 2023

Oops, nevermind. The 4mz windows don't actually overlap with each other, and the 8mz windows don't overlap with each other. So that won't work.

@jsalbin1
Copy link
Author

I tried importing a new set of normal-looking windows into the default XCalibur method and will see whether those work.

@jsalbin1
Copy link
Author

You were right. It was the odd windows in the default method. Converting proceeds without incident once I replace them. On another question, though, I've noticed that converting overlapping DIA windows with Overlap Only is quick, but converting with MSX is very slow (many hours per file). It will start out fine but then slow to a few spectra per second around 20% of the way through. Is this normal?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants