Skip to main content
Recent Posts
13
Other / Re: Open software for SRM experiments
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).
14
MZmine / Identify the peak list processed by MZmine using NIST MS Search
Last post by Pauline -
Hello everyone,

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?

Thank you very much for your help.

Pauline
16
Other / Re: Open software for SRM experiments
Last post by CoreyG -
Hi VSO,

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.

Cheers,
Corey
18
Other / Open software for SRM experiments
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
19
XCMS / Re: Implementing custom retention time alignment algorithms
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.

thanks again, jo
20
XCMS / Re: Implementing custom retention time alignment algorithms
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"]
Code: [Select]
.getChromPeakData <- function(object, peakArea, sample_idx,
                             mzCenterFun = "weighted.mean",
                             cn = c("mz", "rt", "into", "maxo", "sample"),
                             unadjusted=FALSE) {
...
rtim <- rtime(object)
if(unadjusted) rtim_adjusted <- rtime(object,adjusted=!unadjusted)
...
rtScans<-range(which(rtim >= rtr[1] & rtim <= rtr[2]))
...
if(unadjusted) rtrange<-rtim_unadjusted[rtScans] else rtrange<-rtim[rtScans]
...
res[i, "into"] <- sum(mtx[, 3], na.rm = TRUE) *
          ((rtrange[2] - rtrange[1]) /
             max(1, (sum(rtim >= rtr[1] & rtim <= rtr[2]) - 1)))

However, this highlighted something else in the code that felt odd to me (again, I'm making a lot of assumptions).
By using 'rtr[2] - rtr[1]' 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[2] - rtr[1]'. 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?
Code: [Select]
peakArea<-apply(peakArea,1,function(pk) {
    # Get start and end index of rtim between rt range
    rtScans<-range(which(rtim >= pk["rtmin"] & rtim <= pk["rtmax"]))
   
    # Convert median rt range to actual rt range
    pk[c("rtmin","rtmax")]<-rtim[rtScans]
   
    # If the user wants unadjusted rt range give it to them, otherwise just rt range
    if(unadjusted) rtrange<-rtim_unadjusted[rtScans] else rtrange<-rtim[rtScans]
   
    # Save rt range in peakArea, so it can be used instead of rtr[2]-rtr[1] for res[i,'into']
    pk[c("rtDiff")]<-diff(rtrange)
   
    return(pk)
})
peakArea<-t(peakArea)

I'm not sure how centWave integrates peaks and how the rtmin and rtmax are chosen. So maybe this doesn't make sense...

Cheers,
Corey