UP | HOME

Tagebuch Bachelorarbeit MyriMatch

Inhaltsverzeichnis

Akut zu tun
struct
Entwurf für den Textteil
Timeline

TODO Akut zu tun

[X] ROC plots so hinbekommen, dass die Daten Sinn machen :p
[-] Usabilty verbessern
- [ ] doxygen doku für MyriMatchAdapter erstellen
- [ ] In die Doku vom MMA: wenn MM sagt, da ist nix, dann weil mzML file falsch
  - workaround: convert nach mzData und wieder zurück (erst ausprobieren)
- [X] Automatische Erstellung von Decoys durch Myrimatch unterdrücken.
  - No Decoy über die cfg probieren
[X] Ausprobieren was passiert, wenn PepXMLFile die spectrum_querys zu einem scan nicht mehr zusammenfasst und MM statt dessen keinen chargePredictor verwendet
- Geht gut.
[X] Refactoring [7/7]
- [X] Auslagern des Modification Mappings in eine Funktion
- [X] Mehr bezeichner für variable Modifikationen einführen
- [X] In PepXMLFile xcorr ent-kommentieren. Also es eleganter lösen, dass bei MyriMatch der mvh score eingetragen wird.
- [X] Das Zusammenfassen der peptide_queries rückgängig machen
- [X] temporäre pepXML löschen
- [X] versionsprüfung nochmal solider machen. (beim scheitern eine sinnvolle Fehlermeldung). Welcher EXIT_CODE?
- [X] Wie soll eine Fehlermeldung ausgegeben werden? Mit writeDebug_()?
[-] Wünsche an MyriMatch
- [ ] Eine Möglichkeit die Version auszulesen
- [X] Eine Möglichkeit die automatische Decoy Erststellung abzustellen.
[ ] InsPecT Adapter schreiben

struct

Introduction
Meausremnet of peptides
Data acquisition
- u.a. peptide fragmentation
ConsensusID Piepeline
- OpenMS
- SE
- conID
- MM
Methods
- MMA
- PepXML
- IDPep für MyriMatch
results
Discussion

Entwurf für den Textteil

Abstract
- seher oberflächlicher Überblick über das Thema und die Ergebnisse
- statement
Einleitung (2 Seiten)
- Thema motivieren
- Einen oberflächlichen Überblick über das Thema geben.
- Definition von Peptidenn
- mass spectrometry
- identification
- vorangegangene arbeit
- bottom up (peptides, digested proteins)vs. top down (proteins) mass
- was ist der eigene beitrag
Was ist MS/MS (2 Seiten)
- kurz beschreiben wie das gerät funktioniert
- daten beschreiben.
  - was ist ein spektrum
  - was ist eine map
  - b/y ionen leiter
Was ist eine Search Engine (2-3 Seiten)
- allgemein search engine
- myrimatch
- scoring funktion
- unterschied zur datenbank und denovo
Was ist ConsensusID (2-3 Seiten)
- ein wenig mathe
Was ist OpenMS (2-3 Seiten)
- eigene Arbeit
- beschreiben, was der Adapter kann
Results
- tesaufbau
  - mit toppas
- ROC Plots
- venn diagramm und vergleich zum MM paper
Discussion
- possible extensions
Anhang
- suchparamter zum begleitenden material

Timeline

2012-01-27 Fri 12:19

SVN Kennelernen

2012-01-27 Fri 12:36

Pakete für OpenMS installiern

2012-01-28 Sat 14:08

doxygen Doku erstellt
doxymacs für emacs eingerichtet
emacs zum betrachten von doku mmit w3 eingerichtet
XTandemAdapter und MascotAdapter angesehen
- Was gibt es für Parameter und wie werden sie registriert?

2012-01-29 Sun 14:56

Versuch X!Tandem zu installieren
- anders überlegt, da die installation zu aufwendig erscheint
Versuch SEQUEST zu installieren
- installationsdateien nicht gefunden
- Installtion von OMSSA zu installieren
  - runterladen von FASTA Datein nach ~/blastdb mit dem ziel mit makeblastdb (statt formatdb) eine Datenbank zu erstellen
  - ftp://ftp.ncbi.nih.gov/blast/db/FASTA/
  - Ziemlich groß
  - abgebrochen, denn zu groß und wohl auch nicht das was ich brauche
  - Lade die nr datenbank runter, da dies am sinnvollsten erscheint
  - wget ftp://ftp.ncbi.nih.gov/blast/db/nr*
  - "exprt BLASTDB=/home/dima/blastdb" in ~/.bashrc geschrieben
  - OMSSA ist eingerichtet, warte auf den Download der Datenbank
Stelle fest, dass OMSSAAdapter besser als Beispiel geeignet ist
- Maintainer ist mein Betreuer und besser (oder zumindest mehr) dokumentiert

2012-01-29 Sun 15:59

Operatorüberladung in C++ ins Gedächtnis zurückgerufen
runterladen von MyriMatch: Linux x86_64
- http://fenchurch.mc.vanderbilt.edu/software.php
- myrimatch-bin-linux-x86_64-gcc41-release-2_1_111.tar.bz2
- sehr angenehm: nur eine binary und sauberes interface
MyriMatch entnimmt die meisten Optionen einer Konfigurationsdatei. Hier ein Beispiel: http://osdir.com/ml/spctools-discuss/2010-11/msg00088.html
MyriMatch braucht scheinbar fasta dateien, musste also nochmal viel runterladen, aber damit funktioniert das auch noch nicht.

2012-01-30 Mon 10:27

MyriMatch akzeptiert nur *.fasta Dateien als Datenbank. Habe nr.aa runtergeladen und in nr.fasta umbenannt. Warte aufs ergebnis.
Habe MyriMatch ein Beispiel mzML gegen nr.fasta laufen lassen. Dauert ganz schön lange. Hat auch eine Weile gedauert, bis 100% CPU auslastung kam. Das nächste mal mit mehr Kernen probieren.
Stelle fest: Arbeitspeicher ist zu klein. Festplatte arbeitet ständig. Das nächste mal auf einer kleineren Datenbank.
MyriMatch behauptet, dass die InputDatei falsch ist. Parameter waren die folgenden:
- $ ./myrimatch -ProteinDatabase ~/blastdb/alu.fasta ../OpenMS/share/OpenMS/examples/peakpicker_tutorial_1.mzML
  - Reading spectra from file "../OpenMS/share/OpenMS/examples/peakpicker_tutorial_1.mzML"
  - Read 0 spectra with 0 peaks; 0.0204861 seconds elapsed.
  - Skipping a file with no spectra.
Habe versucht den OMSSAAdapter auszuführen, aber der nimmt die mzML Datei auch nicht an.
- $ ./OMSSAAdapter -in /home/dima/thesis/OpenMS/share/OpenMS/examples/LCMS-centroided.mzML -omssa_executable /home/dima/thesis/downloads/omssa/omssacl -out here.out -database /home/dima/blastdb/nr.00.psq
  - Progress of 'loading mzML file':
  - done [took 0.010 s(CPU), 0.014 s(Wall)] --
  - "omssacl.cpp", line 196: Fatal: COMSSA::Run() - omssacl: unable to read spectrum file – incorrect file type?
  - Error: OMSSA problem! (Details can be seen in the logfile: "")
  - Note: This message can also be triggered if you run out of space in your tmp directory

2012-02-01 Wed 19:18

Habe MyriMatch mit daten von Chris Bielow zum laufen gebracht
Habe mir pepXML angeschaut
- schwer zu erkenne, was ich da jetzt wissen muss über pepXML
Habe beschlosse langsam vorzugehen und einen Stub für den MyriMatchAdapter zu schreiben

2012-02-02 Thu 12:00

Habe die Datei MyriMatchAdapter.C (MMA) erstellt und erfolgreich gebuildet
MMA registriert jetzt einen Parameter und gibt ihn auf der Console aus
Die nächsten Schritte sind:
- mit hard gecodeten argumenten MM ausführen.
- dann über die kommandozeile parametrisieren (nur in, out und db)
- Zunächst soll pepXML erstellt werden
- DONE 2012-02-02 Thu 18:52

2012-02-06 Mon 13:26

Folgende erkenntnis: MyriMatch schreibt die retention time nicht in die pepXML
Idee: ein script schreiben, dass die retention Time nachträglich in die pepXML einträgt aus gehend von den Inputdaten
Zunächst: habe mir den MyriMatch source runtergeladen und suche nach einer undokumentierten Funktion, mit der sich die RT eintragen lässt und um weitere Erkenntnisse über die Funktionsweise von MyriMatch zu gewinnen.

2012-02-10 Fri 17:13

der fileconverter findet modifikationen nicht, was auch immer das bedeutet.
Habe script so angepasst, dass zumindest verschiedene RTs eingetragen werden.

2012-02-10 Fri 20:08

habe script so angepasst, dass die echten(!) RTs eingetragen werden, hat aber nix gebracht
Versuche nun die richtigen Daten mit der richtigen Datenbank zu kombinieren.

2012-02-10 Fri 10:30

Besprechung mit Reinert und Bielow
- Bewertung
  - Wenn alles gut ist, dann ist das "gut"
  - Richtung 1 geht man, wenn man alles besonders gut aufschreibt
  - Wenn man besonders gut implementiert
  - Wenn man tight für windows zugänglich macht
- Umfang
- Zusatz durch tight
  - tight für windows anpassen
- Meilensteine
- regelmäig melden
- dauert 3 Monate
- Chris ist der Ansprechpartner
- Im Wiki stehen die Infos
- Aufbau:
  - Einleitung 2-3 Seiten
  - Was ist MS/MS 2 Seiten
    - kurz beschreiben wie das gerät funktioniert
    - daten beschreiben.
      - was ist ein spektrum
      - was ist eine map
      - b/y ionen leiter
  - Was ist eine Search Engine 2-3 Seiten
    - allgemein search engine
    - myrimatch
    - scoring funktion
    - unterschied zur datenbank und denovo
  - Was ist ConsensusID 2-3 Seiten
    - ein wenig mathe
  - Was ist OpenMS 2-3 Seiten
    - eigene Arbeit
    - beschreiben, was der Adapter kann
  - Results
    - tesaufbau
      - mit toppas
    - suchparamter zum begleitenden material
    - venn diagramm und vergleich zum MM paper
  - discussion
    - possible extensions
  - venn diagramm
  - roc plots
  - spectren
    - ms2 und ms1 spec
  - Map

2012-02-10 Fri 12:43

Erweitere mein Test Script
Die von MyriMatch gelieferte pepXML Datei ist für den Fileconverter ungeeignet, deswegen schreibe ich scripts, die die Datei anpassen
ein perl script geschrieben, das eine search_id von 1 in den search_summary tag einfügt
ein perl script geschrieben, das retention_time_sec="1337.1337" in jedes spectrum_query tag einfügt

2012-03-02 Fri 13:12

Klausuren sind vorbei und ich bin ein wenig erholt.
Nehme die Arbeit wieder auf. ;)
habe ein Gerüst für die Niederschirft erstellt. Habe mich entschieden die Arbeit auf Englisch zu schreiben. Hoffentlich klappt das.
Als nächstes habe ich mir vorgenommen, die paper zu MyriMatch und zu ConsensusID zu lesen. Brauche auch eine allgemeine Quelle zu Massenspctroskopie und zu Peptididentifikation.
teilweise das paper zu ConsensusID gelesen. (als nächstes den Abschnitt Data Sets lesen.

2012-03-06 Tue 14:33

Versuchen den OMSSAAdapter erfolgreich auszuführen.
was ist der Unterschied zwischen mzML und mzXML???

2012-03-12 Mon 14:03

Weiter mit OMSSAAdapter
Halte fest: mzML->{SEARCH ENGINE}->idXML
Ich habe myrimatch bis jetzt nur mit einer mzXML Datei gefüttert. Frage: geht auch mzML?
Das wusste ich eigentlich schon früher: mzML wird von MyriMatch zwar unterstützt, aber es nutzt eine engere Definition des Formats, als die offizielle.
Lösungsmöglichkeiten:
1. Einen Converter schreiben, der die Definition von MyriMatch einhält
2. Hoffens dass Chris das MyriMatch-Team überzeugt die Definition zu ändern
3. Hoffen, dass das OpenMS die Definition zu der von MyriMatch ändert
In der E-Mail vom 1. Februar hat Chris geschrieben, dass es funktioniert, wenn man nach mzXML konvertiert. Damit werde ich zunächst mit mzXML dateien arbeiten.
festgestellt, dass mein Skript zum hinzufügen der retention time, nur mit mzXML funktiert. Werde das zu gegebener Zeit anpassen, sodass es mit mzML funktioniert. Wenn das dann überhaupt noch nötig ist.
weiter mit OMSSAAdapter: habe OMSSAAdapter mit einer mzML datei ausgeführt, die ich aus der mzXML Date konverteiert habe, mit der ich MyriMatch ausprobiere. Programm terminiert mit warnings nach einer Sekunde. MyriMatch braucht für diese Daten 50 Sekunden.
bei zwei grundverschiedenen Daten kommt beim OMSSAAdapter folgende Meldung ganz am Anfang
- Warning: while loading term 'MS:1001191' of CV 'MS': parent term name 'peptide quality estimation measure' and id 'MS:1001092' differ.
- Warning: while loading term 'MS:1001883' of CV 'MS': parent term name 'transition validation attribute' and id 'MS:1001881' differ.
- Warning: while loading term 'MS:1001884' of CV 'MS': parent term name 'transition validation attribute' and id 'MS:1001881' differ.

2012-03-14 Wed 12:53

Die ID Daten von MyriMatch sind ca. 20 mal so groß, als die von OMSSA, schaue sonst aber ähnlich aus. Ich denke, das ist auf den Unterschied in den Algorithen zurückzuführen, da MyriMatch nicht so viel wegfiltert.
ZWISCHENSTAND
- Ich weiß jetzt, wie man MyriMatch bedient. MyriMatch benötigt input in mzML, doch das in einem speziellen Format, das mir nicht zur Verfügung steht, weswegen ich vorerst mit mzXML arbeiten werde. Als output erhält man eine pepXML Datei, in der jedoch keine retention times drin stehen. Die retention times kann man aus der inputdatei abschreiben. Dann funktioniert das konvertieren nach idXML problemlos mit dem aktuellen FileConverter.

2012-03-14 Wed 13:33

Also es schaut nun so aus, als stiege OpenMS auf die mzML Definition von MM um. Ich mache ein Update auf den aktuellen HEAD.
Nun ist es so, dass in einer mzML mindestens ein Scan name="MSn spectrum" haben muss.
probiere nun, wie vorgeschlagen, einen Workflow aus den TOPPAS Beispielen mit MM nachzubauen. (E coli.)
Mit E coli hat es nicht geklappt, aber mit LT…SONSTWAS gegen HUMAN.fasta.
Habe festgestellt, dass die pepXML Datein doch nicht angepasst werden müssen, da das schon IDFileConverter leisten kann, wenn man den Parameter mz_file übergibt.

2012-03-15 Thu 14:52

Habe heute meine Arbeit angemeldet. Abgabetermin ist der 7. Juni 2012
Werde jetzt anfangen den Adapter zu schreiben.
versuche den Adapter soweit schon aufzubauen, dass ich damit schon ein Interface zu den Funktionen habe, die ich bis jetzt genutzt habe

2012-03-16 Fri 16:25

Habe jetzt über den MMA eine Schnittstelle zu MM, aber nur für die grundlegendseten Funktionen.
Ich habe versucht den OMSSAAdapter nachzuahmen, aber ich verstehe dort nicht zu 100% den Sinn von manchen Codepassagen.
Insbesondere wird beim OMSSAAdapter eine temporäre Datei erstellt, in die die mzML kopiert und in einem anderen Format abgespeichert wird. Nun kann MM direkt mit mzML umgehen, also braucht man da keine extra temporäre Datei, oder?
Räume den Code auf. Insbesondere die Passagen, die etwas mit den temporären Dateien zu tun haben. DONE.
Bräuchte jetzt kleinere Daten um weitermachen zu können, denn sonst dauert jede Suche bei mir 20 Minuten.

2012-03-20 Tue 19:57

habe jetzt verweise auf neue Daten von Chris bekommen. Werde mich jetzt darum kümmern vernünftige Suchen durchzuführen.
hat nicht funktioniert, da die daten in mzXML sind und msconvert einen unverständlichen Fehler liefert

2012-03-21 Wed 15:37

Habe von Chris den Tip bekommen die von ihm vorgeschlagenen mzXML daten zuerst mit OpenMS nach mzXML zu konvertieren und dann mit msconvert nach mzML. Das hat sehr gut geklappt!
habe einen Branch von Chris im Repository bekommen, werde mir das aber erst später anschauen.
Jetzt erstmal weiter programmieren.
Habe mir angesehen, was bei der implementierung von PepXML fehlt.
Es wird mod_nterm_mass nicht rausgeparsed
Problem: So funktioniert das nicht mit den mzML. FileConverter stört sich auf vielfältige Art und Weise an den Dateien.

2012-03-22 Thu 17:04

Habe weiter probiert eine brauchbare mzML zu produzieren, hat aber mäßig geklappt. Aus einer bestimmten mzXML bekomme ich eine mzML, bei der "nur" warning kommen.
Ansonsten scheint es ein Problem mit msconvert zu geben. Chris informiert darüber die msconvert Developers.
Habe Chris gefragt, wie das nun mit den Modifikationen ist und wie ich die ID File Conversion regeln soll.

2012-03-23 Fri 18:20

Folgender Plan jetzt: die erzeugte PepXML Datei mit load einlesen und dann mit store abspeichern. Dafür werde ich den MyriMatchteil erstmal ganz auskommentieren und mit einer bereits vorhandenen pepXML Datei arbeiten.
Mein Adapter produziert jetzt eine idXML Datei, unter verwendung der entsprechenden Bibliotheksfunktionen. Muss zu gegebener Zeit überprüfen, ob der das auch so richtig macht. Es gibt immernoch die selben Probleme, die es mit dem IDFileConverter gab, aber die sind wahrscheinlich nicht unbedingt mein Problem.
Werde jetzt refactorn

2012-03-24 Sat 15:35

Ich werde wohl die Unimod notation übersetzen müssen in die MyriMatch notation für PTMs. Muss mir nochmal genau anschauen, wie das funktioniert und werde dann noch Chris fragen, ob es schon Verfahren zu Übersetzung gibt. Vorerst werde ich die Modifikationen in MyriMatch Notation an den Adapter übergeben.
Muss mich eigentlich länger mit Chris darüber unterhalten, wie dieses ganze Modifikationsgeschichte funktioniert.
gefühlt großen Fortschritt gemacht
Habe jetzt ein Skript, dass ein mzXML File einlesen kann und erfolgreich ein idXML File produziert, sogar mit den richtigen RTs. Fast die gesammte Logik ist dafür im Adapter. Noch ganz ohne Modifikationen.
Funktioniert bisher leider nur mit mzXML Dateien und da auch nicht mit allen. Funktioniert auf Orbitrap Daten.
Fehlt u.a. noch den pepXML parser anzupassen.

2012-03-25 Sun 19:01

Habe mir die unimod Modifikationen ein wenig angeschaut und wie das beim OMSSAAdapter funktioniert.
Habe festgestellt, dass es beim OMSSAAdapter ein festest mapping für 10 Modifikationen gibt und sonst nichts. Wäre cool, wenn das für den MMAdapter auch hinreichend wäre
jetzt funktioniert es so, dass der MMAdapter ein mapping aus einer Datei ausliest und dann entsprechende Unimod modifikationen verarbeiten kann.
Habe heute auch viele Fragen an Chris geschickt

2012-03-26 Mon 17:36

Der Adapter kann jetzt mit min/max_precursor_charge umgehen
Es stellt sich die Frage, warum bei unimod scheinbar nicht zwischen statischen und dynamischen Modifikationen unterschieden wird, MyriMatch aber verschiedene Notation dafür hat.
Ansonsten warte ich erstmal auf eine Antwort von Chris.

2012-03-27 Tue 17:19

Habe refactored und hilfsparameter entfernt. Versuche das ganze für das Treffen mit Chris ein wenig hübsch zu machen. :p

2012-03-28 Wed 20:16

Implementiere jetzt eine Überprüfung der MyriMatch Version.
MyriMatch scheint keine Möglichkeit anzubieten die Version erfahren, außer eine Suche zu starten, oder einen EXIT_CODE != 0 hinzunehmen.

2012-03-29 Thu 17:28

Habe eine Überprüfung der MM Version eingebaut, allerdings besteht das Problem, dass sich die MM Version nicht einfach abfragen lässt. Jetzt wird ein EXIT_CODE!=0 von MyriMatch bei der Versionsabfrage in Kauf genommen.

2012-03-30 Fri 13:52

Habe mich mit Chris getroffen und viele offene Fragen geklärt. Erstelle jetzt eine TODO Liste und arbeite sie ab.
[X] neuere/ältere Version von proteowizard wege softwareRef ausprobieren.
- neuster build hat nichts gebracht
- mit release 2.2.3181 (2011-12-21) funktioniert das auch nicht. selbes problem.
[ ] Debuggen, warum 'Can not find modification X' beim Laden der pepXML
[ ] PepXMLFile anpassen um das eine Argument zu berücksichtigen
[ ] precursor_mass_tolerance
- User kann einheiten über einen Flag wählen
- User kann zwischen Mono und Avg wählen
[X] Übersetzung von Unimod nach MyriMatch notation
- [X] Statische Modifikationen
- [X] Dynamische Modifikationen
[ ] fragment_mass_tolerance: Einheiten wählen lassen
[ ] Parameter als spezielle MM Funktionen durchreichen
- NumChargeStates
- TicCutoffPercentage
- MonoisotopeAdjustmentSet
- MaxDynamicMods
- MaxResultRank
- CleavageRules
- MinTerminiCleavages
- MaxMissedCleavages
[ ] Parameter als advanced Funktionen durchreichen
- MinPeptideMass
- MaxPeptideMass
- MinPeptideLength MaxPeptideLength
- UseSmartPlusThreeModel
- ProteinSampleSize
- NumIntensityClasses
- ClassSizeMultiplier
[ ] DecoyPrefix mit leerem Strig übergeben
[X] Datenbank File überprüfung verschlanken, da das gar nicht nötig ist.
[X] MyriMatch version nur auf Major und Minor prüfen und nur 2.1 unterstüzten. Sonst Warning.
[ ] E-Mail an MM- und PW-Team verfassen und zur Durchsicht an Chris schicken.
[ ] Warning: ignoring unrecognized parameter "-ThreadCountMultiplier"

2012-03-30 Fri 19:00

Implementiere die Modifikationen, in dem die entsprechenden Infos über die Modifikationen aus der library geholt werden.
Problem(?): Es gibt in Unimod modifikationen, die sich auf keine Aminosäure beziehen, sondern auf N-term z.B. Es ist mir nicht klar, ob Myrimatch damit so ohne weiteres umgehen kann. Ich vermute nicht.

2012-04-01 Sun 19:00

Versuche PepXML anzupassen
Es sieht für mich danach aus, als würden N-Term mods richtig berücksichtigt werden, sofern sie auf bestimmte Aminosäuren eingeschränkt sind. Dieses mod_nterm_mass Argument taucht nur auf, wenn die Modifikation pauschal für alle gilt.
Erweitere die Übersetzung von Unimod nach MM um N/C-term modifikationen. Bis jetzt nur für welche, bei denen die Aminosäure nicht eingeschränkt ist. Muss das auf für die anderen gemacht werden?
habe jetzt scheinbar PepXMLFile soweit erweitert, dass es funktionieren sollte.
brauche noch ein Besipeil für eine C-terminale modifikation um C-terminale auszutesten
Habe rausgefunen, dass das mit C-terminalen analog funktioniert und habe dafür den code für mod_nterm_mass dupliziert (nur mit c statt n)
Problem: kann den "cannot find modification x" Fehler nicht mehr reproduzieren. o.O
Konnte jetzt mit der run2*.mzXML den Fehler <Non-fatal error while loading '/home/dima/thesis/run2pps_D06_03005_hlee_18pro_mix_1144400407.pepXML': Cannot get precursor information - scan mapping is incorrect> produzieren

2012-04-02 Mon 11:29

Sehe jetzt weiter zu, wie ich den Adapter fertig stellen kann.

2012-04-03 Tue 12:39

habe jetzt die precursor_mass_tolerance geschichte fertig
Die Website von MyriMatch ist down, habe sie mir aber aus dem Google Cache geholt.
jetzt wird MM mit -DecoyPrefix "" aufgerufen.
habe Probleme mit MonoisotopeAdjustmentSet. Wollte das als InList parameter einbauen, jedoch scheint getIntList_ methode nur eine Liste mit dem ersten angegebenen Element auszugeben. Fahre erstmal fort mit den anderen, einfachen, parametern.

2012-04-04 Wed 09:59

Mein Ziel ist es heute alle Parameter des MyriMatch adapters fertig zu stellen und eine E-Mail an das MM- und PW-Team zu verfassen.
Habe jetzt alle Prameter umgesetzt, außer MonoisotopeAdjustmentSet, da dafür die getIntList_ methode nicht funktioniert. Da muss ich mal Chris fragen, wie die funktionieren könnte.
Werde jetzt versuchen eine Minimalbeispiel für PW zu finden, das zeigt, dass msconvert nicht richtigt funktioniert.
wollte mit FileFilter von OpenMS eine mzXML Datei reduzieren, aber FileFilter kann nicht mir mzXML Datien umgehen. Ich schau mal, ob proteowizard etwas in die Richtung machen kann.
Probiere MMA in TOPPAS einzubauen, doch bei der verwendung macht TOPPAS etwas merkwürdiges, und zwar wird MM (nicht MMA) zwei mal gestartet und das zweite mal mit einem ungülten Parameter.
Ich kommentiere alle nicht unbedingt notwendigen Paramter erstmal aus.
Habe Problem gelöst: beim laden des Experiments wurde nur der basname benutzt, da aber TOPPAS das Verzeichnis wechselst, wird jetzt der ganze Pfad übergeben.
Die ganze MyriMatch-PipeLine ist durchgelaufen, werde jetzt versuchen das ganze mit OMSSA und ConsensusID zu kombinieren. Die Spannung steigt!
Problem: Man kann bei MyriMatch nicht verhindern, dass die pepXML ins Arbeitsverzeichnis geschrieben wird. Ich lösche jetzt die pepXML dann einfach von da, da sie nicht benötigt wird. Das ist aber Problematisch, da die pepXML da liegen bleiben könnte, wenn der Adapter abstürzt.
habe festgestellt, dass der Adapter innerhalb von TOPPAS auf eine alte (also falsche) pepXML zugegriffen hat.
Also habe jetzt folgendes festgestellt: Damit die Daten der searchengines verglichen werden können, dann müssen posteriori wahrscheinlichkeiten für die Treffer berechnet werden. Das kann man mit dem TOPP Tool IDPosteriorErrorProbability machen, das aber leider nur ein paar search engines unterstützt. Es scheint so, als müsste man nur zwei Zeilen hinzufügen um es für MM nutzbar zu machen, aber dafür müsste man wissen, wie sich diese Wahrscheinlichkeit für MM berechnet. Für jede searchengine ist das anders.
Ich probiere erstmal irgendeine Wahrscheinlichkeit aus, damit die Pipeline durchläuft.
Ich habe die vermutung, dass sie die wahrscheinlichkeit für einen Treffer wie folgt berechnet: …… (nein doch nicht) aber -ln(e^-x) scheint eine gute Näherung zu sein.

2012-04-05 Thu 13:50

Ich denke, ich kenn nicht weiter effektiv programmieren, bevor ich mich wieder feedback von Chris bekommen habe.
Werde heute versuchen etwas für den Textteil zu machen.

2012-04-07 Sat 16:51

Schreibe weiter den Text.
Habe mir als Vorbild die Arbeit von Hannes Hauswedel rausgesucht und habe bemerkt, dass es dort kein abstract gibt, sondern gleich eine relativ aufführlichen Einleitung. Ich versuche auch so eine Einleitung zu schreiben.

2012-04-09 Mon 16:03

habe jetzt die erste Pipeline mit ConsensusID inkl. OMSSA und MM, die komplett durchläuft. Silvesterstimmung.
werde jetzt versuchen die score formell für MM empirisch zu ermitteln

2012-04-11 Wed 23:43

habe in aufwendiger art und weise meinen branch ausgecheckt und merge jetzt sauber meine veränderungen rein.

2012-04-13 Fri 16:46

bereite jetzt die daten und die datenbank für die endgültige auswertung vor
uniprot und cRAP zusammenfügen und dann noch reverse bilden
muss vor der suche noch PepXML anpassen
habe mir die parameter für die suche angeschaut und bin froh, dass es nur eine variable modifikation gibt.
habe beim ausführen auf andorra bemerkt, dass "myrimatch" als executable nicht so cool bei der versionsprüfung ist

2012-04-15 Sun 11:57

mache jetzt weiter. räume meinen lokalen ordner auf und probiere das ganze nochmal auf meinem rechner lokal aus.
Habe die Pipeline jetzt noch angepasst, sodass im MMAdapter die richtigen Paramter stehen
Muss noch dran denken meinen Code zu refactorn
wie war das nochmal mit dem Plotten der Verteilung?
werde jetzt das arbeitsverzeichnis auf einen tmp ordner setzen
habe in der theorie rausgefunden, wie das geht, aber das funktioniert immernoch nicht.

2012-04-16 Mon 13:24

habe nochmal alle suchen laufen lassen und alle möglichen dateien, die im Verlauf durch MM und OMSSA entstehen zur Untersuchung gesichert.
Werde das jetzt so einrichten, dass statt des xcorr, der mvh wert bei MM eingetragen wird. Das ist erledigt.

2012-04-19 Thu 18:30

Silversterstimmung. Lasse jetzt den MyriMatch QProcess nicht mehr mit der statischen execute() funktion laufen, sonderm mit start(). bool success ist nicht true, scheint aber zu funktionieren. Muss noch debuggen, warum nicht true.
Habe bei IDPost… return hit.getScore() eingetragen. Der zugehörig Plot sieht traumhaft aus.

2012-04-20 Fri 10:44

benchmarke jetzt die drei engines (XTA,MM,OMSSA), doch der ConsensusID score ist am schlechtesten. Vermute, dass das an MyriMatch liegt. Werde mal MM rausnehmen.
habe jetzt eine sehr große Pipeline gebastelt, und die sachen schauen ganz gut aus, sind aber nicht die erwarteten ergebnisse. Es schaut so aus, als würden die MM und die X!Tandem ergebnisse alles runterziehen. Versuche X!Tandem zu installieren, funktionier aber nicht.
Versuche jetzt X!Tandem auf andorra laufen zu lassen.
Das hat gut funktioniert
Hatte heute auch ein Treffen mit Chris mit viel Input. Werde die Vorschläge als nächstes umsetzen.

2012-04-21 Sat 16:43

[X] working directory für den QProcess richtig setzen
[X] Suchparameter anpassen
- [X] Generell: charge von 2-6 (außer bei X!Tandem)
- [X] Suchparameter MM: Mods stimmen nicht (von OMSSA übernehmen)
- [X] ConsensusID: RT und MZ deltas von 0.01 benutzen
[X] die ppm vs. Dalton flags als StringList mit "ppm,Da" machen.
[X] Da ich bein mir X!Tandem nicht installieren konnte: ein Skript schreiben, dass X!Tandem über ssh auf eine Unirechner laufen lässt und die Ergebnisse dann runterlädt.
Habe festgestellt, dass die ini-Datei für X!Tandem andere PTMs hatte, als bei den anderen engines. Passe das an.
- Update: habe mich getäuscht.
Problem: Für die neuen einstellungen reichen mein Arbeitsspeicher nicht aus. Die OMSSA Berechnung dauert ewig. Werde das auch auf den Unirechnerauslagern.
Habe jetzt die Ausführung von OMSSA und XTANDEM auf Unirechner ausgelagert. Geht jetzt wesentlich schneller. Leider auch etwas mehr Aufwand beim Arbeiten und dadurch mehr fehlerquellen. Die ini files der engines bearbete ich jetzt erstmal per hand.
Die Ergebnisse machen immernoch wenig Sinn. Das schlechteste Ergebnis liefert bei mir die Kombination aus X!Tandem und OMSSA. Werde jetzt die ini file der beiden vergeleichen. Ich nehme an, dass das Problem in den Einstellungen zu finden ist.
habe jetzt bei tandem.ini folgendes geändert:
- precursor_error_unit => Da
- precursos_mass_tolerance von 10 nach 0.01
- minimum_fragment_mz von 150 nach 4
habe bei myrimatchadapter geändert:
- NumChargeStates von 3 zu 5
unklar: cleavage_site bei XTandem
die grösste Merkwürdigkeit: XTandem und OMSSA Ergebnisse vertragen sich sehr schlecht. Während OMMSA allein das beste Ergebnis überhaupt liefert und XTandem auch nicht schlecht abschneidet, so liefert die Kombination der beiden mit ConsensusID das schlechteste Ergebnis von allen. Ich schätze ich habe etwas falsch eingestellt. Werde versuchen noch eine weiter engine einzufügen. (Mascot)
Es sieht so aus, als wäre Mascot proprietär und mein Budget lässt im Augenblick keine weiteren Ausgaben zu… (wo ich nichtmal den Preis finden kann)

2012-04-22 Sun 12:58

Habe jetzt den MzXMLHandler und den MzDataHandler angepasst. Jetzt wird MSNSPECTRUM Tag richtig gesetzt.
Damit ist das alte Problem, dass MyriMatch von OpenMS generierte mzMLs nicht akzeptiert und behauptet da wäre 0 Spektren, vom Tisch.
Bei MzData gibts noch eine unklarheit, über die Chris noch nachdenken muss.
Die Einheit für die *_mass_tolerance parameter kann jetzt bequemer eingestellt werden.

2012-04-23 Mon 11:39

Habe IdXMLs nach search engine und IDPostErrProb an Sven geschickt und schon eine Antwort bekommen. Bei ihm sieht das Ergebnis nach ConsensusID gut aus. (für OMSSA und XTandem)
Bei mir sieht der ROC Plot für XTandem und OMSSA jetzt auch gut aus. Habe einen Fehler gefunden, der zu peinlich ist, als dass ich je dovon berichten könnte. :p
Laut Sven muss ich jetzt noch das Posterior error prob modeling anpassen.
Es sieht so aus, als würde nichts vernünftiges aus dem IDPostErrProb für MyriMatch rauskommen. Ich werde da noch ein wenig rumprobieren und auch die anderen Fragen, was man da machen könnte.

2012-04-24 Tue 08:19

Habe ein Paper zu PEP-Score gelesen und werde jetzt versuchen nachzuvollziehen, warum die Berechnung für MyriMatch nicht vernünftig klappt.
Halte fest: Die Anpassungen der Parameter, die in der Hoffnung vorgenommen wurden die Ergebnisse zu verbessern sind wahrscheinlich nicht nötig. Das Problem lag darin, dass ein Paramter durch den Adapter nicht richtig übersetzt wurde.
Jetzt schaut der ROC Plot von MyriMatch realistisch aus, aber MM in Kombination mit anderen sieht zu gut aus, um wahr zu sein.
Ich vermute jetzt, dass es ein Problem mit der target/decon Annotation ist.

2012-04-25 Wed 18:09

Meine Vermutung war richtig: myrimatch erstellt selbst eigene decoys, was es nicht tun sollte und was ich eigentlich auch abgestellt hatte. So dachte ich. Versuche das jetzt zu reparieren.
Habe MM jetzt auch ohne den Adapter ausgeführt und muss feststellen, dass die automatische Erstellung von Decoys sich nicht wie beschrieben abstellen lässt. Ich versuche im MM Code nachzuvollziehen, was man dafür wirklich tun muss.
Habe mir den MyriMatch Quellcode geholt und so neu kompiliert, dass da sicher keine decoys erstellt werden. Das hat auch funktioniert. Leider passt das Suchergebnis dann trotzdem nicht. Myrimatch wird gar nicht in den ROC Plot gezeichnet. Ich nehme an, weil die Ergebnisse zu schlecht sind, sodass sie aus der Skala fallen. Muss das aber noch überprüfen.

2012-04-30 Mon 16:53

Folgender Zwischenstand: Haben mit Chris manuell ein neues fasta File erstellt, bei dem die decoys mit einem prefix gekennzeichnet sind, womit MyriMatch vernünftig umgehen kann.
Bei einem erneuten Durchlauf sind die Ergebnisse der Suche jedoch wieder zu schön um wahr zu sein. Ich schätze es passt wieder etwas mit den decoys nicht.
Haben ferner MzData angepasst, sodass es den MSNSPECTRUM Tag richtig behandelt.(glaube ich)
Mir ist eingefallen, dass ich die Suchergebnisse von Omssa und XTandem wiederverwendet habe. Natürlich muss ich diese Suche jetzt für die neue Datenbank wiederholen.
Und tatsächlich: Ich habe in einem IdXML File peptide gefunden mit dem rev_ prefix und dem _rev suffix. Lasse das ganze nochmal auf den Unirechnern laufen.
Um es nochmal festzuhalten: Bei MyriMatch lässt sich die automatische decoy Generierung nicht abstellen. Laut Doku müsste das gehen, geht aber nicht. Wenn die Datenbak aber schon decoys enthält, die mit dem rev_ Prefix gekennzeichnet sind, dann nimmt MM das so hin und erstellt keine weiteren Decoys. Das hat dazu geführt, dass ich die ganze Pipeline dafür anpassen musste. Warte jetzt gespannt auf die Ergebnisse der neues Suche.
Leider sieht die MM Suche, im vergleich zu den anderen engines, verdächtig schlecht aus. Der Grund dafür ist auch noch zu finden.

2012-05-02 Wed 16:23

Hatte noch eine Besprechung mit Chris und wir hatten die folgende Erkenntnis: In den Ergebnisse von MM(A) tauchen zu einem Messpunkt mehrere Peptide Hits auf. Das erklärt meiner Meinung nach auch die Anomalie in den aktuellen ROC Plots. Wenn das ausgebügelt ist, dann könnte die Plots endlich realistisch aussehen.
Bei MyriMatch ließ sie die automatische Erstellung von Decoys nicht abstellen, jedoch habe ich das bis jetzt nur über die Kommandozeile probiert. Mir ist die Idee gekommen, das gleiche nochmal über eine myrimatch.cfg zu probieren. Vielleicht tritt so dieser Bug nicht auf.

2012-05-02 Wed 20:30

Nach langem Suchen meine ich jetzt zu wissen, was los ist. MyriMatch erstellt für jeden assumed_charge, für den es einen Treffer gab, im pepXML einen eigenen spectrum_query tag. OpenMS erstellt für jeden spectrum_query tag einen eigenen PeptideIdentification tag. Das führt dazu, dass für ein Spektrum mehrere PeptideIdentification ins idXML eingetragen werden, die von da an als seperate Treffer gelten.

2012-05-03 Thu 00:10

Habe PepXMLFile jetzt so angepasst, dass spectrum_query tags mit der gleichen scan nummer zusammengefasst werden. Ob das so okay ist, muss ich noch mit Chris besprechen, aber der ROC Plot für MyriMatch schaut jetzt traumhaft aus, nämlich sehr ähnlich zu dem von XTandem.

2012-05-03 Thu 09:04

Die ConsensusID Plots bei denen MyriMatch dabei ist, schauen immernoch zu gut aus. Wenn ich mir die Ergebnisse in TOPPView anschaue, so sieht das so aus, als würden eigentlich gleiche Treffer bei MM und bei OMSSA bei verschiedenen RTs verbucht, was zu mehr treffern führt. Wenn ich mich nicht täusche, so war ein Verbesserungsversuch vor ein Paar Wochen die rt_delt bei ConsensusID runterzusetzen. Ich werde den Testaufbau jetzt wieder auf den Stand bringen, auf dem er ganz am Anfang war. Also auch die Ladungszahl veringern.
Das hat nichts gebracht. Versuche jetzt den charge predictor anzupassen.
versuche es mit OMSSA Paramter zcc=1
- hat das Ergebnis von OMSSA und den ConsensusID mit OMSSA deutlich verbessert.
Problem: FalseDiscoveryRate kann nur mit Suffixen zur markierung von Decoys umgehen. :'(
Das sollte aber kein Problem sein, wenn ich dem PeptideIndexer vor FDR eine Datenbank gebe, wo die entsprechenden Peptide mit einem Suffix markiert sind. Eine geniale Idee!

2012-05-03 Thu 17:08

Habe eine neue pipeline gebaut, in der die eigentlichen Suchen nicht durchgeführt werden. Erhoffe mir jetzt ein Zeitersparnis, da ich nur selten die Suchen wirklich wiederholen muss und sie die mich die meiste Zeit kosten.
Habe Untersucht, warum die Consensus Scores mit MyriMatch Beteiligung so gut sind und habe festgestellt, dass fast jeder Treffer als Zwillingspaar in ca. 2 Sekunden retention time von einander auftaucht. Dadurch werden die Treffer von MyriMatch und z.B. OMSSA als verschiedene Treffer gewertet, selbst wenn es der selbe Messpunkt ist. Wenn nun jeder hit doppelt gezählt wird, dann gibt es nun bei gleicher FDR nun die Summe von den target Treffern von MM und OMSSA.
Schaue im PepXMLFile.C nach wie die retentiont times ausgelesen werden.
Probiere ConsensusID mit einem rt_delta von 3 Sekunden auszuführen.
Hat nichts gebracht, es tauchen trotzdem Zwillingspaare mit 2 Sekunden Abstand auf. Entweder versteh ich den rt_delta Parameter falsch, oder die Einheit ist nicht Sekunden. UPDATE Hat doch was gebracht. Die Zwillingspaare sind in TOPPView nicht mehr zu sehen.
Aber der ROC Plot schaut sehr gut aus!!!! Wegen rt_delta=3 ist er zwar vielleicht noch verfälscht, aber wenn die tatsächliche Wahrheit so ausschaut, dann wäre das ein sehr gutes, aber auch ein realistische Resultat für ConsensusID(MM+OMSSA).
Stelle das rt_delte jetzt auch für die anderen Kombinationen ein. Es ist besonders interessant, wie sich das auf die XTandem+OMSSA Kombo auswirken wird. Dort reicht ja ein rt_delta=0.1
Die ROC Plots von ConsensusID(OMSSA,XTandem) mit rt_delta=0.1 und rt_delta=3 unterscheiden sich nur durch wenige Pixel. rt_delta=0.1 ist minimal besser.
Ich bin also guter Dinge, dass die (wirklich guten) ConsensusID Ergebnisse mit MyriMatch jetzt endlich korrekt sein könnten. Das ist natürlich noch zu prüfen und der Grund für die RT Verschiebung zu finden. Ich bin guter Dinge!
Es macht mich stutzig, dass MM+Xtandem besser ist als OMSSA+XTanden, obwohl OMSSA allein viel bessere Scores hat, als MM. Ich probiere das nochmal mit einem rt_delta=4
rt_delta=4 hat die ConsensusID Ergebnisse ein wenig nach unter verschoben. Schaut jetzt auch realistisch aus.
Für heute genug.

2012-05-04 Fri 00:00

Vergleich der Zeiten
- im mzML 151.88928333333334 Minuten
- im Myri IdXML 9111.7358 Sekunden
- im OMSSA IdXML 9113.357 Sekunden
- Laut Wolframalpha: 9113.357 Sekunden
Feststellung: Die umrechnung aus der Minutenzahl in der mzML in Sekunden ist fehlerhaft bei PepXMLFile(?).

2012-05-04 Fri 10:19

habe jetzt plots für rt_delta gleich 3,4,5 und 6 erstellt.
- von 3 zu 4 sieht man einen großen Unterschied. Bei 4 sind die Ergebnisse deutlich "schlechter". Es werden wohl mehr sinnlose Zwillingstreffer zusammengefasst.
- von 4 zu 5 ändert sich nur sehr wenig
- von 5 zu 6 änert sich defacto nichts.
Das alles dürfte uninteressant werden, sobal die retention times richtig berechnet werden.

2012-05-04 Fri 16:25

In der Besprechung mit Chris haben wir festgestellt, dass in PepXMLFile die retention time vom precursor und nich vom fragment eingetragen wurde. Das ist jetzt korrigiert und die ConsensusID scores mit MyriMatch schauen jetzt auch mit rt_delta=0.1 gut aus.
Jetzt, wo es so aussieht, dass der Adapter seine Funktion erfüllt bleibt mir noch den Quellcode zu refaktorn und hübsch zu machen und usabilty zu verbessern. Mache dazu eine todo liste.
Dann bleibt das Schreiben des Textes und Erstellen von Grafikenfür die Arbeit.
Wenn noch Zeit ist, dann werde ich noch einen Adapter für InsPecT schreiben. Wenn es aber vergleichbar viele Probleme damit gibt, wie mit MyriMatch, dann dürfte es schwer werden das noch hin zu bekommen. Ich werde es aber versuchen.

2012-05-04 Fri 18:44

Versuche die Versionsprüfung zu verbessern. Jetzt wird der Adapter beendet, wenn die Versionsinformation nicht wie erwartet formatiert ist. Es wird dabei der EXIT_CODE EXTERNAL_PROGRAM_ERROR zurückgegeben. Wahrscheinlich sollte ich einen besseren EXIT_CODE raussuchen.
Habe die Übersetzung der Modifikationen von Unimod nach MM in eine Funktion ausgelagert. Jetzt sieht die main() deutlich aufgeräumter aus.
Bis jetzt hatte ich einen inkonsistenten Einrückungs-Stil, da die automatische Einrückung bei mir anders eingestellt war, als es bei OpenMS üblich ist. Jetzt habe ich das endlich umgestellt und jetzt schaut alles gleich aus.
Da fällt mir ein: was ist eigentlich die OpenMS Konvention für Warnungen und Fehlermeldungen? _writeDebug()?
Ich habe nun festgestellt, dass sich die automatisch decoy Erstellung bei MyriMatch deaktivieren lässt, wenn man den entsprechenden Parameter über eine .cfg Datei übergibt. Werde jetzt den MM Adapter so anpassen, dass eine temporäre .cfg Datei erstellt wird.
Das ist nun erledigt.
Wir hatten ja festgestellt, dass es keinen Sinn macht beim parsen der pepXML die RT des precursors in die idXML einzutragen. An der Stelle im Code passiert aber noch mehr, dessen Sinn sich mir nicht erschließt. Ist da vielleicht noch mehr überflüssig?

2012-05-07 Mon 13:27

Mache jetzt ein paar sinnlose Änderungen rückgängig. Insbesondere die Zusammenfassung von spectrum_queries und die Bestimmung der retention time.
Das hat hat nichts kaputt gemacht. Die Plots schauen immernoch so aus wie vorher.
Habe bei PepXMLFile eine Membervariable String search_engine_ eingeführt, damit beim Auslesen der scores der xcorr bei in der PepXML von MM ignoriert werden kann:
- if (name == "xcorr" && search_engine_ != "MyriMatch")

2012-05-07 Mon 20:04

Habe jetzt die Anzahl der zugelassenen variablen Modifikationen von 3 auf 6 erhöht. Wenn mehr angegeben werden, dann werden nur die ersten 6 benutzt und eine entsprechende Meldung ausgegeben.
Noch ein paar Parameter des Adapters angepasst, also z.B.
- MonoisotopeAdjustmentSet
- threads
Habe in TOPPBase.h versucht bessere EXIT_CODEs zu finden. Festgestellt: ich hatte schon die besten. :p
commite jetzt den Zwischenstand

2012-05-10 Thu 17:24

Jetzt wo der Programmierteil meiner Arbeit praktisch fertig ist, widme ich mich dem Textteil der Arbeit. Werde jetzt mein Vorgehen planen.
Habe eine grobe Gliederung für die Arbeit erstellt und zwar grob so, wie bereits besprochen.
Werde jetzt meine Einleitung neu schreiben, unter Berücksichtigung der Kommentare von Chris.
Frage: woher zitiere ich Definitionen von z.B. 'Proteomics'?

2012-05-22 Tue 17:27

Kurzes Update: Ich bin jetzt nur noch mit den schreiben des Textteils beschäftigt. Es gibt also nichts zu berichten.

2012-05-23 Wed 10:27

habe von Chris neue Daten bekomme und werde jetzt die entsprechende Pipeline bauen.

Datum: 2012-06-20 12:14:32 CEST

Autor: Dimitri Schachmann

Org version 7.6 with Emacs version 23