mzmine / old-mzmine3 Goto Github PK

Hi There,
First, We would like to acknowledge, me and my wife, the efforts of Mzmine team for this great peace of software which helped us in our research.
I think it would be nice and convenient to add a quick (one-click) option in "Chart Properties" that allows to set the plot to "publication-ready" figure. By "publication-quality", I mean: a common accepted font in journals such as "Arial", a black color #000000 for digits, labels and axes, a white background #FFFFFF without grid. I joined below an example of how it would looks like (A: default , B: pub-quality).
Thank you very much !

Hi,

I couldn't find a way to get the TIC for specific MS2 precursor scans only. Is this possible? Otherwise this is a feature request.

https://github.com/mzmine/mzmine2/issues/334

Hi there,

Xcalibur Qual Browser has a plotting feature where multiple chromatograms can be overlayed:
example.pdf

This would be a nice feature to have in MZmine3, as it seems to be a common way to present multiple chromatogram traces in the literature. Xcalibur seems to have it implemented by using two parameters: skew & elevation. Skew translates each chromatogram trace in the X axis whereas elevation translates the chromatogram trace in the Y axis. Each chromatogram is translated by the skew/elevation values, multiplied by the position of the trace - 1 (e.g. 1st trace is at the origin, 2nd trace is translated by 1 skew & 1 elevation, 3rd trace is translated by 2 skew & 2 elevation). The background bounding box seems to be lines drawn from the origin / limits of the axes to limits defined by the skew / elevation of the last trace.

If the graphing framework planned for use in MZmine3 can draw datapoints outside of the bounds of the X and Y axis (as this plot would require), and has a mechanism for directly drawing lines given start and end coordinates, it should be possible to implement such a plot without much trouble. Would be happy to try and implement as MZmine3 progresses & the GUI becomes fleshed out.

Added in MSDK pull request #76. The MSDK discussion on the topic can be found here.

The visibility of the table columns should be saved and loaded from xml so that the users previous settings are remembered when opening a new feature table.

Hi there,

It would be nice if there were a couple blocks for logic / flow control for batch mode.

An simple implementation might be to give the blocks an explicit integer order (e.g. 1,2,3,4,5). Then, there could be a logic block, which could GOTO a certain block if a condition is met (if raw file is all profile data or all positive mode scans etc.) Otherwise the batch would progress in an ascending order. Also it would be good if blocks could have the same order # (e.g. multiple chromatogram builders with order # 3), as then MZMine3 could execute things in parallel due to the existing modularity of the tasks.

Given how high-resolution accurate mass instruments are becoming more common, it would be nice if isotopes were handled more discretely in MZmine3. A couple ideas below:

1. MZmine2 currently picks isotopes in the isotope grouping module by looking in a parameter defined m/z range around the "average" neutron mass (at least that is my understanding of how the module works). In principle it is possible to look for exact isotopic differences (+15N neutron, +13C neutron etc.), which have subtle but resolvable differences in m/z on a HRAM instrument run at a "reasonable" mass resolution setting (e.g. 70,000). Ideally such isotopes, when linked to the molecular ion, would be annotated & queryable as the likely possible isotope. The set of possible isotopes or elements to look for should be definable by the user, as clearly all isotopes on the periodic table is a bit much, but restricting it to what is currently interesting to the user makes it manageable & informative. Ideally, relative abundances of discrete isotopes could be quickly computationally queried (e.g. what is the relative abundance of +15N, +3x 13C, as compared to the molecular ion), which would be very useful for stable isotope assisted metabolomics. Currently such an analysis of unusual deviations of isotopes such as in stable isotope assisted metabolomics can be preformed by not running the isotopic groping module & using the adduct search module to pick out particular isotopic peaks.
2. Local calculation/calibration of the mass accuracy for the isotope grouping. I haven't done careful analysis of how the mass accuracy of the mass difference between isotopes is over the small m/z range of the possible isotopes (e.g. if I expect a particular isotope to be 5.012351 m/z away from the precursor mass, how accurate is this mass difference). My expectation is that it is spot on, or it will be highly amenable to calibration given the small m/z range & defined isotopes (bootstrap calibration with common or unusual isotopes such as multiple 13C / or combinations with 15N)
3. Calibration of the divergence of isotopic ratios away from expected ratios. The relative abundances of specific isotopic as defined by chemical data sources are (I believe), based on what you might find in "rocks". Biology has some well described isotopic preferences (e.g. preference of Rubisco for C12 over C13/C14, which is the basis for C14 radioisotope dating), which may produce measurable and reproducible divergences from expected isotopic ratios as defined by chemical data sources. E.g. isotopes patterns should and may turn out to be measurably different for animal cells, yeasts, plants etc, which have greatly varying core metabolisms. If particular isotopic ions can be detected & annotated, then it should be possible to calibrate how much that particular divergences from the expected isotopic ratio (if stable isotopic tracing is not being performed which would lead to unpredictable deviations). This could lead to greater specificity with the "isotopic pattern scoring" with the chemical formula prediction. This of course should be flexible with the user as not all workflows rely on biological metabolites.

It would be nice with a module which can merge two or more feature tables with the option to keep e.g.:

• all features
• overlapping features
• unique features

Right now mzMine2 can import custom metabolite ID databases in CSV format. This is flexible, but why not use mzTab format explicitly (which I believe has a field for identifications) as the format for importing/exporting compound identifications? Ideally the mzTab / compound identification file could also have parseable InChI for the feature in question, which would allow computation of parameters.

We need to be able to associate metadata (or sample parameters as it is called in MZmine 2) to samples. This is needed for the data analysis and statistical modules.

Currently in MZmine2 when a line representing data is exported (e.g. TIC plot) into a vector file such as .eps, it is actually made of multiple discrete line segments. On the other hand, Xcalibur (when printing a TIC), produces a vector file with a single contiguous line / TIC. This makes it much easier to edit in downstream vector manipulation software (Adobe Illustrator / Inkscape). This would be a nice perk to have in MZMine3 (though is likely strongly dependent on graphics library quirks)

I would like to add a module for m/z calibration of peak lists based on compounds with known chemical formulas.

Something like this:

Peaklists have enough information for some simple plots (intensity, RT, m/z), in the absence of .raw data.

Hi there,

It would be nice if there were a couple blocks for logic / flow control for batch mode.

An simple implementation might be to give the blocks an explicit integer order (e.g. 1,2,3,4,5). Then, there could be a logic block, which could GOTO a certain block if a condition is met (if raw file is all profile data or all positive mode scans etc.) Otherwise the batch would progress in an ascending order. Also it would be good if blocks could have the same order # (e.g. multiple chromatogram builders with order # 3), as then MZMine3 could execute things in parallel due to the existing modularity of the tasks.