Add filterPrecursorScan,MSnExp-method.

[sgibb]

This PR closes #282. Briefly it adds a method to filter linked spectra (MS1 and its corresponding MS2 and if available their corresponding MS3 and so on). The information is available in the featureData via the precursorScanNum column.

I use two for loops for the up/downward search in the hierarchy because recursion is slow in R and constructing the family tree would be more time consuming than the filtering.

I am wondering how to handle the argument scanIndex in filterPrecursorScan. In fact it is not the scanIndex but the acquisitionNum. Should I change the name or is there a way to translate between the two different indices?

[jorainer]

Nice PR @sgibb. One minor comment from my side.

[jorainer]

This method will never work for MSnExp objects, because they don't have the required columns in the feature data. Any plans to implement it for MSnExp objects? A simple helper function that iterates through the Spectrum objects to extract the acquisitionNum and precursorScanNum and returns a data.frame might do it.

[sgibb]

Currently I don't have any plans to add such a function (because most MSnExp won't have more than one msLevel) but I used MSnExp to provide this option.

[jorainer]

Right, forgot about that.

[lgatto]

This all looks good. I would like to do two things before merging

1. get my hands on an file with MS3 data for some more testing (msdata/proteomics/MS3TMT10_01022016_32917-33481.mzML.gz suffers from the Xcalibur bug documented in Link MS2 to MS1, MS3 to MS2 and MSn to MS(n-1) spectra #282 )
2. add a section in the vignette that shows how to use the code and visualise to respective peaks.

@sgibb - Re 1. above, do you know if it's possible to re-process a raw file to fix the missing precursor data? Otherwise, I will try to get a new file (and hope we have a recent Xcalibur version).

[sgibb]

@lgatto Sorry, but I never used Xcalibur myself. If you can't find the correct Xcalibur version @pavel-shliaha could convert the files for us.

Putting this code into the vignette would be great (but you are right, we need an example file).

What about the argument name scanIndex?

[lgatto]

@sgibb - I can get a file processed with Xcallibur 3.x tomorrow.

What about the argument name scanIndex?

Indeed, this is confusing (I had to double check myself when testing yesterday). I think it should be acquisitionNum, to make it match with the feature variable.

[jorainer]

OK from my side

[jorainer]

Re scanIndex: if I recall correctly, scanIndex is the index of the spectrum entry within the file, which does not have to be identical to the acquisitionNum which represents the order of the spectra as detected by the machine. pwiz determines the acquisitionNum and the precursorScanNum both from the ID of the spectrum in its respective entry in the mzML. This is obviously vendor specific, so in many instances the scanIndex and acquisitionNum are identical.

[lgatto]

As mentioned in a comment, it would be nice to

1. have an example file with MS3 data for some more testing - I should get one soon;
2. add a section in the vignette that shows how to use the code and visualise to respective peaks using the MS3 example.
   I'll approve and we might want to open a new issue for the points above.

[lgatto]

@sgibb - Thank you for this, great feature. I am close this but keeping issue #282 open until I add some test data (in msdata) and examples.

[lgatto]

I have now added an example that uses an MS3 TMT11.