Code Monkey home page Code Monkey logo

camera's People

Contributors

antonwnk avatar dtenenba avatar hpages avatar jwokaty avatar kayla-morrell avatar korseby avatar lain-inrae avatar nturaga avatar samsonjm avatar shutinet avatar sneumann avatar stanstrup avatar treutler avatar vobencha avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

camera's Issues

Is there a way to respectively perform findIsotopes to each phenodata class?

My xset includes 3 groups of samples, and I want to perform findIsotopes function to each group rather than altogether. Is there a way to do that?

Another perspective of this question is that is it possible to create a subsets of an object according to phenodata class?

an <- xsAnnotate(xset )
an@xcmsSet@phenoData$class
[1] A A B B C C
Levels: A B C

Thanks a lot.

creating custom rule table for CAMERA

I am processing a set of metabolomics profiles using xcms+CAMERA. Particularly, and I am trying to create a custom rule table for adduct identification. Unfortunately, I have not found much material on the subject, except section 6 of the "LC-MS Peak Annotation and Identification with CAMERA" vignette.
Is there any additional resource where I can better learn how to create a rule table?
What baffles me is the usage of the "quasi" and "ips" fields, and the corresponding concepts of annotation group and rule score. In my understanding, setting all quasi and ips values to 1 should indicate that all candidate adducts must be considered independently and have the same weight. Is this correct?

Use MSnbase objects for storing CAMERA annotations

Related to adding annotation slot in XCMSnExp: sneumann/xcms#295
Related to finding where CAMERA uses XCMS1: #24 (comment)

Instead of CAMERA wrapping around the old xcmsSet object could it make sense to add CAMERA output to an XCMSnExp object instead?
I see two ways to do this:

  1. A dedicated extension of the XCMSnExp object for CAMERA
  2. A generic annotation slot that CAMERA could fill.

We also need to check how much of CAMERAs object really need to be kept around.
Also to consider is if there should be a ProcessHistory kept for the CAMERA processing.

Unit test failure: number of annotations changed

In test_groupFWHM.R we have a failure for

checkEqualsNumeric(length(unique(anFA@annoID[,1])),36)

which has now 38 instead of the 36 annotations. Running git bisect identifies ec32b75 as the commit causing the change.
Since that is actually a fix, I adapted the unit test to the new value.
Caveat: didn't manually check those annotations.
Yours, Steffen

CAMERA Peaklist table is empty

Hi,

I am trying to use CAMERA (version 1.45.1) to annotate peacklists generated by XCMS (3.11.3) in R (version 4.0.0). But, the generated peaklist is empty. Please see below for more details.
I am not sure which parts I am doing wrong. Thanks for your help. Fereshteh
########
xset <- as(xdata5, "xcmsSet")
xset <- group(xset)
xset<-fillPeaks(xset)
library(CAMERA)

an <- xsAnnotate(xset, sample=seq(1,length(sampnames(xset))), nSlaves=4)
Attaching package: ‘snow’
The following objects are masked from ‘package:BiocGenerics’:clusterApply, clusterApplyLB, clusterCall, clusterEvalQ, clusterExport, clusterMap, clusterSplit, parApply, parCapply, parLapply, parRapply, parSapply
The following objects are masked from ‘package:parallel’:
clusterApply, clusterApplyLB, clusterCall, clusterEvalQ, clusterExport, clusterMap, clusterSplit, makeCluster, parApply, parCapply, parLapply, parRapply,
parSapply, splitIndices, stopCluster

Starting snow cluster with 4 local sockets.
Run clean parallel after processing to remove the spawned slave processes!

an <- groupFWHM(an)
Start grouping after retention time.
Created 453 pseudospectra.

an <- findIsotopes(an)
Generating peak matrix!
Run isotope peak annotation
% finished: 10 20 30 40 50 60 70 80 90 100
Found isotopes: 2845

an <- groupCorr(an, graphMethod="lpc", calcIso = TRUE, calcCiS = TRUE, calcCaS = TRUE, cor_eic_th=0.5)
_
Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Generating EIC's ..

Calculating peak correlations in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100

Calculating peak correlations across samples.
% finished: 10 20 30 40 50 60 70 80 90 100

Calculating isotope assignments in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
Calculating graph cross linking in 453 Groups...
% finished: 10 20 30 40 50 60 70 80 90 100
New number of ps-groups: 667
xsAnnotate has now 667 groups, instead of 453 _

ann.add<-findAdducts(an, ppm = 5,mzabs = 0.015, multiplier = 2,polarity = "negative")
_Generating peak matrix for peak annotation!

Calculating possible adducts in 667 Groups...
Parallel mode: There are 77 tasks.
Calculating possible adducts in 667 Groups...
Parallel mode: There are 77 tasks.
Sending task # 1
Sending task # 2
Sending task # 3
Sending task # 4
Sending task # 5
Sending task # 6
Sending task # 7
Sending task # 8
Sending task # 9
Sending task # 10
Sending task # 11
Sending task # 12
Sending task # 13
Sending task # 14
Sending task # 15
Sending task # 16
Sending task # 17
Sending task # 18
Sending task # 19
Sending task # 20
Sending task # 21
Sending task # 22
Sending task # 23
Sending task # 24
Sending task # 25
Sending task # 26
Sending task # 27
Sending task # 28
Sending task # 29
Sending task # 30
Sending task # 31
Sending task # 32
Sending task # 33
Sending task # 34
Sending task # 35
Sending task # 36
Sending task # 37
Sending task # 38
Sending task # 39
Sending task # 40
Sending task # 41
Sending task # 42
Sending task # 43
Sending task # 44
Sending task # 45
Sending task # 46
Sending task # 47
Sending task # 48
Sending task # 49
Sending task # 50
Sending task # 51
Sending task # 52
Sending task # 53
Sending task # 54
Sending task # 55
Sending task # 56
Sending task # 57
Sending task # 58
Sending task # 59
Sending task # 60
Sending task # 61
Sending task # 62
Sending task # 63
Sending task # 64
Sending task # 65
Sending task # 66
Sending task # 67
Sending task # 68
Sending task # 69
Sending task # 70
Sending task # 71
Sending task # 72
Sending task # 73
Sending task # 74
Sending task # 75
Sending task # 76
Sending task # 77

Warning message:
Use of 'xcmsClusterApply' is deprecated! Use 'BPPARAM' arguments instead. _
peaklist<-getPeaklist(ann.add)
write.csv(sample,file="Neg-annotations_CAMERA.csv")
##########

CAMERA fails to load from source files

Hi,

I can't seem to load CAMERA from the .tar.gz file. The main problem seems to be "ERROR: loading failed for 'i386', which occurs even with arch - x64. Isn't i386 only for 32 bit?

  • installing source package 'CAMERA' ...
    ** libs

*** arch - i386
C:/Rtools/mingw_32/bin/gcc -I"C:/PROGRA1/R/R-351.1/include" -DNDEBUG -O3 -Wall -std=gnu99 -mtune=generic -c fastMatch.c -o fastMatch.o
C:/Rtools/mingw_32/bin/gcc -shared -s -static-libgcc -o CAMERA.dll tmp.def fastMatch.o -LC:/PROGRA1/R/R-351.1/bin/i386 -lR
installing to C:/Users/xxx/Documents/R/win-library/3.5/CAMERA/libs/i386

*** arch - x64
C:/Rtools/mingw_64/bin/gcc -I"C:/PROGRA1/R/R-351.1/include" -DNDEBUG -O2 -Wall -std=gnu99 -mtune=generic -c fastMatch.c -o fastMatch.o
C:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o CAMERA.dll tmp.def fastMatch.o -LC:/PROGRA1/R/R-351.1/bin/x64 -lR
installing to C:/Users/xxx/Documents/R/win-library/3.5/CAMERA/libs/x64
** R
** data
** inst
** byte-compile and prepare package for lazy loading
Warning: package 'xcms' was built under R version 3.5.2
Warning: package 'BiocParallel' was built under R version 3.5.2
Warning: package 'MSnbase' was built under R version 3.5.2
Warning: package 'mzR' was built under R version 3.5.2
** help
*** installing help indices
converting help for package 'CAMERA'
finding HTML links ... done
annotate-methods html
annotateDiffreport html
finding level-2 HTML links ... done

calcCaS-methods                         html  
calcCiS-methods                         html  
calcIsotopes-methods                    html  
calcPC-methods                          html  
calcPC.hcs-methods                      html  
calcPC.lpc-methods                      html  
cleanParallel                           html  
combinexsAnnos                          html  
compoundLibraries                       html  
compoundQuantiles-class                 html  
compoundQuantiles                       html  
findAdducts-methods                     html  
findIsotopes-methods                    html  
findIsotopesWithValidation-methods      html  
findKendrickMasses                      html  
findNeutralLoss                         html  
findNeutralLossSpecs                    html  
getAllPeakEICs-methods                  html  
getAtomCount-compoundQuantiles-method   html  
getIsotopeCluster                       html  
getIsotopeProportion-compoundQuantiles-method
                                        html  
getPeaklist-methods                     html  
getReducedPeaklist-methods              html  
getpspectra                             html  
groupCorr-methods                       html  
groupDen-methods                        html  
groupFWHM-methods                       html  
massWindowSizes                         html  
mm14                                    html  
plotEIC.xsAnnotate                      html  
plotPsSpectrum.xsAnnotate               html  
psDist-methods                          html  
pspec2metfrag                           html  
ruleSet-class                           html  
xsAnnotate-class                        html  
xsAnnotate                              html  

** building package indices
** installing vignettes
** testing if installed package can be loaded
*** arch - i386
Warning: package 'xcms' was built under R version 3.5.2
Warning: package 'BiocParallel' was built under R version 3.5.2
Warning: package 'MSnbase' was built under R version 3.5.2
Warning: package 'mzR' was built under R version 3.5.2
Error: package or namespace load failed for 'CAMERA' in library.dynam(lib, package, package.lib):
DLL 'RBGL' not found: maybe not installed for this architecture?
Error: loading failed
Execution halted
*** arch - x64
Warning: package 'xcms' was built under R version 3.5.2
Warning: package 'BiocParallel' was built under R version 3.5.2
Warning: package 'MSnbase' was built under R version 3.5.2
Warning: package 'mzR' was built under R version 3.5.2
ERROR: loading failed for 'i386'

  • removing 'C:/Users/xxx/Documents/R/win-library/3.5/CAMERA'
  • restoring previous 'C:/Users/xxx/Documents/R/win-library/3.5/CAMERA'
    In R CMD INSTALL
    Warning in install.packages :
    installation of package ‘C:/Users/xxx/Downloads/CAMERA_1.38.1.tar.gz’ had non-zero exit status

Sigma Parameter Behaves as Expected? (update documentation for groupFWHM?)

I am not sure the sigma parameter for groupFWHM() is behaving as expected. In the man page it states that sigma = the multiplier of the standard deviation However, in the code for groupFWHM sigma acts as a divisor, not a multiplier.

Source Code:
hwhm <- ((rt.max-rt.min) / sigma * 2.35 * perfwhm) / 2; #fwhm of the highest peak

Even if everything is working as intended, I would suggest changing the description to : The FWHM (full width at half maximum) of a peak is estimated as FWHM = (rt.max-rt.min)/sigma * 2.35 in order to make things more clear.

Another option could be adding: The SD (standard deviation) is estimated as SD = (rt.max-rt.min)/sigma instead of the suggestion above.

From XCMS3 - NA values in xcmsSet. Use fillPeaks()

Hi,

It seems that CAMERA doesn't really like the NAs left by fillChromPeaks:

Error in .local(object, ...) : NA values in xcmsSet. Use fillPeaks()
Calls: annotatediff -> diffreport -> diffreport -> .local

Although, the data were processed by FillChromPeaksParam

> processHistory(xdata)
[...]
[[8]]
Object of class "XProcessHistory"
 type: Missing peak filling
 date: Wed Jul 11 11:28:54 2018
 info:
 fileIndex: 1,2,3,4
 Parameter class: FillChromPeaksParam

Note that I'm using a toy example for my functional tests

> apply(featureValues(xdata, filled = FALSE), MARGIN = 2, FUN = function(z) sum(is.na(z)))
ko15.CDF ko16.CDF wt15.CDF wt16.CDF
    4252     4140     4251     4218
> apply(featureValues(xdata), MARGIN = 2, FUN = function(z) sum(is.na(z)))
ko15.CDF ko16.CDF wt15.CDF wt16.CDF
    2694     2702     2806     2680

My concern is that I should not be the first to chain xcms3 and camera.
With xcms 1.*, I had even more missing values which were fill with 0 and CAMERA didn't complain.

ping: @jotsetung ... maybe you have an idea.

'dimnames' must be a list in Examples

Travis is reporting:
https://travis-ci.org/sneumann/CAMERA/builds/162313326

* checking examples ... ERROR
Running examples in ‘CAMERA-Ex.R’ failed
The error most likely occurred in:
> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: findIsotopesWithValidation
> ### Title: Deconvolute/Annotate LC/ESI-MS data
> ### Aliases: findIsotopesWithValidation
> ###   findIsotopesWithValidation,xsAnnotate-method
> ### Keywords: methods
> 
> ### ** Examples
> 
>  library(CAMERA)
>  file <- system.file('mzdata/MM14.mzdata', package = "CAMERA")
>  xs   <- xcmsSet(file, method="centWave", ppm=30, peakwidth=c(5,10))
 Detecting mass traces at 30 ppm ... 
 % finished: 0 10 20 30 40 50 60 70 80 90 100 
 456 m/z ROI's.
 Detecting chromatographic peaks ... 
 % finished: 0 10 20 30 40 50 60 70 80 90 100 
 126  Peaks.
>  an   <- xsAnnotate(xs)
>  an   <- groupFWHM(an)
Start grouping after retention time.
Created 14 pseudospectra.
>  an   <- findIsotopesWithValidation(an)
Generating peak matrix!
Run isotope peak annotation
 % finished: 10  Error in array(dim = c(maxcharge, numberOfPeaksHere - 1, numberOfPeaksHere -  : 
  'dimnames' must be a list
Calls: findIsotopesWithValidation ... findIsotopesWithValidation -> findIsotopesForPS -> array
Execution halted
* checking for unstated dependencies in ‘tests’ ... OK

Error in if (rtr[2] < rtim_range[1] | rtr[1] > rtim_range[2] | mzr[2] < : missing value where TRUE/FALSE needed

Hi, I was trying to process ~400 samples with XCMS. It went well until fillChromPeaks step with error message:
Requesting 463 peaks from ### ... Error in if (rtr[2] < rtim_range[1] | rtr[1] > rtim_range[2] | mzr[2] < :
missing value where TRUE/FALSE needed
Calls: fillChromPeaks ... tryCatch -> tryCatchList -> tryCatchOne ->
Execution halted

This happens after I use sub-sample alignment.
Could you please help me with this issue? Thank you!

Best,
Yuanwen

Change all messages from cat to message

CAMERA gives a lot of status messages. This is normally good but when making tutorials it is often clear to avoid that.

If the messages are created with message() they can be disabled in rmarkdown with message=FALSE. In a script suppressMessages can be used,

Right now the messages are made with cat which cannot be ignored.

Some philosophy on that: https://stackoverflow.com/questions/36699272/why-is-message-a-better-choice-than-print-in-r-for-writing-a-package/36700294

R CMD check failure on recent BioC `Error in getPeaks_selection(xs)`

RUNIT TEST PROTOCOL -- Tue Jul  7 22:04:24 2015 
*********************************************** 
Number of test functions: 13 
Number of errors: 3 
Number of failures: 0 


1 Test Suite : 
CAMERA RUnit Tests - 13 test functions, 3 errors, 0 failures
ERROR in test.anno_multi: Error in getPeaks_selection(xs) : Peak information ?!?
ERROR in test.anno_multi: Error in getPeaks_selection(xs) : Peak information ?!?
ERROR in test.grp.lpc: Error in getPeaks_selection(xs) : Peak information ?!?

error with groupCorr

Hello all,

I don't know if this error is posted in previous issues however I encountered an error after updating the CAMERA package.

xsaC <- groupCorr(xsaF)
Start grouping after correlation.
Generating EIC's ..

Calculating peak correlations in 573 Groups...
% finished: Error in rcorr(EIC[, pi], type = "pearson") : object 'F_rcorr' not found

xsaF
An "xsAnnotate" object!
With 573 groups (pseudospectra)
With 12 samples and 9305 peaks
Polarity mode is set to:
Using automatic sample selection
Memory usage: 18.1 MB

It refers to something as "rcorr", has is something to do with the retcor? I ran that prior to groupCorr but gave no errors. I hope somebody can help me with this, I had it running before the up-date.

Thanks in advance,

Gr Marc Besseling
PhD student at the Netherlands Institute for Sea Research (NIOZ)

sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

Matrix products: default
BLAS: /usr/lib/libblas/libblas.so.3.0
LAPACK: /usr/lib/lapack/liblapack.so.3.0

locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=nl_NL.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=nl_NL.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=nl_NL.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=nl_NL.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] parallel stats graphics grDevices utils datasets methods
[8] base

other attached packages:
[1] LOBSTAHS_1.2.0 CAMERA_1.32.0 BiocInstaller_1.26.0
[4] xcms_1.52.0 MSnbase_2.2.0 ProtGenerics_1.8.0
[7] mzR_2.10.0 Rcpp_0.12.11 BiocParallel_1.10.1
[10] Biobase_2.36.2 BiocGenerics_0.22.0

loaded via a namespace (and not attached):
[1] splines_3.4.0 lattice_0.20-35 colorspace_1.3-2
[4] htmltools_0.3.6 stats4_3.4.0 base64enc_0.1-3
[7] vsn_3.44.0 XML_3.98-1.7 survival_2.41-3
[10] RBGL_1.52.0 rlang_0.1.1 foreign_0.8-68
[13] affy_1.54.0 RColorBrewer_1.1-2 affyio_1.46.0
[16] foreach_1.4.3 plyr_1.8.4 stringr_1.2.0
[19] mzID_1.14.0 zlibbioc_1.22.0 munsell_0.4.3
[22] pcaMethods_1.68.0 gtable_0.2.0 htmlwidgets_0.8
[25] codetools_0.2-15 knitr_1.16 latticeExtra_0.6-28
[28] IRanges_2.10.2 doParallel_1.0.10 MassSpecWavelet_1.42.0
[31] htmlTable_1.9 preprocessCore_1.38.1 acepack_1.4.1
[34] backports_1.1.0 checkmate_1.8.2 scales_0.4.1
[37] limma_3.32.2 S4Vectors_0.14.3 Hmisc_4.0-3
[40] graph_1.54.0 gridExtra_2.2.1 RANN_2.5.1
[43] impute_1.50.1 ggplot2_2.2.1 digest_0.6.12
[46] stringi_1.1.5 grid_3.4.0 tools_3.4.0
[49] magrittr_1.5 lazyeval_0.2.0 tibble_1.3.3
[52] Formula_1.2-1 cluster_2.0.6 MASS_7.3-47
[55] Matrix_1.2-10 data.table_1.10.4 iterators_1.0.8
[58] MALDIquant_1.16.2 rpart_4.1-11 igraph_1.0.1
[61] multtest_2.32.0 nnet_7.3-12 compiler_3.4.0

xraw parameter

Hi,

I'm actually trying to obtain beautiful EICs after running metaMS package. During this exercise, I can see that on the manual, we have a xraw parameter but when we look at the code, we can't find something like this... So I ask myself why there were this parameter before and why it disappear?

Because I thought that it could maybe help me :)

Thanks for the answer !

Julien

Error in fillpeaks after XCMSnExp conversion

Hello,
I would like to annotate my masses
I have xcms version 3.9.2 and camera version 1.43.2.
I do the different stages of processing xcms
and I converted my XCMSnExp to xcmsSet
when I apply the Fillpeaks function, here is the error message:
Error in rowSums(groupmat[, (match( npeaks, colnames(groupmat)) + 1):ncol(groupmat), :
'x' must be numeric
I take exactly the same steps as the MTBLS2 example

Thanks

Yohann

Error in plotPsSpectrum(): missing value where TRUE/FALSE needed

Hi,
this was reported by Mike at http://www.metabolomics-forum.com/viewtopic.php?f=24&t=911&p=2705#p2705.

library(xcms)
library(CAMERA)
library(faahKO)
xset1 = group(faahko, bw = 3, minfrac = 0.9, mzwid = 0.05)
xset2 = retcor(xset1, plottype = "none")
xset3 = group(xset2, bw = 3)
xset4 = fillPeaks(xset3)
xset4 = xsAnnotate(xset4)
xset5 = groupFWHM(xset4, perfwhm = 0.6)
xset6 = groupCorr(xset5, cor_eic_th=0.75, pval=0.05, calcCiS = TRUE, cor_exp_th=0.75)
xset7 = findIsotopes(xset6)
xset8 = findAdducts(xset7, polarity="positive")
plotPsSpectrum(xset8, pspec=1, maxlabel=5)

Confirmed with

other attached packages:
[1] faahKO_1.10.0       CAMERA_1.27.1       xcms_1.47.3        

ions in the same pseudospectrum not identified as isotopes

Hi,

I've beeing using CAMERA 1.45.2 to process LC-MS QTOF data. The following codes were used to exact isotope peaks.

xs.s <- xcmsSet(file, method = "centWave", ppm = 50, peakwidth=c(5,20),noise = 20000, snthresh = 10)     
xs.s <- xsAnnotate(xs.s)  
xs.s <- groupFWHM(xs.s, perfwhm = 0.6)   
xs.s <- findIsotopes(xs.s, ppm=50, mzabs = 0.01, filter = FALSE)  
peaklist <- getPeaklist(xs.s)  

I noticed in the peaklist, there are two ions in the same pcgroup (I assume same pcgroup indicates the same pseudospectrum), mz 514.312 maxo 1.5e6 and mz 514.814 maxo 1.1e5. As I understand, these two ions in the same pcgroup with a difference of 0.502 should be identified as isotopes of a [M]2+. However, that's not the case. When I ran xs.s <- groupFWHM(xs.s, perfwhm = 2) instead of xs.s <- groupFWHM(xs.s, perfwhm = 0.6) , less pcgroups were identified, the same two ions remained in the same pcgroup, but this time, they were identified as isotopes of a [M]2+, and this [M]2+ has no other isotopes.

Such results are very confusing to me. The C12/C13 ratio filter was off and the two ions remained in the same pcgroup, why does perfwhm affect the isotope identification?

Thank you very much.

Dependency on deprecated xcmsClusterApply

Hi,

we are getting an error xcmsClusterApply in findAdducts (the only place in CAMERA calling this function):

> an <- findAdducts(an,
+                   rules=rs@rules,
+                   polarity="positive")
Generating peak matrix for peak annotation!
Found and use user-defined ruleset!
Calculating possible adducts in 216 Groups... 
Parallel mode: There are 15 tasks.
Error in get(name, envir = asNamespace(pkg), inherits = FALSE) : 
  object 'xcmsClusterApply' not found
> traceback()
4: get(name, envir = asNamespace(pkg), inherits = FALSE)
3: xcms:::xcmsClusterApply
2: findAdducts(an, rules = rs@rules, polarity = "positive")
1: findAdducts(an, rules = rs@rules, polarity = "positive")

xcmsClusterApply was rightfully removed from xcms in
sneumann/xcms@944e73b#diff-79ec150cf995556015ba23f2a591ee68d5968adce487a08d2522e083a5c91112L303

But it is still called in

result <- xcms:::xcmsClusterApply(cl=object@runParallel$cluster,

The proper way is to go BPPARAM in CAMERA as well.
@jorainer, I need some hand-holding if I don't get this fixed this weekend myself.

Yours, Steffen

Expose the function to identify isotopes?

Dear developers (@sneumann @Treutler) I wanted to ask if it would be possible to expose/export some CAMERA-internal core functionality as documented functions?

The reason for that: I think it would be helpful to be able to call some of the core functionality from CAMERA also from other packages or independently of CAMERA (and more importantly, the xcmsSet object). This would open up CAMERA also for other types of input data, e.g. if you just have a list of m/z and intensity values, find possible isotopes. And that is actually exactly my use case at the moment: I have a set of m/z values and related intensity values and would like to know which or if these could be isotopes from each other. So, is there a function in CAMERA that takes mz and intensity values and can predict isotopes on that? And if so, which is it and how can I call that?

WARNING: subdirectory of ‘inst’ also used by R

Hi @HendrikTreutler , There is one WARNING:

Found the following non-empty subdirectories of ‘inst’ also used by R:
  inst/data
It is recommended not to interfere with package subdirectories used by R.

Stuff in package/inst/* is copied into the finished package,
so directories like package/inst/man would collide with package/man,
same is true for package/inst/data -> Please rename.

Yours, Steffen

Unexpected outputs: m/z differences and isotope number

Hello,

It seems that CAMERA sometimes produces unexpected outputs.

First, sometimes, the m/z difference are incorrect for the isotope number. I have mostly observed m/z larger than expected. Such as below (in this case 2.004 for M+2 and M+1 difference):

image

Second, sometimes, the isotope group contains multiple peaks for the same isotope. Strangely, they have different m/z values. Such as below (in this case, two M+2 peaks with 1.003 m/z difference)

image

Data was processed with XCMS online, for positive ionization mode. I attach a link to a collab notebook with the data and analysis.

https://colab.research.google.com/drive/1OciFt1M3lKrorlX7gnkwH4skJRwnHvFV?usp=sharing

Best regards.

The larger the isotope number, the larger the m/z error

Hello,

It seems that the algorithm by which CAMERA calculates m/z between isotopes systematically leads to erroneous isotopes of higher order.

As I understand, m/z differences are calculated between isotopes [M+k] and [ M+k-1]. For higher order isotopes, it seems that there is a m/z error that is accumulated, and the higher order isotopes are in fact no longer in an appropriate m/z range to the respective [M] isotope.

To illustrate the issue, I attach differences between adjacent isotopes. The ppm error is mostly less than 10 ppm:

image

However, if I calculate the difference between the higher order isotopes and the [M] isotope, there are more and more peaks with large m/z differences to the [M] isotope. By the isotope [M+5], most of the detected isotopes, have, in fact, a ppm to large to be true isotopes.

image

While I understand that m/z values have to be calculated between the [M+k] and [ M+k-1] isotopes to define possible isotope groups for computational reasons, I think a post-processing step should be added to filter from the pre-defined groups which peaks, in fact, have appropriate m/z difference with the respective [M] isotope.

I used XCMS online to process the data, which was acquired in positive mode. The expected mass tolerance we observe is 5-7 ppm.

I attach a colab notebook with the data and analysis. I have only considered isotopes with +1 charge.
https://colab.research.google.com/drive/1OciFt1M3lKrorlX7gnkwH4skJRwnHvFV?usp=sharing

Best regards.

findIsotope: subscript out of bound

Running findIsotopes() I get the following error:

an <- findIsotopes(an)
Generating peak matrix!
Run isotope peak annotation
% finished: Error in mint[ipeak, , drop = FALSE] : subscript out of bounds

Let me to know how may I help you.

Kind regards
Riccardo

Failure on windows with SNOW in parallel mode

** running examples for arch 'i386' ... [72s]Warning in file(con, "r") :
  cannot open file '../CAMERA-Ex_i386.Rout': Permission denied
Error in file(con, "r") : cannot open the connection
Execution halted

Thanks to Dan who debugged this:
"Windows is sensitive to starting socket clusters without stopping them, that results in this error. So if you could add a stopCluster(snowclust) to the appropriate place in xsAnnotate.R, that should take care of this."

Bug in labelling and/or legend of plotEICs

Reported by Andre Kleensang (Johns Hopkins University):

Die peakannotatioten sind anders in beiden Graphiken und damit ist
unklar, ob der höchste peak (6e06) 132.099 [M1+H]+ (laut maxlabel=5)
oder nicht zugeordnet ist (laut maxlabel=10).

As you can see the color labels are pointing to different peaks in the two versions of the same spectra.

maxlabel5 eps
maxlabel10 eps

calcIso in annotaeDiffreport not propagated down to groupCorr

Hi,
in a call today related to #38 @yguitton mentioned he had discovered that annotateDiffreport
seems to not propagate the calcIso=TRUE parameter down to the groupCorr()

Indeed I get identical results:

library(CAMERA)
library(faahKO)
xs.grp     <- group(faahko)
xs.fill    <- fillPeaks(xs.grp)

diffreportFALSE <- annotateDiffreport(xs.fill, calcIso = FALSE, calcCiS = TRUE, calcCaS = FALSE)
diffreportTRUE  <- annotateDiffreport(xs.fill, calcIso = TRUE,  calcCiS = TRUE, calcCaS = FALSE)

## Test if that parameter makes any difference:
diffreportTRUE[,"pcgroup"] == diffreportFALSE[,"pcgroup"]

where I'd expect this should be different. A PR could include that as unit test.
Yours,
Steffen

getReducedPeaklist values not reported

as reported by Christelle BONNEFOY ...

We need to fix a bug that...

when it is set to FALSE the value for the sample are not reported.
table_red<-getReducedPeaklist(xsaFCIA, intval = "maxo", method = "maxint",cleanup = FALSE,default.adduct.info = "maxint")

when it is set to TRUE, the value for the sample are reported.
table_red<-getReducedPeaklist(xsaFCIA, intval = "maxo", method = "maxint",cleanup = TRUE,default.adduct.info = "maxint")

failure: length > 1 in coercion to logical

After the BioC build farm has enabled _R_CHECK_LENGTH_1_LOGIC2_
(see https://stat.ethz.ch/pipermail/bioc-devel/2020-January/016081.html for details)
we get a build error http://bioconductor.org/checkResults/devel/bioc-LATEST/CAMERA/malbec2-checksrc.html , see below for a copy.

Chances are good that the issue is here:

if(!is.infinite(ini) && length(ini) > 0){

So what's left is to figure how to safely fix this code.

Yours, Steffen

* checking examples ... ERROR
Running examples in ‘CAMERA-Ex.R’ failed
The error most likely occurred in:

> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: annotate-methods
> ### Title: Automatic deconvolution/annotation of LC/ESI-MS data
> ### Aliases: annotate annotate,xcmsSet-method
> ### Keywords: methods
> 
> ### ** Examples
> 
>  library(CAMERA)
>  file <- system.file('mzdata/MM14.mzdata', package = "CAMERA")
>  xs   <- xcmsSet(file, method="centWave", ppm=30, peakwidth=c(5,10))
Detecting mass traces at 30 ppm ... OK
Detecting chromatographic peaks in 456 regions of interest ... OK: 126 found.
>  xsa  <- annotate(xs)
Start grouping after retention time.
Created 14 pseudospectra.
Generating peak matrix!
Run isotope peak annotation
 % finished: 20   ----------- FAILURE REPORT -------------- 
 --- failure: length > 1 in coercion to logical ---
 --- srcref --- 
: 
 --- package (from environment) --- 
CAMERA
 --- call from context --- 
FUN(newX[, i], ...)
 --- call from argument --- 
!is.infinite(ini) && length(ini) > 0
 --- R stacktrace ---
where 1: FUN(newX[, i], ...)
where 2: apply(hits.iso[!hit, , drop = FALSE], 1, function(x) {
    if (!all(is.na(x))) {
        ini <- which(x > iso)
        if (!is.infinite(ini) && length(ini) > 0) {
            x[min(ini):ncol(hits.iso)] <- NA
        }
    }
    x
})
where 3: t(apply(hits.iso[!hit, , drop = FALSE], 1, function(x) {
    if (!all(is.na(x))) {
        ini <- which(x > iso)
        if (!is.infinite(ini) && length(ini) > 0) {
            x[min(ini):ncol(hits.iso)] <- NA
        }
    }
    x
}))
where 4: findIsotopesPspec(isomatrix, mz, ipeak, int, params)
where 5: findIsotopes(xa, maxcharge = maxcharge, maxiso = maxiso, ppm = ppm, 
    mzabs = mzabs, intval = intval, minfrac = minfrac)
where 6: findIsotopes(xa, maxcharge = maxcharge, maxiso = maxiso, ppm = ppm, 
    mzabs = mzabs, intval = intval, minfrac = minfrac)
where 7: annotate(xs)
where 8: annotate(xs)

 --- value of length: 2 type: logical ---
   2    3 
TRUE TRUE 
 --- function from context --- 
function (x) 
{
    if (!all(is.na(x))) {
        ini <- which(x > iso)
        if (!is.infinite(ini) && length(ini) > 0) {
            x[min(ini):ncol(hits.iso)] <- NA
        }
    }
    x
}
<bytecode: 0x55a4ac4776c0>
<environment: 0x55a4ac473030>
 --- function search by body ---
 ----------- END OF FAILURE REPORT -------------- 
Fatal error: length > 1 in coercion to logical

findIsotopes: Combine isotope cluster bug

Hey,

I think I might have found a bug while working through the function 'findIsotopes'.
In this function exists this block of code.

#Combine isotope cluster, if they overlap
index2remove <- c();

if(length(idx.duplicated <- which(isomatrix[, 1] %in% isomatrix[, 2]))>0){
  for(i in 1:length(idx.duplicated)){
    index <-  which(isomatrix[, 2] == isomatrix[idx.duplicated[i], 1])
    index2 <- sapply(index, function(x, isomatrix) which(isomatrix[, 1] == isomatrix[x, 1] & isomatrix[,3] == 1),isomatrix)
    if(length(index2) == 0){
      index2remove <- c(index2remove,idx.duplicated[i])
    }
    max.index <- which.max(isomatrix[index,4]);
    isomatrix[idx.duplicated[i], 1] <- isomatrix[index[max.index], 1];
    isomatrix[idx.duplicated[i], 3] <- isomatrix[index[max.index], 3]+1;
  }
}

My problem with this is how the 'iso' value is set in the last line. For example I have processed the code up to this point and have an isomatrix, which lines 55:64 look like this:

   mpeak isopeak iso charge intrinsic
55   675     682   2      1         0
56   730     732   1      1         0
57   730     739   2      1         0
58   730     743   3      1         0
59   730     746   4      1         0
60   746     750   1      1         0
61   746     754   2      1         0
62   746     757   3      1         0
63   812     819   1      1         0
64   832     835   1      1         0

If I run the code above it yields this:

   mpeak isopeak iso charge intrinsic
55   675     682   2      1         0
56   730     732   1      1         0
57   730     739   2      1         0
58   730     743   3      1         0
59   730     746   4      1         0
60   730     750   5      1         0
61   730     754   5      1         0
62   730     757   5      1         0
63   812     819   1      1         0
64   832     835   1      1         0

The 'iso' for the lines 60:62 have all been set to 5, where it should be 5, 6 and 7. Am I correct?

In my example idx.duplicated is 60, 61, 62, 215, 284. For 60, 61 and 62 the index is always set to 59 and therefore max.index is also 59. This leads to the faulty 'iso' values.

Kind regards
Carl

Unexpected [M+2]+ isotope annotation

Hi,

I was wondering what the reason would be for the [M+2]+ isotope annotation to be so far outside of the tolerated mz ranges.

See below:

mzmed isotope_mz_diff isotopes adduct pcgroup
520.5083   [102][M]+ [M+H-COCH2]+ 561.512 1
521.5117 1.003390443 [102][M+1]+   1
524.5032 2.991508421 [102][M+2]+   1
525.5065 1.003271503 [102][M+3]+   1

I thought that the [M+2]+ would be between the tolerance in this matrix plus the ppm and absolute tolerances.

Sorry if I am missing something obvious. Any help would be appreciated

Version details

R version 3.3.1   (2016-06-21)
--
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601)   Service Pack 1

CAMERA_1.30.0      

CAMERA workflow

xsa <- xsAnnotate(xset)
xsa <- groupFWHM(xsa)
xsa <- groupCorr(xsa)
xsa <- findIsotopes(xsa)
xsa <- findAdducts(xsa, polarity = 'positive')

slot neutraladdition can not be empty to use generateRules

This was reported by Andre Kleensang at http://www.metabolomics-forum.com/viewtopic.php?f=24&t=594 :
I try the following:

rsP <- new("ruleSet")
rsP@ionlistfile <- "ions_pos.csv"
rsP@neutraladditionfile <- "neutraladdition.csv"
rsP@neutrallossfile <- "neutralloss.csv"
rsP <- readLists(rsP)
rsP <- setDefaultParams(rsP)
rsP <- generateRules(rsP)

Fehler in if (neutraladdition[i, 1] == "NaCOOH") { :
Fehlender Wert, wo TRUE/FALSE nötig ist

which is because neutraladdition.csv just has the header and no entries which creates an empty slot of neutraladdition. I do not want to allow a neutral addition in my rule set. Is there a possibility to fix that? I guess the problem is in the section "## Erzeuge Neutral" of ruleSet.R

... which is at

## Erzeuge Neutral Addition

Thanks Andre!

groupCorr cor_exp_th = 0.90 separate two > 0.9995

Hello and thanks in advance for you help

I am using CAMERA

xsgf<-as(fdata,"xcmsSet")
xsaf<-xsAnnotate(xsgf,sample = c(3:5), polarity = "positive")
xsaFf<-groupFWHM(xsaf, sigma = 6 , perfwhm = 0.6, intval = "maxo")
xsaFCIf<-findIsotopes(xsaFf, maxcharge=3, maxiso=4, ppm=5, mzabs=0.015, intval="maxo", minfrac=1, isotopeMatrix = NULL,filter = TRUE)
xsFCf <- groupCorr(xsaFCIf, cor_exp_th = 0.90,calcCiS = FALSE, calcCaS = TRUE)
xsaFCIAf<-findAdducts(xsFCf,polarity = "positive")

At the end, I get groups in different ps-groups

Example

line 2227 and line 2239
after FWHM pc-group = 21 for both
after isotopes, corr and adducts pc-group = 756 and 757 respectively
the correlation coefficient calculated by
calcCaS(xsaFCIf,corval=0.90, pval=0.05, intval="maxo")
is 0.9999

Could someone explain me why?
What is the role of the pval? How could I access it?

Christelle

negative mode: generateRules(rs) #Error in if (coeff[i, ii] > 0) { : missing value where TRUE/FALSE needed

library(CAMERA)

## Setup ruleSet
rs <- new("ruleSet")

rs@ionlistfile <- system.file('lists/ions.csv', package = "CAMERA");
rs@neutraladditionfile <- system.file('lists/neutraladdition.csv', package = "CAMERA");
rs@neutrallossfile <- system.file('lists/neutralloss.csv', package = "CAMERA");

rs <- readLists(rs)
rs@ionlist<-rs@ionlist[c(1,3),]
rs <- setDefaultParams(rs)

##default polarity is positive
#rs@polarity<-"positive"
rs <- generateRules(rs)

#works perfectly fine in positive mode

#returns the following error in negative mode
rs@polarity<-"negative"
rs <- generateRules(rs)
#Error in if (coeff[i, ii] > 0) { : missing value where TRUE/FALSE needed

Possible bug in `findIsotopesWithValidation`

Running findIsotopesWithValidation on a xsAnnotate object it throws the error:
Fehler in if (!isotopeProportionFits) { : Fehlender Wert, wo TRUE/FALSE nötig ist
(sorry German locale :-))
I believe the reason is that object@xcmsSet@peaks contains NAs in the sn column. This leads to snValues of NA which subsequently in function findIsotopesForPS causes isotopeProportionFits to be assigned a NA instead of a TRUE/FALSE.
A solution could be to set na.rm=TRUE for the median which calculates snValues for the different groups. Just like it is done for the calculation of intValues.

Cheers

Neutral masses do not match

First of all thank you for your package! I have a question regarding how neutral masses are calculated:

run the example from the manual:

 library(CAMERA)
 file <- system.file('mzdata/MM14.mzdata', package = "CAMERA")
 xs   <- xcmsSet(file, method="centWave", ppm=30, peakwidth=c(5,10))
 xsa  <- annotate(xs)

pick a mass with an identified adduct, e.g. at index 118, where a neutral mass was found

> xsa@derivativeIons[[118]]
[[1]]
[[1]]$rule_id
ruleID 
     1 

[[1]]$charge
[1] 1

[[1]]$nmol
[1] 1

[[1]]$name
[1] "[M+H]+"

[[1]]$mass
   mass 
145.052 

For this mass feature:

> xsa@groupInfo[118, ]
       mz     mzmin     mzmax        rt     rtmin     rtmax      into      intb      maxo        sn    sample 
 146.0614  146.0599  146.0626  300.6130  297.2490  303.9770 8928.7288 8901.5375 2862.0000  189.0000    1.0000 

I assumed the difference between the neutral mass and mz would be a proton (1.00727...), however this is clearly not the case:

> xsa@groupInfo[118, "mz"] - xsa@derivativeIons[[118]][[1]]$mass
     mz 
1.00942 

As it is not the mz value in groupinfo, what m/z value does CAMERA use to calculate the neutral mass... or am I missing something?

> sessionInfo()
R version 3.1.3 (2015-03-09)
Platform: x86_64-pc-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C         LC_TIME=C            LC_COLLATE=C         LC_MONETARY=C        LC_MESSAGES=C        LC_PAPER=C           LC_NAME=C           
 [9] LC_ADDRESS=C         LC_TELEPHONE=C       LC_MEASUREMENT=C     LC_IDENTIFICATION=C 

attached base packages:
[1] parallel  stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] CAMERA_1.22.0       igraph_1.0.1        xcms_1.42.0         mzR_2.0.0           Rcpp_0.12.3         Biobase_2.26.0      BiocGenerics_0.12.1 stringr_1.0.0      
 [9] data.table_1.9.6    readxl_0.1.0.9000   dplyr_0.4.3         sendmailR_1.2-1    

Isotopes assigned to different pc groups

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.

Screen Shot 2019-07-11 at 12 11 39 PM

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

RT correction is not incorporated into groupCorr() EIC extraction functions

The groupCorr EIC extraction functions (CAMERA:::getEICs(), and getAllPeakEICs() with the underlying getEIC4Peaks()) all extract EICs from xcmsRaw objects using the @groupinfo slot from the xsAnnotate object to determine mz and rt boundaries. However, the groupInfo data will contain shifted rt boundaries if the xcmsSet object had retention time correction applied. This does matters for multiple sample xsAnnotate objects for functions such as calcCis(), as the correlation score will be incorrectly calculated when using rt corrected groupInfo rt boundaries. Worse case, even to the point where an aligned feature across different samples may use use a collection of EICs extracted from (unaligned) adjacent features, or even baseline values. To fix this, something like the following should be done whenever an xcmsRaw object is generated from a xcmsSet object:

xraw <- xcmsRaw(object@xcmsSet@filepaths[i])
xraw@scantime <- object@xcmsSet@rt$corrected[i]

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.