Extra fragment ions reported

[GoogleCodeExporter]

Hi dev team, and thank you for your X!Tandem parser.

I am using your lib indirectly throught the mzidentml-lib, where I reported a 
bug (https://code.google.com/p/mzidentml-lib/issues/detail?id=18) related to 
fragment ion reporting in mzid. This bug was caused in part by the 
mzidentml-lib (now fixed) and also by your getFragmentIonsForPeptide() method 
in de.proteinms.xtandemparser.xtandem.XTandemFile.

Fragment ion information is not present in the X!Tandem output file, so you 
perform an in-silico fragmentation and report all the matching ions. But in 
this process you try all possible fragmentations (a, b, c, etc. ions) instead 
of using only those ones actually used by X!Tandem (i.e.: b and y ions). This 
results in reporting different fragment ion combinations for the same m/z 
(i.e.: an y3 ion and also and a7 ion for the same m/z value).

This can be easily solved by searching only for the fragment ion types 
specified in the input parameters group. I attach my solution and a diff in 
case you want to commit it.

Best wishes!

Original issue reported on code.google.com by gorka.pr...@gmail.com on 9 Oct 2014 at 12:13

Attachments:

• XTandemFile.diff
• XTandemFile.java

[GoogleCodeExporter]

Hi and thanks for contacting us on that,
Indeed the ions returned by the parser are the result of a very basic 
implementation with little support for parameters like type of ions, charges or 
neutral losses. It serves more as a base for quick quality control, from the 
parser GUI essentially, where ions are filtered according to a user selection. 
It has never been our intention to reverse engineer the ions used for the 
search. 
I am afraid there is no easy way of knowing the ions actually used by X!Tandem, 
notably in terms of in sillico fragmentation, noise suppression, neutral 
losses, etc. And since the information is not present in the file, as you 
noticed, I don't think it should be expected from the parser. 
Thus, it does not look like a bug in the parser to me, but a misuse of one of 
its internal methods. If you agree, I will close the issue.
Marc

Original comment by mvau...@gmail.com on 9 Oct 2014 at 1:09

[GoogleCodeExporter]

Hi Marc, thank you for your soon response! I do not understand why X!Tandem 
developers did not include the fragment ion information in the output file, 
that should not be a task for the reader/parser. But since you have already 
carried out that basic implementation, I think it would benefit your lib users 
if you include this basic filtering (unless the getFragmentIonsForPeptide 
method is intented for a more general purpose and could affect other users).

Original comment by gorka.pr...@gmail.com on 9 Oct 2014 at 1:36

[GoogleCodeExporter]

Original comment by harald.b...@gmail.com on 9 Oct 2014 at 7:23

[hbarsnes]

We decided to not take any action regarding this issue.