The last column pcgroup describes the compound or pseudospectrum index. Means here that peak 1, 2 and 15 belongs after CAMERAs grouping to compound 166 and peak 3,9 to 84 whatsoever both compound are. The isotope detection searches in both groups separately, which leads to the annotation of two single charged isotope clusters. So if you are sure about the double charged metabolite, then the grouping parameter was to strict. Decrease the EIC correlation threshold to get all peaks in one group.
If not and without the intensity values it's hard to say and perhaps unlikely, but another possibility could be that we have here two co-eluting compounds with a mass difference of 0.5 m/z. I'm only asking because from the very early retention time it seems like the injection peak, where you normally have a bunch of co-eluting compounds.
the determination of the isotope charge is a separated step in the annotation pipeline. Therefore, it relies on the mass differences within a already grouped pseudospectra (so grouping retention time or EICs). For an example with three peaks: 270.0, 270.5, 271.0 m/z
Here 270.0 would get a [M]2+ annotation, 270.5 a [M+1]2+ and 271.0 a [M+2]2+. Another possible annotation is 270 as [M]+ and 271 as [M+1]+, but since the first solution explains more peaks we decide for the majority.
Additionally we have some constrains to filter false positive. For example we estimate the minimum and maximum number of carbon atoms from the monoisotopic peak and calculate a intensity range for the first isotopic peak. Hope this helps a bit.
I can take a look into your example, but it seems the attachment is missing.
Sorry for the late answer, this post slipped through unnoticed. The temporary deactivation of the parallel mode was necessary, since CAMERA had a huge code optimization which broke the multicore functionality. This has been fixed so far.
CAMERA uses a very similar call for Rmpi as XCMS does. If MPI is not available XCMS tries parallel processing via local sockets using the snow package. This alternative could be the reason, why it works under Win 64bit.
I add this adaption on the TODO list and write back as soon as it works.
The rules folder with precalculated ruletable was added with version 1.5.7. Please update if your version is lower. If not, did you get any output from system.file('rules/primary_adducts_pos.csv', package = "CAMERA") ?
I am playing with CAMERA for the first time today, and found this discussion somewhat helpful. But how exactly would one change the ruleset directly? do we read in a csv file with those columns/values?
This is a possibility. Section 6 of the vignette explain this in little more detail.
Quote from: "cbroeckl"
I was playing with the default values, and picking a random annotation of some of my experimental data I found that a dimer was mislabelled as a monomer, and the monomer of the pseudospectrum was mislabelled as [M+2H]++. THe isotope pattern for the true mononomer clearly indicated that this m/z was not doubly charged. How can I prevent this?
The annotation of dimer and monomer are checked against the labeling from the isotope detection. So if a monomer has a [M]+ isotope label, no double charged rule can be applied like [M+2H]2+ So did you use findIsotopes before? If the isotope pattern is recognized correctly, it should not happened. Otherwise it is a bug and for fixing it would be a great if you could provide me an example.
If no isotope pattern is available, it is hard to distinguished between [M+H] and [2M+H] or [M+2H] and [M+H] alone with mass differences.
Quote from: "cbroeckl"
Also, I had another example where I had two compounds in the same peak group annotated as [M+H]+. This of course cannot be correct, but can it be prevented?
At the moment we allow multiple annotation of [M+H]+ in one peak group. Hence, we observe perfect co-eluting compounds, which could not be separated according to there EICs. As long as there are no conflicts for one peak within a group, the different annotation groups (all annotated peaks belong to one compound mass) are "per definition" valid. For example we detect two [M+H]+ and [M+Na]+ peak pairs.
If we wouldn't allow multiple annotation, we clearly lose those cases and we need additional constrains for conflict resolution. For example a) choose the annotation group with the most explained peaks or b) the one with the higher compound mass. Would that make more sense? If there is an interest, we could implement this as an optional parameter in the current devel and see if it improves the results.
to get an almost complete coverage about all possible adducts CAMERA generates an intern ruleset. This is done via combinatorical combination starting from three list, ions.csv, neutraladdition.csv and neutralloss.csv, which are stored under the lists folder in the CAMERA library path. So one possibility is to make changes here.
If you want to change or add smaller subsets/rules you can edit the ruleset directly, which is a little bit more difficult.
The first four columns should be clear. For the massdiff values, these are the direct mass differences without charge adoption, so [M+2H]2+ has charge 2 and massdiff 1.007276. The additional three columns regulate the internal annotation filtering. Oidscore is an identifier encoding if one rule is a direct cluster of another ion. See example above for M+H and 2M+H. For a new rule simply use a new, unique oidscore value. Quasi is a binary value (0/1), which defines if an annotation group (same molecular mass hypothesis) is valid. A group is defined as valid, if it contains at least one annotation with quasi = 1. As standard only M+H, M+Na, M+K and M+NH4 have 1. Ips is a scoring function(experimental), which consists out of four values(0.25,0.5,0.75,1) which represent the importance of this rule. This comes in handy, if an ion have conflicting annotation possibilities. The different annotation group that has the higher sum of ips scores is chosen.
