Zusammenfassung der GP2-Richtlinien zur Code-Standardisierung des Global Parkinson's Genetics Program

Generell gilt beim Global Parkinson’s Genetics Program (GP2) der Grundsatz „keine Überraschungen“. Analysen, Projekte und Manuskripte werden offen und transparent untereinander koordiniert und kommuniziert. GP2 möchte, dass die Daten und der Code so weitreichend und frei wie möglich genutzt werden, und fordert eine Standardisierung des Codes in allen Analyseteams. Für alle GP2-Mitglieder und externen Nichtmitglieder, die Analysen mit GP2-Daten durchführen, betont GP2 die Notwendigkeit eines sauberen, organisierten und replizierbaren Codes, welcher der wissenschaftlichen Gemeinschaft frei zugänglich ist. Der Code muss den Standardisierungsleitlinien entsprechen, GP2 ist zu nennen und der Code wird der Gemeinschaft über GitHub zur Verfügung gestellt.

Einführung

Das Global Parkinson’s Genetics Program (GP2) ist ein internationales Vorhaben zur Erlangung signifikanter Erkenntnisse hinsichtlich der genetischen Grundlagen der Parkinson-Krankheit und zur Demokratisierung des Zugangs zu den entsprechenden Ergebnissen und Daten. GP2 wird von der Initiative „Aligning Science Across Parkinson‘s“ ( ASAP ) finanziert und ist Teil der strategischen Ziele dieses Programms, die Zusammenarbeit zu unterstützen, Ressourcen zu generieren und Daten zu demokratisieren. Die Verbreitung von GP2-Code und -Daten gehört zu den wichtigsten Zielen von GP2, und ASAP unterstützt die weitreichende, schnelle und freie Veröffentlichung von Ergebnissen.

Übersicht

Durch diese Richtlinien soll Folgendes gewährleistet werden:

1. GP2-Code und -Arbeitsschritte von unter Leitung des GP2-Forschungsverbundes durchgeführten Analysen werden vollumfänglich, korrekt und unverzüglich veröffentlicht.
2. GP2-Code und -Arbeitsschritte von unter Leitung des GP2-Forschungsverbundes durchgeführten Analysen sind standardisiert, organisiert und öffentlich auf GitHub verfügbar.

Die Code-Standardisierungsleitlinien ergänzen die Veröffentlichungsrichtlinien von GP2. Bezüglich der Klärung ungewöhnlicher Situationen durch den GP2-Forschungsverbund verweisen Sie bitte auf dieses Dokument.

Die Code-Standardisierungsrichtlinien beschreiben das Erfolgsmodell für die Standardisierung von Codes, welches für die vom GP2-Steuerungskomitee und dem GP2-Forschungsverbund geleiteten Analysen übernommen wird und die vom GP2-Forschungsverbund geleiteten Publikationen ergänzt. Externen Forscher*innen, die GP2-Daten verwenden, wird dringend nahegelegt, diese Methoden ebenfalls anzuwenden, um hochkarätige Analysen und Open Science, also frei zugängliche Forschungsergebnisse, zu gewährleisten. Da sich Python/Jupyter anstelle von R für Analysen in unserem Bereich immer mehr durchsetzen, liegt auch in diesem Dokument der Schwerpunkt auf Python. Uns ist bewusst, dass viele GP2-Forscher*innen nach wie vor mit R oder anderen Tools arbeiten, und wir unterstützen auch weiterhin einen organisierten, frei zugänglichen und replizierbaren Code innerhalb der GP2-Gemeinschaft.

Als weitere Motivation bedenken Sie bitte, dass das Bereinigen des Codes zwar mühsam ist, aber so wird GP2 seinen Code einrichten, und Sie sind aufgefordert, diese Standards ebenfalls zu befolgen. Ist der Code nicht sauber/klar und aus sich selbst heraus verständlich, stellt sich die Frage, ob er wirklich die gewünschte Funktion erfüllt. Sauberer Code bedeutet auch, dass später weniger Zeit aufgewendet werden muss, um Analysen und Konzepte wieder und wieder zu erklären – ein Gewinn für beide Seiten. Ein sauberer Code ermöglicht Replizierbarkeit und Transparenz.  GP2 ist dem Gedanken der Open Science (frei zugängliche Wissenschaft), der Zusammenarbeit durch Transparenz des Codes und der Inklusivität verpflichtet.

Im Folgenden beschreiben wir einige grundlegende Informationen und Arbeitsabläufe in Bezug auf Python als primäre Programmiersprache, Anaconda als bevorzugte Python-Distribution, PEP8 als zu verwendende Python-Programmierstruktur, die Speicherung in der Google-Cloud-Umgebung und die Durchführung von Analysen in der Cloud-Umgebung von Terra. Wichtig ist es ferner, für jede Analyse ein so genanntes README-Dokument mit einer übersichtlichen Darstellung von Arbeitsabläufen und Zielsetzungen zu haben. Nach diesen Standards arbeitet GP2 und hofft, dass sie auch in der Wissenschaftsgemeinde generell eingehalten werden.

Zunächst einige grundsätzliche Anmerkungen zu Python und zum Programmieren im Allgemeinen.

• Sämtliche computergestützten Analysen für GP2 erfolgen zumeist in Terra, The AnVIL von NHGRI oder ähnlichen cloud-basierten Systemen.
  • Für Projekte oder Gruppen mit begrenzten logistischen bzw. finanziellen Möglichkeiten bieten wir analytische und finanzielle Unterstützung.
• Python3+ ist für GP2-Analysen die Haupt-Programmiersprache, für R und andere Programmiersprachen gibt es in begrenztem Umfang ebenfalls Unterstützung. Dadurch kann der aktuelle Code-Bestand der LNG Data Science Group des National Institute on Aging besser genutzt werden.
• Um das Arbeiten mit Terra zu lernen, richten Sie sich ein AMP-PD-Konto ein. Das bietet einen guten Einstieg.
  • Dort gibt es hervorragende „Getting Started“-Materialien (wo Sie programmieren und den Code ausführen können) sowie Arbeitsbereiche und Daten, die Sie nutzen können.
  • Die „Getting-Started“-Dokumente auf Terra.bio sind auch sehr gut.
• Um Python in zwei Wochen wirklich gut zu lernen…
  • Gehen Sie dies einmal täglich durch.
  • Gehen Sie dies einmal pro Woche durch (von unseren Freunden bei der NSA via FOIA).
  • Google Colabs bietet außerdem mit geringem Aufwand und Stress die Möglichkeit, die Notebook-Struktur zu erlernen und sich mit Python vertraut zu machen ( Notebooks in Drive anzeigen ).
• Ein guter Code ist einfach, klar und verwendet eine standardisierte Grammatik – gewissermaßen wie ein Rezept.
  • Google Style Guides sind ein guter Ausgangspunkt.
  • PEP8 ist die bevorzugte „Grammatik“ für Python.
  • Visual Studio Code ist bei GP2 der bevorzugte Editor, da es dort Erweiterungen für die Standardisierung des Programmierstils gibt. Arbeiten Sie aber einfach mit dem Editor, in dem Sie sich am wohlsten fühlen.
• Die Hauptsprache des Support-Teams ist Python3. Wenn Sie die gleichen Tools verwenden wie wir, können wir sowohl Tools mit Ihnen teilen als auch Ihre Projekte viel effizienter unterstützen.
  • Alle internen Bausteine für Tools und Programmierung sind in Python3.
  • Gemeinsam genutzte GP2-Ressourcen sind für die große Mehrheit der Projekte in Python3.

Anaconda/Python für die lokale Nutzung herunterladen

• Wenn man lokal in Python programmiert, ist es wichtig, mit der Anaconda-Distribution zu arbeiten, um eine vollwertige Python3-Umgebung sicherzustellen. LNG hat eine Anleitung zur Einrichtung von Anaconda zusammengestellt. Das Dokument finden Sie hier.

Wichtigste Punkte und Übersicht

• Sie müssen über eine Methode zur Kontrolle der Version verfügen, um Programmierunfälle zu vermeiden. Man kann sich das wie eine Art elektronisches Laborbuch vorstellen. Das GP2-Projektlabor hat seinen eigenen GitHub für zukünftige Arbeitsabläufe. Hier ist getreu dem GP2-Motto alles öffentlich zugänglich.
  • Wenn etwas noch nicht bereit ist für die Öffentlichkeit, ist das auch in Ordnung! Erstellen Sie ein privates Repository und wenn der Code vollständig ist, haben Sie die Möglichkeit, ihn an einen öffentlichen Ort zu verschieben.
  • Bei GitHub sind Versionskontrolle und Zusammenarbeit sehr einfach, besonders mit der neuen Desktop-Oberfläche. Weiterführende Dokumentation zur Einführung findet sich hier.
• Es ist unerlässlich, eine README-Datei zu erstellen. Über unsere READMEs kommunizieren wir nicht nur mit anderen, sondern sie sind auch Dokumente, die ständig geändert werden. Folgende Informationen sind dort aber immer enthalten:
  • Autoren, Mitwirkende, Projektname, Projektzielsetzung, vorgeschlagene Arbeitsabläufe für Analysen, Startdatum, Datum der letzten Aktualisierung, Arbeitsverzeichnispfade, Dateipfade
  • Ein kostenloser und hervorragender Markdown-Editor zur Erstellung von README-Dateien ist stackedit.io
• Das GP2-Analyseteam arbeitet gemeinsam in Google Colabs an experimentellen Proof-of-Concept-Codes, um die kostenlosen GPUs zu nutzen sowie bei Bedarf in der lokalen Jupyter-Umgebung Inhalte einfach teilen und ändern zu können.
• Generell gilt, wenn eine Gruppe von mehr als 2 oder 3 Personen gemeinsam an einem Projekt arbeitet, wird eine Versionskontrolle benötigt.
• Bevor ein Projekt bzw. Manuskript mit dem GP2-Netzwerk geteilt wird, ist eine Versionskontrolle und eine Art von transparenter und verständlicher Programmierressource erforderlich.
  • Dieser Code wird vor der Freigabe zur Veröffentlichung geprüft, wenn GP2-Ressourcen in Form analytischer oder finanzieller Unterstützung genutzt wurden.

Code organisieren

• Eine Möglichkeit, wie man seinen Code organisieren kann, wird hiererklärt.
  • Auf dieser Seite wird behandelt, wie man Funktionen und Module erstellt oder anderweitig seinen Code gut gliedern kann.
  • Ihr Code muss sich nicht nach diesen Vorgaben richten, wenn Sie sich damit nicht wohlfühlen, aber er sollte in irgendeiner Form intuitiv nachvollziehbar organisiert sein.
  • Betrachten Sie Ihren Code als Teil Ihres Manuskripts. Wenn ein Gutachter Ihr Manuskript nicht versteht, wie soll es dann den Open-Science-Standards von GP2 standhalten? Das Gleiche gilt für den Code.
  • Zwar gibt es bei GP2 für die Programmierung keine starren Formatvorgaben, aber bemühen Sie sich bitte unbedingt, klar zu strukturieren.

Code-Standardisierung in Python

• Wir befolgen so genau wie möglich (Python Enhancement Proposal) für das Programmieren in Python die PEP8-Standards. PEP8 ist ein Dokument, in dem beschrieben wird, wie man am besten in Python programmiert, um einen besser lesbaren und konsistenteren Code zu produzieren.
  • Umfangreiche, aber zugleich gut verständliche Informationen dazu finden sich hier.
  • Die meisten integrierten Entwicklungsumgebungen (IDEs) verfügen über ein Plugin, das die Einhaltung dieses Standards unterstützt.
    • Ein Beispiel hierfür ist das autopep8-Plugin von Visual Studio Code.
• In Notebook-Dateien haben wir Vorlagen für Textbausteine, die wir verwenden, um uns selbst und die Nutzer*innen daran zu erinnern, welche Motivation hinter den Projekten steht. Beim Arbeiten mit Notizbüchern ist Markdown sehr nützlich, um Nutzer*innen Orientierung zu bieten und zu dokumentieren, was ausgeführt wurde.
  • Hier ist unsere aktuelle Textvorlage.
    • Man kann sie je nach Bedarf anpassen.
    • Der allgemeine Rahmen sollte für einen Code im Zusammenhang mit Projekten verwendet werden, die direkte Unterstützung von GP2 erhalten. Das sorgt für Übersichtlichkeit und hilft bei der Fehlerbehebung.

Bewährte Praktiken beim Arbeiten mit Cloud-Plattformen

• Als Teil von AMP-PD und wahrscheinlich auch für GP2 werden wir die PlattformTerra nutzen, um Analyse-Pipelines zu schreiben, zu optimieren und auszuführen.
  • Terra wurde durch das Broad Institute und das MIT entwickelt, setzt auf kommerzielle Cloud-Infrastruktur(en, Mehrfachoptionen) und bietet eine komplette interaktive Python3-Umgebung in Notebook-Struktur (die Jupyter sehr ähnelt).
    • Wenn man mit dem Cloud Computing noch nicht so vertraut ist, bietet Google hier eine hervorragende Einführung mit Erläuterungen zentraler Begriffe wie Projekt, Bucket, Container und anderer wichtiger Ausdrücke, die man für die weitere Arbeit beherrschen sollte.
    • Terra-spezifische Beispiele hat das AMP-PD-Team hier zusammengestellt.
    • Einige Grundlagen zum Umgang mit Dateien in der Cloud-Infrastruktur finden sich in diesem praktischen Spickzettel.
    • Die bewährten Praktiken von Google zur Benennung, Datenspeicherung und Datenverwaltung finden sich hier.
• Es gibt 2 entscheidende Unterschiede zwischen der Ausführung von Analysen lokal oder in der Cloud.
  • Lokal zahlen Sie selbst für den Speicher (entweder auf dem eigenen Computer oder im Cluster einer Institution), in der Cloud wird der Speicherplatz bezahlt (z.B. Durch AMP PD oder durch GP2)
  • Lokal bezahlen Sie nicht für die Ausführung von Analyse-Pipelines (bzw. Sie bezahlen zwar nicht auf dem eigenen Computer, aber je nach Institution wird für das Cluster bezahlt), während in der Cloud Nutzer*innen für jede ausgeführte Analyse bezahlen (etwa über ihre PIs oder Institutionen).
• Die AMP PD- und GP2-Analyseteams haben eine Reihe verschiedener Analyse-Pipelines geschrieben (Link), die optimiert werden können
  • Da man für die Umgebung, die man einrichtet, und die Datenmenge, auf die man zugreift, bezahlt, ist die bestmögliche Konzipierung und Planung der Analysen ein wichtiger Faktor.
    • Ein Beispiel für Laufzeit-Kosten zur Orientierung findet sich hier.
  • Die Cloud-Umgebung kann immer im Backend aktualisiert werden. Daher ist es wichtig, die Buckets, auf die man Zugriff hat, zu protokollieren und zu versionieren, um später direkt darauf verweisen zu können.
  • Sie bezahlen für die Umgebung, die Sie eingerichtet haben, sowie für die Nutzungsdauer. Halten Sie diese daher an oder löschen sie gleich ganz, wenn sie nicht genutzt wird. So bezahlen Sie nur für das, was Sie auch genutzt haben.

Zum Schluss ein Wort an unsere Freund*innen in den Nasslaboren

Transparenz, freier Zugang und Reproduzierbarkeit sind nicht nur Grundsätze der computergestützten Analysen. Wir empfehlen dringend Tools wie protocols.io oder ein Rocket Notebook zu verwenden, um Laboraufgaben und Experimente zu standardisieren. Sowohl die Arbeitsgruppe „Komplexe Krankheitsdatenanalyse“ als auch die Arbeitsgruppe „Daten- und Codeverbreitung“ von GP2 möchten vorgeschriebene Nasslaborpraktiken, die unsere Arbeit am rechnergestützten Ende des Spektrums widerspiegeln. Wir drängen auch darauf, dass die Praktiken der Probenbeschaffung- und -benennung online standardisiert und transparent sind, auch wenn dies nicht direkt in unseren Arbeitsbereich fällt.

Danksagung

In allen Manuskripten, Vorabdrucken und Abstrakts/Postern, die auf der Nutzung von GP2-Datenanalyse-Pipelines beruhen, müssen ASAP und GP2 in der Danksagung (Acknowledgements) in der nachfolgenden Form genannt werden:

„Der zur Vorbereitung dieser Pipeline verwendete Code wurde vom Global Parkinson’s Genetics Program (GP2) bezogen. GP2 wird von der Initiative Aligning Science Against Parkinson’s (ASAP) finanziert und von der Michael J. Fox Foundation for Parkinson’s Research ( MJFF ) umgesetzt. Eine vollständige Liste der GP2-Mitglieder finden Sie hier.

Die Michael J. Fox Foundation, ASAP und das GP2-Steuerungskomitee behalten sich das Recht vor, die Bedingungen aus dieser Vereinbarung zu ändern. Dies können sie tun, indem sie eine Mitteilung über derartige Änderungen auf dieser Seite veröffentlichen. Vorgenommene Änderungen gelten unmittelbar ab Veröffentlichung (sofern nicht anders angegeben). Sie sollten diese Seite regelmäßig besuchen, um die aktuellen Bedingungen der Nutzungsvereinbarung zu prüfen.

„Verhaltenskodex für Code-Programmierer*innen“

Bitte spiegeln Sie diesen konzeptionellen Rahmen für die Zusammenarbeit an Codierungsprojekten in GP2 wider.

 

Download