Hi Wendy,

Can you share the RAW file? I'll need to see how the method differs from the supported methods to understand what's different.

Hi Wendy!

Lindsay Pino here, formerly of the MacCoss lab and now working in the Garcia lab. Hoping I can help you troubleshoot!

• The published Garcia lab histone methods aren't optimized for hi res instruments so I would caution against using those parameter settings on your Exploris -- your instrument can scan faster!

• The MSconvert error looks like what happens when the staggered window width is an "odd" value (e.g. 11mz wide windows). Skyline can import the data (Transition Settings > Full-Scan Settings > MS2 Settings) but you can't demux it with MSconvert, unfortunately. Was this data acquired with an odd-value window width?

• Related but specific to this particular error, I have to add an extra flag for Exploris data (MSconvert version 3.0.18267) in case anybody runs into that in the future: --ignoreUnknownInstrumentError T

Thank you for your help-
I reinjected sample using 10mz isolation ( Exploris 480 only 30000 resolution) and got this new error using MSConvert
Can you tell me why this error was generated, please.
C:\Skyline Documents\2020_10JulyDIA_histoneStd_01.raw

I attached the raw file

Starting...
Opening file "C:\Skyline Documents\2020_10JulyDIA_histoneStd_01.raw" for read...
Calculating SHA1 checksum...
Processing...
Writing "C:\Skyline Documents\2020_10JulyDIA_histoneStd_01.mzML"...
Failed - System.Exception: SpectrumToIndices() Number of demultiplexing windows changed. Minimum window size or window boundary tolerance may be set too low.
at pwiz.CLI.msdata.MSDataFile.write(MSData msd, String filename, WriteConfig config, IterationListenerRegistry iterationListenerRegistry)
at MSConvertGUI.MainLogic.processFile(String filename, Config config, ReaderList readers, Map2 usedOutputFilenames) at MSConvertGUI.MainLogic.Go(Config config, Map2 usedOutputFilenames)

That seems like progress. Sorry it's still having an error. Can you share the RAW file?

Yes, getting closer.... I uploaded the data file 30 mins ago.
I appreciate your help:)

What's the filename? I only see a broken mzML from today.

2020_10JulyDIA_histoneStd_01

Hi Wendy,

one of your windows is from 1.105 to 1.115 and the directly following window starts at too soon at 1.113. This irregularity is a second kind of overlap additionally to the staggered windows which is something MS Convert cannot handle at the moment.

Also, many windows have small gaps in-between where Im not sure if it would cause the same error, but in any case I would redo the acquisition on a blank until you find a gapless variant that can be processed succesfully. Skyline has a nice window scheme designer. I would be highly interested to see how the method designer on exploris looks like.

Best,
tobi

I will also point out this Skyline Tip for generating a staggered (overlap) window scheme. https://skyline.ms/wiki/home/software/Skyline/page.view?name=OverlappingWindowScheme

Also, this document describes how to do this in Skyline well too. https://bitbucket.org/searleb/encyclopedia/downloads/dia_methods_setup.pdf

-Mike

Thanks, Tobi. Yes, if you go to the Transition Settings > Full Scan tab chose DIA as your MS/MS Acquisition method and choose from the Isolation scheme dropdown list <Add...>, Skyline will show the Edit Isolation Scheme form.

In this form you can choose Prespecified isolation windows and then click the Import button. Choose one of your raw data files, and after Skyline has loaded the isolation scheme from it, click the Graph button. This will show you a graph like the one attached.

The gaps seem to be related to whatever created these windows insisting on using full unit deltas for the windows, though, we hope starting each window at an optimal window placement:

300.3887 310.3887
310.3932 320.3932
320.3978 330.3978

You can see that End - Start = 10 always, but Start is specified out to 4 decimal places with no sign of rounding. Skyline might come up with the same Start values, but it would not use exactly Start + 10 m/z for the End values. However, I wouldn't expect these small gaps of around 0.0045 to cause an issue. So, you can just uncheck the Show gaps checkbox in the form to see the less cluttered graph also attached, which shows the overlap issue at the end of the cycle.

I agree with Tobi that the problem is likely the final window in each cycle, which both start roughly 2.5 m/z before they should, causing an unexpected overlap.

cycle 1:
1110.7571 1120.7571
1118.2605 1128.2605

cycle 2:
1105.7548 1115.7548
1113.2582 1123.2582

Luckily, the command-line version of msconvert.exe contains a filter which can allow you to exclude just these two windows (1118.2605 to 1128.2605, and 1113.2582 and 1123.2582). Yes, we have had problems like this before where we wanted to salvage the data from a malformed isolation scheme.

In your case, it would be:

msconvert.exe 2020_10JulyDIA_histoneStd_01.raw --filter "mzPrecursors [1123.2605,1118.2582] mode=exclude" --filter "demultiplex"

Note: To get the values I used in mzPrecursors, I pasted the isolation scheme imported into Skyline to Excel and took the average (i.e. (Start+End)/2) of the Start and End values for the windows in question.

For me, this command-line still gave me an error about an unknown instrument type, but once I added --ignoreUnknownInstrumentError, then I was able to convert your file without an error.

Hope this helps. Thanks for posting to the Skyline support board, and thanks to Tobi for pointing out the issue in the isolation scheme.

--Brendan

Actually, it has been working on the demultiplexing for several hours now, without error. I don't yet have a completed mzML file.

I this how I add the lines?

Here are the various tooltips in a more long lasting form:

msconvert.exe 2020_10JulyDIA_histoneStd_01.raw --filter "mzPrecursors [1123.2605,1118.2582] mode=exclude" --filter "demultiplex"

msconvert.exe 2020_10JulyDIA_histoneStd_01.raw --filter "mzPrecursors [1123.2605,1118.2582] mode=exclude" --filter "demultiplex"