Last post by johannes.rainer -
I'm also not familiar with SRM/MRM data. But we have implemented a readSRMData function in MSnbase to read chromatographic data from mzML files. Would be nice to know if that works for you and what is missing. Note also that xcms can do now peak detection also on purely chromatographic data (i.e. Chromatogram/Chromatograms classes which are returned by the readSRMData function).
I used the MZmine2 software to analyze GC-MS data and NIST MS Search to identify the peak list. But I found that using the same parameter settings, I got different results. My parameters are set as follows: Spectrum RT tolerance: 3% Max. peaks per spectrum:10 Must have same identities: yes Min. match factor: 700 Min. reverse match factor: 700
But I am not sure that the settings for Spectrum RT tolerance and Max. peaks per spectrum are correct? What references can I refer to?
I've used skyline (https://skyline.ms/project/home/software/Skyline/begin.view) a fair bit in the past for metabolomics SRM data analysis. You can export peak areas, retention times (apex, start of integration, end of integration) and FWHM fairly easily (using document grid). I don't know if it generates a metric for noise (or S/N)...
The hardest part when getting started, is that you have to manually specify what transitions you want to look at (edit->Insert->Transition list). Skyline won't read the transition list from a file automatically.
Last post by vso -
Hello, I am looking for free/open source software that can process files from SRM experiments (converted to an open format) and provide parameters such as peak start/end at x% height, fwhm, noise etc. Does anyone have any suggestions? Many thanks
Last post by johannes.rainer -
Thanks for sharing your ideas. If you would like some changes in xcms I would however appreciate if you open an issue at the xcms github repository as this enables me also to keep track of what to do (and what was done) - a pull request would actually be even better
Regarding the code in xcms centWave - I did not write that code and I am veeerrry hesitant to change anything within it as this will affect all xcms users.
Last post by CoreyG -
Thanks for looking into and fixing the error - very much appreciated.
I was quite intrigued that you said fillChromPeaks always uses the adjusted retention time, so I looked a bit deeper into the code. It seems fairly simple to allow the ability to integrate using the original rt range.
If you included another parameter on getChromPeakData to select whether switch back to the unadjusted rtrange, stored the unadjusted rtime, figured out which index of rtim is the rtmin and rtmax, then use those indexes to get the original rt for use in the calculation of res[,"into"]
However, this highlighted something else in the code that felt odd to me (again, I'm making a lot of assumptions). By using 'rtr - rtr' in the calculation of "into", don't we always end up overestimating the area of the peak? rtr comes from the medians of other samples, but getChromPeakData integrates using scans found between these limits. So the rt range of where it integrates is notionally smaller than 'rtr - rtr'. In the example above, rtrange is indeed smaller (with unadjusted=FALSE).
Could we iterate over peakArea and calculate new rtmin and rtmax based on the actual rtime?