Closed CarlosHorro closed 4 years ago
@CarlosHorro Highly recommended to use the "Insert code" option when pasting in code. Makes the text much more readable. So I edited your text above. ;)
@CarlosHorro I'd also recommend checking the Database Processing settings for this dataset as they seemed to be using "-REVERSED" as the decoy tag while the FASTA file uses "_REVERSED", hence the FDR validation does not work correctly. Probably does not affect the bug, but worth correcting.
(Note that the change from "_REVERSED" to "-REVERSED" was made a while back in the new backend, but as it only caused issues such as for this dataset, it was later reverted. So if creating new search parameters with old FASTA files (with the latest new backend) the issues should be gone.)
@mvaudel The protein export exception does not occur when loading only the OMSSA and X! Tandem results together. And loading the MS-GF+ results is enough to reproduce the issue. Should simplify the debugging? :)
This commit solves the problem of the export. But we ought to verify that the ambiguous sites assigned to each representative make sense. https://github.com/compomics/peptide-shaker/commit/d56f4fd2c60ca5a4b57922f3509e697c3a24927f
I can confirm that the reports export works again :-) But not very sure about how to confirm that the ambiguous sites make sense... so I share the generated Protein report in case it may help you to check it...
https://www.dropbox.com/s/nppi5zn8d7vdynr/Protein_Report_with_non-validated_matches.xlsx?dl=0
I will set this one to closed, as the reported bug has been fixed. We can always open a new issue if it turns out that the ambiguous sites do not make sense. :)
Hi,
I'm having an exception with a SearchGUI file created with Yehia's worflow in Galaxy when loaded in new_backend PeptideShaker app and I try to generate a Default Protein report with or without non-validated-matches:
I also tried to reuse the old implementation of getSitesSummary instead of the new one:
But there is a very similar error with it too:
So the problem seems to be that the value of "entry.getKey()" in the new implementation sometimes is 0, or the value of "representativeSite" is 0 in the original implementation too.
Problem can be reproduced in PeptideShaker with this SearchGUI result: https://www.dropbox.com/s/6on2fmy5y691r3i/Galaxy304-%5BLabel-SearchGUI%5D.searchgui_archive.zip?dl=0