Issue 632: Failure importing SRM runs

issues
Status:open
Assigned To:matt.chambers42@gmail.com
Type:Defect
Area:Skyline
Priority:3
Milestone:4.3
Opened:2019-02-11 by an.staes
Changed:2019-02-14 by Brendan MacLean
Resolved:
Resolution:
Closed:
2019-02-11 an.staes
Title»Failure importing SRM runs
Assigned ToGuest»Brendan MacLean
Type»Defect
Area»Skyline
Priority»3
Milestone»4.3
Dear Brendan,

I have a collision energy optimization set of runs on SRM and one of them gives me an error on omporting. I already reran the sample, but even with the new run, it keeps on geiving met the same error:

At 10:50:
Failed importing results file 'S:\MassSpec\Tabita\T15042b_Tubul_SRM_100fmol_iRT_CE_5.RAW'.
[ScanInfoImpl::initialize()] Object reference not set to an instance of an object.


Inner exceptions:
Exception type: System.Exception
Error message: [ScanInfoImpl::initialize()] Object reference not set to an instance of an object.
[ScanInfoImpl::initialize()] Object reference not set to an instance of an object.
   at pwiz.CLI.msdata.ChromatogramList.size()
   at pwiz.ProteowizardWrapper.MsDataFileImpl.get_HasChromatogramData() in C:\proj\pwiz_x64\pwiz_tools\Shared\ProteowizardWrapper\MsDataFileImpl.cs:line 755
   at pwiz.Skyline.Model.Results.ChromatogramDataProvider.HasChromatogramData(MsDataFileImpl dataFile) in C:\proj\pwiz_x64\pwiz_tools\Skyline\Model\Results\ChromDataProvider.cs:line 365
   at pwiz.Skyline.Model.Results.ChromCacheBuilder.BuildCache() in C:\proj\pwiz_x64\pwiz_tools\Skyline\Model\Results\ChromCacheBuilder.cs:line 194


I'm using Skyline Daily 64-bit 4.2.1.19004. I also tried on the not Daily version and it gives the same error.
I'm using TSQ Vantage.

Do you have any idea what is going on?
I can send you a link to the skyline file and the raw file in a private message.

Thanks!

Kind regards,
An

2019-02-11 Brendan MacLean
Assigned ToBrendan MacLean»matt.chambers42@gmail.com
Matt, can you get files and have a look?

2019-02-11 matt.chambers42
Please do send a link to one of the problematic RAW files.

2019-02-12 matt.chambers42
The conversion breaks when it asks the vendor API to parse this looooooooooooooooooooooooong filter:
+ c NSI SRM ms2 863.468 [413.187-413.189, 413.187-413.189, 413.197-413.199, 413.197-413.199, 413.207-413.209, 413.207-413.209, 413.217-413.219, 413.217-413.219, 413.227-413.229, 413.227-413.229, 413.237-413.239, 413.237-413.239, 413.247-413.249, 413.247-413.249, 413.257-413.259, 413.257-413.259, 413.267-413.269, 413.267-413.269, 413.277-413.279, 413.277-413.279, 413.287-413.289, 413.287-413.289, 938.467-938.469, 938.467-938.469, 938.477-938.479, 938.477-938.479, 938.487-938.489, 938.487-938.489, 938.497-938.499, 938.497-938.499, 938.507-938.509, 938.507-938.509, 938.517-938.519, 938.517-938.519, 938.527-938.529, 938.527-938.529, 938.537-938.539, 938.537-938.539, 938.547-938.549, 938.547-938.549, 938.557-938.559, 938.557-938.559, 938.567-938.569, 938.567-938.569, 1067.510-1067.512, 1067.510-1067.512, 1067.520-1067.522, 1067.520-1067.522, 1067.530-1067.532, 1067.530-1067.532, 1067.540-1067.542, 1067.540-1067.542, 1067.550-1067.552, 1067.550-1067.552, 1067.560-1067.562, 1067.560-1067.562, 1067.570-1067.572, 1067.570-1067.572, 1067.580-1067.582, 1067.580-1067.582, 1067.590-1067.592, 1067.590-1067.592, 1067.600-1067.602, 1067.600-1067.602, 1067.610-1067.612, 1067.610-1067.612, 1180.594-1180.596, 1180.594-1180.596, 1180.604-1180.606, 1180.604-1180.606, 1180.614-1180.616, 1180.614-1180.616, 1180.624-1180.626, 1180.624-1180.626, 1180.634-1180.636, 1180.634-1180.636, 1180.644-1180.646, 1180.644-1180.646, 1180.654-1180.656, 1180.654-1180.656, 1180.664-1180.666, 1180.664-1180.666, 1180.674-1180.676, 1180.674-1180.676, 1180.684-1180.686, 1180.684-1180.686, 1180.694-1180.696, 1180.694-1180.696, 1295.621-1295.623, 1295.621-1295.623, 1295.631-1295.633, 1295.631-1295.633, 1295.641-1295.643, 1295.641-1295.643, 1295.651-1295.653, 1295.651-1295.653, 1295.661-1295.663, 1295.661-1295.663, 1295.671-1295.673, 1295.671-1295.673, 1295.681-1295.683, 1295.681-1295.683, 1295.691-1295.693, 1295.691-1295.693, 1295.701-1295.703, 1295.701-1295.703, 1295.711-1295.713, 1295.711-1295.713, 1295.721-1295.723, 1295.721-1295.723, 1394.689-1394.691, 1394.689-1394.691, 1394.699-1394.701, 1394.699-1394.701, 1394.709-1394.711, 1394.709-1394.711, 1394.719-1394.721, 1394.719-1394.721, 1394.729-1394.731, 1394.729-1394.731, 1394.739-1394.741, 1394.739-1394.741, 1394.749-1394.751, 1394.749-1394.751, 1394.759-1394.761, 1394.759-1394.761, 1394.769-1394.771, 1394.769-1394.771, 1394.779-1394.781, 1394.779-1394.781, 1394.789-1394.791, 1394.789-1394.791]

What is up with that filter? I did some testing and it's not the duplicate Q3 ranges (each one is represented twice) causing the failure. It seems to be the overall length of the filter. Why is every Q3 range duplicated? Without the duplication, the filter parser works.

The conversion actually also works with the old 32-bit MSFileReader API, just not with the new 64-bit RawFileReader one. This is not something we could easily fix in ProteoWizard. Brendan, do you want me to add some deduplication when filters exceed a certain length, or wait for Thermo to say whether they'll fix this limitation?

2019-02-14 Brendan MacLean
Notify»Brendan MacLean
I guess it would be good to understand how An ended up with this file and if there is anything she can do to the instrument method to fix the issue on her end. Contacting Thermo would also be good to understand why they generate files like this and possibly even Jim to understand whether they can fix on their end to be support having their own filter strings supplied back to them, especially if MSFileReader works.

If An really cannot fix the method that generates this raw data file, then I suppose you could look at solving the issue with code on the ProteoWizard side.