did you already thought about the implementation of an option in MS-Dial that allows for (e.g. QC-based) drift correction of signal intensities in all processed samples?
Especially when you have huge sample batches strong drift effects can occur. So from my opinion, this could be a very useful feature for the future.
as some time has passed since my last post, I want to ask, if you already had time to look for the problem? Do you see any problems regarding the attached msp-files?
I have a question regarding the post-processing option in MS-Dial. What is MS-Dial doing, when you have partially (or fully) co-eluting isomers within your post processing txt file, i.e. compounds (adducts) sharing the same accurate mass and a very similar or the same retention time. I processed my current data set in MS-Dial using our in-house-mzRT list consisting of approx. 400 compounds (txt and parameter file, see attached). As a result, and with respect to the Annotation Table I got about 40 matches. In parallel, I processed the same data set applying our R/XCMS workflow. Here, I got up to 40 additional matches when compared to MS-Dial. At least partially, this can be explained by the fact that in MS-Dial only one (of several possible isomers) is annotated, whereas in XCMS any entry in the mzRT list is matched one by one and will finally be reported as “match” or “nomatch”.
In MS-Dial it looks like that in case there are several co-eluting isomers only one of them (probably the best match with respect to ΔRT/Δmz?) is applied to the Annotation Table and the others are “ignored”. This result was independently whether I checked “Only report top hit” in the Identification tab or not.
Is that true?
If yes, may it be useful to report the other possible matches in addition to the top hit (especially when not checking the “Only report top hit”)? So, you would be able to manually check this “isomer issues” in the Annotation Table and no possible match (isomer) can be overlooked.
Of course I can send you the required files. Unfortunately I can´t send you the msp-file here (data format not accepted). Could you therefore send me your e-mail?
Thanks you for your recommendations. I tried to follow the workflow you proposed, i.e.: 1) Converting raw files (I converted into abf and not mzmL for some reason) 2) Processing by MSDIAL using a pre-prepared post-processing list to be able to identify the correct MS2 spectrum more easily 3) Exporting the respective MS2 spectra as single .msp-files for each reference compound (At this point, I changed the NAME descriptions of the msp files, e.g. by adding the prefix "MRI_MS2_..." ) 4) Taking one single msp-file as starting point and sequentially adding the content from the other .msp-files (via Copy &Paste in Notepad), thereby creating my in-house MSMS spectral library (.msp) file
After finishing steps 1) to 3) and starting with step 4) (putting a few .msp-files together), I wanted to check if everything worked fine. So, I took three abf-files (belonging to single standards runs: Apigenin, Apigenin 6-glucoside and Apigenin 7-glucoside). For proofing MS2 matching quality I used the following files examplerily: 1.) post processing (.txt) file including all reference compounds from my mzRT list 2.) MSMS (.msp) file consisting of approx. 20 spectra (compounds) including the apigenin compounds mentioned above. But as I checked the results, I noticed that none of the three standard compounds shows a MSMS matching hit, although their spectra (that had been exported from the same files I used here) were put into the In-house library (.msp) file. In order to test if the error has to do with the merging of msp-files, I also select a single .msp-file (spectrum of Apigenin 6-glucoside) for annotation. But again, there was no MSMS match for Apigenin 6-glucoside.
So I think there is still a problem with the .msp-files but I don´t know what it is.
I have a question regarding the creation & selection of MSMS spectral libraries in MS-DIAL. Is it possible to select several distinct .msp files in one data processing workflow for annotation or is it necessary to have it as one msp-file?
The background of my question is that we are currently creating our Inhouse MSMS spectral library in MS-DIAL. Therefore, we already measured several hundred reference compounds with our LC-QTOF machine.
In general, we prefer to create our own separate msp-file. However, are you able to select these library as well as the database package of MS-DIAL in one data processing workflow. Or would this mean you have to annotate every data set twice, one time with “our file” and one time with the “MS-DIAL file”?
for metabolomics analysis we record our MS2 spectra in DDA mode on a QTOF device (TripleTOF 5600, Sciex).
Especially in the case of pseudo molecular ions with higher intensitites we sometimes get up to three single MSMS spectra per feature and file.
Now, my question is: Are these different MSMS spectra are merged during data processing in MSDIAL? If the spectra are not merged and you have let´s say e.g. three MSMS spectra per feature and file, which of them is then used for database annotation?
Regarding merging, I did not find any setting options in MSDIAL yet (e.g. MS or Rt tolerance). But from my experience I know that merging of MS2 spectra is possbile e.g. using vendor-specific Sciex Software (PeakView) or R/XCMS.
I planned to import Sciex data from DDA experiments in order to build an own, user- and device-specific MS/MS spectral library for annotation in MSDIAL.
In this context, I would like to ask you what MSDIAL compatible data format is suggested for this purpose? Are there variable options, how to extract the MS2 spectra from the raw files? Following this, should the assigned MSMS spectra left as they are or would it be better to eliminate the noise within the spectra before, und if so, how can this be done reliably?
I have a question regarding the (post-)alignment process, i.e. the option to filter „blank features“. In the alignment settings, I checked the blank filter option using an average intensity ratio of sample to blank of 3. Thus, the number of features decreases from 1836 to 933. That means, about 50% of the features were also detected in the solvent blanks with respect to the above-mentioned settings, and consecutively these features were not reported in the corresponding feature list (export by selecting „height matrix list“ and „blank filter option“). However, when you look into that feature list, there are still a lot of features in there, which still have average intensity ratios below 3 or even below 1. Approx. 70% of all features belong to that category of features. So in my case, the blank filter process seems not to work properly.
Do you have an idea what the problem might be and how I can get a better feature list? And a general question, what is meant with „Average Sample Intensity“: the average intensities from all sample files, but including or excluding QC samples?
