In our research group, we have been trying to transfer to use MS-DIAL 5 but have run into some issues. So far we have recognized two separate problems:
The program is unstable in certain computers and will crash unexpectedly before even setting all the parameters for the peak picking. It seems to be unrelated to the known issues, such as the decimal comma used by many language settings.
The parameters can be set but the peak picking will instantly fail resulting in crashing once you press "run" apparently because the msp database given by the user contains something that crashes it. One thing that will result in this situation is if the database accidentally contains any negative ions if you are running a positive mode project or vice versa.
While we are fixing our databases, could the parser that reads the database ignore any wrong/faulty entries in the database file to allow peak picking to initiate or give a warning/error message if the database has issues that prevents using it?
To get back to this matter, we have tried again with version 4.92 and the same issue persists. It seems that version 5 does not yet have a console app – are there plans to introduce it?
We are experiencing problems with the MS-DIAL console app. It gives an error (screenshot below) which seems to point towards the adduct list in the parameter file, which the parser is not able to read. We used the parameter file exported directly from MS-DIAL. Could it be that there is some glitch in the code of the console app that it wants the adducts in a different format than given by the GUI version?
We have a similar issue with the Windows console app regarding question no. 2. We often have a blank at the beginning of the injection sequence and if a blank is chosen automatically as the reference file for peak alignment, will it cause a major issue for this process since it probably doesn't contain peaks from most metabolites?
I have a question related to the MS/MS data format provided in the MS/MS spectrum column in the exported alignment result file. The MS/MS fragments are listed there in ascending order of the m/z as m/z1:abundance1 m/z2:abundance2 etc. For reporting MS/MS spectra in publications, we often have a format where the most intense fragments are listed in descending order of relative intensity as follows: m/z1 (pergentage1), m/z2 (percentage2) etc.
Is there a way to automatically transform the data in the MS/MS spectrum column into another format that is more suitable to be reported as such in a publication? Perhaps someone has used an Excel macro or R script? This would be handy in case there are plenty of MS/MS spectra to report.
Thank you @jjjvanderhooft for your comments and advice. Indeed the moiety being cleaved off will often ionize in one mode only, in which case it will be seen as a neutral loss in one mode and as a peak (with possible fragments) in the other. This should be taken into account but so far I haven't had enough data to classify the information based on that.
Unfortunately this is the best version at the moment since I didn't have access to a vector version of the MetSoc logo or even the font itself (Banker Square)...
Thank you @Jan Stanstrup for the useful information. Yes I think we could work on compiling all this data. To me it does not matter which file sharing method is used.
I have been looking for a comprehensive list of neutral losses commonly seen in MS/MS spectra but haven't been able to find one. Instead, I've started to compile a list on my own with some additional information, such as the functional groups to which the neutral loss may be related and how the moieties may be further fragmented. You can access and use the list in Excel format using the OneDrive link below and expand it freely. Also, any good source for additional information is most welcome.
