Isotopes assigned to different pc groups

[shefalilathwal]

I was testing the single sample example given in CAMERA and in the final results, found several isotope annotations that were separated into different pcgroup after the corr_eic_th is applied. I am using the following code from the example on bioconductor:
file <- system.file('mzdata/MM14.mzdata', package="CAMERA") xs <- xcmsSet(file,method="centWave",ppm=30,peakwidth=c(5,10)) an <- xsAnnotate(xs) anF <- groupFWHM(an, perfwhm = 0.6) anI <- findIsotopes (anF, mzabs = 0.01) peak_iso <- getPeaklist(anI) anIC <- groupCorr(anI, cor_eic_th = 0.75) peak_iso_cor <- getPeaklist(anIC)

The second peak list after applying eic correlation threshold (peak_iso_cor) separates several isotopes into different pc groups. A snapshot of the table shows the 13th and 7th isotope pairs belonging to different pcgroups.

My understanding after reading the user documentation was that features annotated as isotopes will stay in the same pcgroup even if they don't meet the cor_eic_th criterion.

If the correlation value between two peaks is higher than the threshold cor_eic_th, it will stay in the group, otherwise both are separated. If the peaks are annotated isotope ions, they will not be divided.

Can you help me understand what might be going on here?
I am attaching the peaktable as well.
camera_example_isotope_corr.xlsx

[stanstrup]

The default groupCorr parameters are:

calcIso = FALSE, calcCiS = TRUE, calcCaS = FALSE

Thus, the isotope information is never used in that step unless you enable it.

That said it never made sense to me to look for isotopes before groupCorr.

[shefalilathwal]

@stanstrup I had tested with the isotope information set to TRUE as well and got the same result as reported above.
I do agree with you though that logically it doesn't make much sense to look for isotopes before groupCorr. Maybe this can be reflected in the user documentation.

[yguitton]

Hi @stanstrup, @sneumann

It's an old post, but I'm facing the same issue. Setting calcIso to true seems to have no effect (as if the step is not launched or is not efficient).
In my case the intensities of [13]C are quite low and may explain that groupCorr wants to exclude them from the original pcgroup due to low pearson correlations between EICs. But my understanding of the calcIso parameter was that it was created to avoid such splitting. Am I wrong?

Regards
Yann

[fgiacomoni]

Hi everybody
@sneumann, we are facing same issue in W4M with a new interactive tool.
Do you have few minutes to give your feedback on this issue/limit? Thank you very much
Do we start to imagine another strategy?