search

kevinkovalchik / RawQuant

RawQuant is a Python package for extracting scan meta data and quantification values from Thermo .raw files.
MIT License
10 stars 2 forks source link

Adding support for Boxcar #1

Open chrishuges opened 6 years ago

chrishuges commented 6 years ago

If you perform a Boxcar style method where you do selective isolation of multiple windows that are then combined into a single MS1 scan, can we extract the fill time data for each of the windows in the multiplex? This could be useful for optimizing method parameters with this setup.

Output data should go into the MS1ParseData.txt file.

kevinkovalchik commented 6 years ago

This data should be in the trailer extra or header information. Will see if we can find it.

kevinkovalchik commented 6 years ago

This data has been added to output matrix in the RawFileReader_dev branch. The columns for the fill times include the respective mass range in the column name, so it should be pretty easy to parse it out.

chrishuges commented 6 years ago

Tested. Is working very well.

*edit - I have only tested it processing files on Linux.

chrishuges commented 6 years ago

There seems to be a format change in the latest Tune version for the Fusion (just upgraded last week so we could use 'time-based' cycling in boxcar). RawQuant gives an error when trying to process these new files. You can find that data file for testing on the ptx_results, in the 05-May folder for the Fusion under my name.

ch_18May2018_HeLa-InSol_dda-it-box-iso_1.raw: Extracting MS1 retention times 100%|##########################| 1826/1826 [00:00<00:00, 88036.22it/s] ch_18May2018_HeLa-InSol_dda-it-box-iso_1.raw: Extracting MS1TrailerExtra 100%|###########################| 1826/1826 [00:00<00:00, 8578.52it/s] ch_18May2018_HeLa-InSol_dda-it-box-iso_1.raw: Converting data to DataFrame... ch_18May2018_HeLa-InSol_dda-it-box-iso_1.raw: Extracting boxcar mass ranges and fill times 0%| | 0/1826 [00:00<?, ?it/s]Traceback (most recent call last): File "/gsc/software/linux-x86_64-centos7/python-3.6.1/lib/python3.6/runpy.py", line 193, in _run_module_as_main "main", mod_spec) File "/gsc/software/linux-x86_64-centos7/python-3.6.1/lib/python3.6/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/chughes/Virtual_Python361/lib/python3.6/site-packages/RawQuant/main.py", line 718, in data.ToDataFrame(method='parse', parse_order=o) File "/home/chughes/Virtual_Python361/lib/python3.6/site-packages/RawQuant/RawQuant.py", line 1736, in ToDataFrame self.ExtractMassRangeFillTimes() File "/home/chughes/Virtual_Python361/lib/python3.6/site-packages/RawQuant/RawQuant.py", line 390, in ExtractMassRangeFillTimes disable=self.disable_bar)) File "/home/chughes/Virtual_Python361/lib/python3.6/site-packages/RawQuant/RawQuant.py", line 388, in self.data['MassRangeFillTimes'] = OD((str(x), get_out(x)) for x in tqdm(self.info.loc[self.info['MSOrder'] == 1, File "/home/chughes/Virtual_Python361/lib/python3.6/site-packages/RawQuant/RawQuant.py", line 384, in get_out return OD((keys[x], fill_times[x]) for x in range(len(keys))) File "/home/chughes/Virtual_Python361/lib/python3.6/site-packages/RawQuant/RawQuant.py", line 384, in return OD((keys[x], fill_times[x]) for x in range(len(keys))) IndexError: list index out of range

kevinkovalchik commented 6 years ago

It kind of looks like the Multi-Inject field in the TrailerExtra information has been truncated...

We should ask Thermo about this.

chrishuges commented 6 years ago

I put some new BoxCar files on the server: /projects/ptx_results/2018/Lumos-pc/05-May/Samples/CH/ with the names - ch_30May2018_HeLa-Std_FastLCwide_box2-otms_1.raw for example. These may fix some of the scan number issues we were seeing before...I think. Take a look when you have a chance.

kevinkovalchik commented 6 years ago

Have you found out anything about the truncated Multi-Inject field in the TrailerExtra? I forgot about this and was trying to work on the boxcar analysis this morning, but it is still an issue.

kevinkovalchik commented 6 years ago

The scan numbers look more reasonable for these files. At least they do for ch_30May2018_HeLa-Std_FastLCwide_box2-itms_1.raw. I haven't looked at the others. There are still some master scan numbers that occur out of order, but in this case it looks more like the instrument might be "mopping up" some good peaks it didn't have time for in the previous cycle. Not sure if this is something that happens in the design for the boxcar experiments... I'm not sure how it organizes the data dependent scans for the two different MS1 profiles. Anyway, nothing which appears alarming like we saw in #5.

chrishuges commented 6 years ago

Yes I think those files are different. They are acquired on the lumos using a specific scan setup for boxcar that I think the instrument is more happy with. I didn’t get around to looking more at the files after I acquired them. Basically it was an issue with overlapping mass ranges in the boxcar causing way more ms1 scans to be triggered. It was a fusion tune bug that is still not working.