mzmine / mzmine

mzmine source code repository
https://mzmine.github.io/mzmine_documentation/
MIT License
186 stars 123 forks source link

ADAP Deconvolution? #1817

Open bmgarcia opened 5 months ago

bmgarcia commented 5 months ago

Basic information

What happened

I wanted to inquire about the ADAP deconvolution module. I used this quite routinely on mzMine 3 but don't see it in the upgrade 4.0.3. Is this under maintenance or a discontinued feature?

ansgarkorf commented 5 months ago

Hi, we hope to re-introduce the module soon. We also have an alternative called "GC-EI spectral deconvolution" which will automatically used when setting up a batch with the wizard.

alvaroferochoa commented 4 months ago

Hi, I also used the ADAP deconvolution method in MZmine 3.0 with LC-HRMS data and I was very happy with the results obtained with it. Then, are you planning to integrate it in MZmine 4.0 soon?. You mentioned that an alternative is "GC-EI spectral devoncolution". But, what could be the better alternative for LC-HRMS data? Thanks in advance. Álvaro

bmgarcia commented 4 months ago

I was also using the ADAP for LC-HRMS data similar to Alvaro.

ansgarkorf commented 4 months ago

Very interesting. What are you doing next with the data? ADAP decon stored the features in the isotope pattern. The GC-EI spectral decon module uses a new class called Pseudo Spectrum.

hannierpulido commented 3 months ago

I am also processing GC-MS data. My steps are:

LOC Retention time calibration GC-EI spectral deconvolution Aligner Spectral library search. The workflow works for the most part, but the deconvolution step is overly simplified.

I am using an internal standard with a known main fragment (m/z 383.4). In most of the files, it correctly identifies the compound after the library search, but it misses the ID in 4 out of 170 files. When I look at the spectra, I realize that the major fragment there is not 383.4, but 149.

It seems that the deconvolution step is considering only the major ion because, after this step, the feature with m/z 383.4 vanishes.

I tried running the process without the deconvolution step, and it generated a feature list, but it didn't search the library.

I compared with previous posts and realized that the ADAP deconvolution is more thorough than the current one. Why was it removed?

Also, is there a way to remove specific masses during the mass detection for the GC-EI workflow? It seems that this was possible with the hierarchical clustering deconvolution, but it no longer appears to be available in MZmine 4.1.0.

ansgarkorf commented 3 months ago

Hi hannierpulido, for GC-EI MS data we currently recommend the following steps:

The GC-EI spectral deconvolution uses the feature of the most abundant ion as the representative ion. When you right flick on the feature and select show -> show Pseudo Spectrum you can investigate the deconvolution result. There is currently no option to manually adjust the representative feature for a deconvolution result.

Running the processing without deconvolution will not allow for spectral matching, because no deconvoluted spectrum is available for matching.

ADAP deconvolution is currently under maintenance. If you want to use it now you can fork the mzmine source-code, adjust the code accordingly to your needs and compile yourself.

hannierpulido commented 3 months ago

Hi Ansgar,

Thanks for your reply.

One major drawback of the current deconvolution step in MZmine is its assumption that the most abundant ion corresponds to the target compound of interest. However, in cases where there are interfering m/z values, such as plasticizers or contaminants, the most abundant ion may not accurately represent the target compound. This has led to incorrect peak identification in my case.

One solution could be to use multiple ions to represent the compound of interest.

Another solution, which was available in previous versions but seems to be missing in MZmine 4.1, is the option to exclude specific m/z values. Why is the 'Hierarchical Clustering' module with this parameter no longer present?

Is it possible to reintroduce this parameter during the deconvolution process?

It is a pity that there seems to be no way around this issue. I'm working on Agilent MassHunter, where the peaks can be detected in all samples, but I wanted to migrate my work to MZmine. Unfortunately, this does not seem possible at the moment.

I am not a developer or programmer, so while I appreciate the suggestion to adjust the code myself, this might not be a viable option for most of the MZmine user base.

ansgarkorf commented 3 months ago

Hi, Thanks for the input. I don’t understand the problem regarding the identification. The identification in mzmine is based on the spectral similarity of the deconvoluted spectrum and should not be affected by the representative ion. Can you explain how you usually identify your compounds? Using the most intense signal of the deconvoluted spectrum to determine the representative feature leads to less confusion during the alignment step. How would you determine the representative feature? Do you know how it is done in MassHunter? Is it basically done by ignoring certain mz values? You suggest to use multiple ions to represent the compound of interest. Can you brainstorm how this could look like in the feature table? The hierarchical clustering will be reintroduced after some maintenance work.

DanielCR92 commented 2 months ago

Hello, I'm on MZmine 4.1.0 and don't see the ADAP deconvolution. Anyone knows if the feature is already present on that version and I'm just not being able to find it? I'm processing LC-MS data.

Thanks to the developers for all the hard work!