Stupid questions maybe: I have never really accessed the behind the scenes code, and for the life of me I cannot find the file you refer to. In my xcms/R folder there are only xcms documents (three of them), and my search isn't finding any files called mzClust.R on my C: drive. Sorry to be a pain.
I have spectra that are already centroided. I can extract individual spectra from the file using getSpec(), and I can choose those spectra by using the xcmsRaw()@TIC slot. I am trying to understand how to apply mzClust to to spectra. The default output for getScan is not an xcmsSet or Raw object structure, so I don't think I can use that directly as input for mzClust. If I could coerce a spectrum into an xcmsSet object structure, maybe this is possible.
So I think that I either need to 1. extract individal scans from a raw data file so that they are inserted into an xcmsSet object or 2. coerce the getSpec() output into something mzClust can take.
I am a bit stumped as to how to do this. Any tips? Thanks,
as a follow up to this thread, i would normally interpret mu as the mean, which in the case of a fitted peak would represent retention time. However, mu is roughtly 2.2 times higher than the retention time. Any explanation on why this is?
I am interested becuase the gaussian fit may at times be a more reproducible estimate of retention time than the raw data. Thoughts? Thanks,
group.nearest did work for this application. The catechin molecular ion was present in two of the 52 files, and ended up as a feature group in the peakTable. I am a little shocked at how many more feature groups there are: nearly 10 fold more, but that was a first run through, and I can't say that I have optimized parameters at all. It does take quite a bit longer than the density algorithm. Thanks for the tips. Corey
This is actually a little concerning. I do not routinely structure my files for XCMS to recognize groups. So if all my files (52) are in a single group, then I am only recovering features that are present in 1/2 of my files - 26 samples? Shouldn't the minfrac take precendence over that value?
I am perplexed. I haven't used the other grouping method but can try it. I have tried setting the minsamp or minfrac to zero and that doesn't work. If I take the two samples that contain the catechin molecular ion and group then the catechine molecular ion makes it intot he peak table. If I use the c() command to add this to my 'background' xcms set, then group - the catechin molecular ion, while still present in the xcms@peaks slot, is absent from the peak Table.
Is it possible that it is a function of the c() step? I don't use this routinely, but was hoping to do so in this instance so that I didn't have to perform peak detection on the background files each time - just once.
Anyone have any suggestions as to why a feature in two of my samples (out of 52) does not make into my peakTable? Any tips are appreciated. Thanks, Corey
The retention time was adjusted by two seconds. Increasing the bw for the post-retention time correction xset does not result in the 291 peak making it into the peakTable. Any other ideas? Could it be a bug somewhere? This behavior doesn't make sense to me at all.
I have tried both minfrac=0 and minsamp=0 in the second peak grouping step. I also tried trivial non zero values for the minfrac step, the feature representing the standard molecular ion is absent in either case.
I am a bit confused I think. Even if they aren't properly aligned - they should be in the resulting dataset right? I can play with the bw setting tommorrow, but assuming that works, can you explain to me why the bw matters? Shouldn't the peak end up as its own column in the peaklist if it is present in one sample?
Any one out there have a suggestion I am missing? Shouldn't I be able to recover all the signals from peak detection in the grouped dataset if I set the minFrac setting to zero? Thanks, Corey
