Unable to bookmark some compounds in manual peak picking

[sunil20dhakad]

I am doing a manual peak picking for a .mzml data. I found something unusual i.e. I am picking some peak for a particular metabolite but it is not stored in bookmark table and automatically calling a function of isotope printing "Clipboard set to isotope summary". This is happening only for particular case like PSUEDOURIDINE 5'-PHOSPHATE and PSUEDOURIDINE

ElMaven version: El_Maven_v0.1.4-18-g654cfb1

[sunil20dhakad]

This is happening when metabolite of same mass and rt is bookmarked again for other metabolite. ElMaven is considering them as isotope which it should not.

[chubukov]

So this was definitely implemented as a feature for precisely this reason -- to not let the user bookmark the same peak for pseudouridine-phosphate and uridine-phosphate. Perhaps it has outlived its utility, but it seems like it actually helped in your case? Not sure exactly what your application is of course.

It does seem like it would be nice if it gave a message instead of silently not adding the peak to the table.

[sunil20dhakad]

@chubukov, since I don't know the RT for metabolites I want all possible metabolites for a peak. I cannot ignore other metabolites by just annotating the peak for only one metabolite. It might be possible that other metabolites point to this peak rather than one we picked. It is already done in Automated Peak Picking but when we are manually picking peaks ElMaven does not allow me to do that.

[MaryPiotrowski]

I am having a similar problem when using Automatic peak peaking. When peaks need manual integration and there are metabolites with the same mass and retention time only one can be added to the Bookmark table at a time. The Bookmark table containing the one manually integrated metabolite needs to be merged to the automatically generated table, then go to the next metabolite, manually integrate it so it appears in the Bookmark table, merge tables, so on…

[sahil21]

@sunil20dhakad @MaryPiotrowski Thanks for reporting. We'll look into this issue. @chubukov Shall we remove this functionality? Is this helpful for you guys? Or should we find some alternate solution for this? We can have some option to enable/disable this functionality but I don't want to make global options too complicated.

[chubukov]

@sahil21 It's not like I feel that strongly about this feature -- we would be fine without it. But I am a little surprised by the desire to do the analysis this way. @MaryPiotrowski or @sunil20dhakad if you don't mind, can you mention your application and why you want to have this type of output (identical data rows with different compound annotation).

To me the fact that you can have this type of result from automated compound search has always been sort of a quirk of Maven. Not a huge problem, but sort of a strange way to do things. If I'm reporting metabolomics data, I try hard to report only one row per actual peak. If necessary, I'll make more ambiguous names (e.g. hexose instead of glucose and mannose, or aspartate instead of d-aspartate and l-aspartate) if we can't separate the compounds. If you look at #91, the idea is precisely to find and then resolve these overlapping groups.

If it's really true that people want to do their analysis this way, then by all means we should enable it, and honestly, it wouldn't make much difference for our usage. But it's just sort of unusual to me, so I'm trying to understand it a little better.

Finally, the way this feature is actually implemented has all these hardcoded cutoffs, so it would be ripe for refactor regardless.

[IpankajI]

@sunil20dhakad @chubukov @MaryPiotrowski when rt difference and mz difference of two groups are less than 0.00001, then these two are considered same group.Previously only one group was getting bookmarked and others were getting silently rejected.Now we have given control to user whether such groups should be bookmarked or not.