Bugs in fragment ion report from X!Tamdem

[GoogleCodeExporter]

Hi all, thank you for this great lib. I have located (and coded a solution for) 
the following bugs in Tandem2mzid (v1.6.10) when reporting in the output mzid 
the fragment ions from a X!Tandem input file using the xtandem-parser lib.

* Your code assumes that all the ions in the FragmentIon array returned by the 
X!Tandem parser lib have the same charge, but it was not the case in my tests. 
I have added an orderFragmentIons() method to account for this.

* A "break;" was missing in the switch-case block of getFragmentCVParam() 
resulting in a incorrect CV for some ion types.

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 15 Sep 2014 at 2:39

Attachments:

• Tandem2mzid.java
• Tandem2mzid.diff

[GoogleCodeExporter]

Hi Gorka,

well spotted, thanks! It seems to be related to the fact that the underlying 
de.proteinms.xtandemparser simulates the peptide fragmentation (in silico) 
again as well as the spectrum matching in order to (re)generate the list of 
ions (which is apparently then not present in the X!Tandem output file). The in 
silico fragmentation of this underlying library makes indeed theoretical 
fragments of different charges, more specifically when the precursor ion has 
charge X it generates fragment ions of charges 1 to X (the rationale of the 
authors here must have been that fragment ions can lose charge during 
fragmentation, but never gain...not sure if this is always the case). 

Anyway, I merged your changes and will a unit test for it. 

Best regards,

Pieter. 

Original comment by pieterlu...@gmail.com on 3 Oct 2014 at 1:13

[GoogleCodeExporter]

Hi Pieter,
Gorka is correct, fragment ions can carry multiple charges. This is very 
standard with esi. That is why the method you use returns these.
However, as you saw, this information is not present in the xml files and this 
method was originally only written for GUI purposes. For conversion purposes, I 
don't think it is a good thing to use the parser to generate information which 
is not originally present in the file. I would expect Tandem2mzid to convert 
tandem results in the mzIdentML format, and not make any additional 
interpretation. This would lead your users to misinterpreting X!Tandem results. 
I thus advise not to include the fragment ion annotation in these files.
Best regards,
Marc

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

[GoogleCodeExporter]

Hi Marc,
Generation of the “fragmentation data” is already optional in the 
Tandem2mzid, so users can chose whether to add this info or not. I will just 
make sure it is clearly documented as “pseudo fragmentation data”, 
indicating we re-generate the fragment annotations again as it is absent in 
xtandem output. 

Best regards,

Pieter 

Original comment by pie...@thehyve.nl on 29 Dec 2014 at 3:17