GSOC Week 1: The Beginning

Not much coding happend in the first week. Due to a local holiday this week was also a day shorter than normal.
The main things that happend were:
  • I read the python scripts written by the authors of the paper.
  • I created a gantt chart to have an overview over the whole project. It can be found here.
  • I started working on the first part for the workflow (which you can find in my last blog post). Which is the ability of IDFileConverter to concatenate peptide identifications into one FASTA entry.
While talking to my mentors about what I found out in the python scripts and creating a general plan of how to do what, the following interesting points were raised:
  • What happens if one just appends ALL de novo sequences to the database rather then only the high scoring ones?
    In theory, bad de novo sequences should just act as more decoys during the peptide identification search with Comet/X!Tandem or any other search engine.
    This will be checked when the workflow is done!

  • What about post translational modifications?
    If important PTMs are not used during the search, the ID rate will be low. But the metric might still be high, because Novor is missing those PTMs too.

    #db_hits / (#db_hits + #novor_hits)

    Using this it would be possible to tell the difference between crapy data (or database) and just some missed PTMs.

    On a further note if the time allows it an open-modification search (e.g. MSFragger) could be added to the workflow.

  • The re-scoring described in the paper, which is done after the Comet search, is based on a "cross correlation score". This is just the score that Comet uses to score its hits. Therefore other search engines and their score should also be checked for compability. The 'DatabaseQuality' tool could than handle inputs according to the search engine, which was used.

  • While I worked on giving IDFileConverter the option to concatenate the peptides into one FASTA entry, it came to our attention that this concatenation could yield some problems.
    If a Novor peptide begins with a P (proline), is just appended to the privious peptide and later the search engine uses trypsin with the P cutting rule as an enzyme, this previous peptide will never be found. The search engine will only search for the two concatenated peptides.

    AAAAK + PGGGG -> AAAAKPGGGG
    KP site will not be cut. AAAAK peptide is lost.

    Because no easy solution presented itself in the moment. The problem will be handled if we see a lot of P-beginning peptides.

Next week I will start with giving Novor some example files and counting the number of P-beginning peptides to decide if a the problem needs further observation.
After that I will probably finish the work on IDFileConverter and open a pull request for the feature.








Comments

Post a Comment

Popular posts from this blog

GSOC Final Report

Image
What was the goal? A recent publication (found here ) describes a metric to evaluate the suitability of a database used for an identification search of LC-MS/MS data. This is useful because sometimes you don't now from which organism the data is coming from. In that case it is also very challenging to find the best database to search with. OpenMS (codebase located on github ) is a huge open source library with a lot of tools to analyze  mass spectrometry  data. The goal of this project was to implement the freshly proposed metric as a tool in OpenMS. The paper also describes another metric so score the quality of the recorded spectra. This metric was also to be implemented, but it is a lot more trivial and not doesn't need that much attention. Was the goal achieved? Yes, it was. One week ago the final version of the database suitability tool was merged. This tool calculates database suitability and spectral quality according to the algorithms presented in the paper. All algori...
Read more

GSOC Week 8: Benchmarking II

Image
Finally some plots are ready! I finished the python script that executes the paper workflow. Here I did the FDR MinProb transition I wrote about in my last post. I than wrote another python script to execute the OpenMS workflow. (That workflow can be found in my project plan .) Both of these scripts can be found here . Finishing both of these scripts I followed with a quick plotting script and done! The first comparison is ready: This looks promising! The more related the species are the higher the suitability. It would be nice to increase the resolution at the top end of the suitability to be able to differentiate the "right" database better. We are not sure how or if this would be possible since it very well can be that despite the different genomes in related species the proteasome can be even more similar. It would be nice get a similarity of proteasomes for this. When comparing the paper results to the OpenMS results it can be noted that the paper consistently scores abo...
Read more

Project Plan

Image
A ssessing protein sequence database suitability using de novo sequencing  describes two metrics which could both be useful. First of all a metric to verify the suitability of a database for a protein identification of a given sample. The other metric scores the quality of the mass spectra regarding their capability to produce high scoring de novo  sequences. 1. Database Suitability The process of calculating the suitablity of a given protein database for a given set of mass spectra consists of mainly six steps. Those are: Calculate de novo  sequences from the mass spectra; Append high quality (score >= 60) de novo  sequences to one another to create one de novo  protein; Add this protein with a unique header to the given protein database; Run a standard protein search engine (f.e. Comet or X!Tandem); Re-rank instances where database hits and de novo  hits rank 'close' to each other to ensure the database sequence is on top; Count the number of data...
Read more