Open jsalbin1 opened 1 year ago
This often indicates the isolation scheme is not correct for what the demultiplexer works with. Can you share what your isolation windows are?
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
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?
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?
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.
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.
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.
I tried importing a new set of normal-looking windows into the default XCalibur method and will see whether those work.
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?
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?