konvergieren

Cæ|si|um  〈n.; –s; unz.; Chem.; Zeichen: Cs; fachsprachl.〉 = Cäsium

Maul|brü|ter  〈m. 3; Zool.〉 Fisch mit meist hochentwickelten Brutpflegeinstinkten, bei dem die Jungen im Maul als Brutraum schlüpfen u. bei Gefahr auch wieder in das Maul aufgenommen werden: Cichlidae

Kurz nach Start des Blogs erschien in Nature der Aufruf zur “Ten Years Reproducibility Challenge”. Ich habe darüber berichtet und auch zugegeben, dass bei eigener Software nicht immer gut um die Frage nach der Lauffähigkeit nach langer Zeit bestellt ist.

Inzwischen gibt es bereits einige Rückläufer in Form von Veröffentlichungen zu einer ausgewählten Software, die beschreiben in welchem Rahmen Reproduzierbarkeit auch nach > 10 Jahren funktioniert oder nicht – und wenn nicht: warum?

Was ist der Beitrag von Software zu Reproduzierbarkeitskrise?

Zuvorderst steht die Frage im Raum, ob die Ergebnisse, die mit einer Software X auch nach Ablauf von zehn oder mehr Jahren wieder erzielt werden können? Diese Frage ist interessant, weil so enorm viele wissenschaftliche Ergebnisse in der einen oder anderen Form von Software abhängen. Was also ist, wenn die Software von heute in zehn Jahren ihre Ergebnisse nicht mehr reproduzieren kann: Ist dann auch das Ergebnis von heute nicht mehr reproduzierbar? Dies ist selbstverständlich nur ein Aspekt der “Reproduzierbarkeit” – nicht unbedingt im Sinne von “wahrscheinlich ungültige” Resultaten.

Für das “Versagen” der Software von damals kann es eine Reihe von Gründen geben, die uns heute eine Lehre sein können. Alter Code funktioniert kann heute nicht mehr, weil

• … die Prozessoren andere sind (letztens wollte ich ein statisch kompiliertes 32bit Programm auf aktuellen CPUs ausführen, ohne das ich vorher hin geschaut hätte, geht so natürlich nicht – neu kompilieren hatte bei den obskuren Abhängigkeiten ebenfalls keine Chance; ein anderes Beispiel wäre Code, der zu empfindlich ist bei kleinen numerischen Störungen und mit der größeren Genauigkeit heutiger CPUs nicht klar kommt)
• …  sich die benötigten Softwarebibliotheken nicht mehr installieren lassen (und niemand vor zehn Jahren an das Archivieren von Containern oder VMs gedacht hat*)
• … sich die benötigten Softwarebibliotheken zu stark geändert haben (und niemand vor zehn Jahren an das Archivieren von Containern oder VMs gedacht hat und die alten Veröffentlichungen/Releases nicht mehr zur Verfügung stehen)
• … sich niemand Gedanken über eine gute Installationsroutine Gedanken gemacht hat (und heute niemand das Gefrickel von vor zehn Jahren nachvollziehen kann)
• … sich niemand die Mühe Gemacht hat gut zu dokumentieren wie man die Software richtig anwendet (bei alter wissenschaftlicher Software nicht selten)
• … etc. etc. etc.

Kommt das Alles nicht mehr vor? Sind die wissenschaftlichen Communities klüger geworden und haben aus den Fehlern gelernt? Ich glaube bereits vermittelt zu haben, dass einige der Probleme von damals heute noch sehr aktuell sind.

Eine unterhaltsame Beschreibung eines bunten Problemstrausses habe ich in einem anderen Blog gefunden. Um es vorweg zu nehmen: Die Wiederholung für dieses verlinkte Beispiel hat einigermaßen gut funktioniert. Aber die entscheidenden Punkte sind:

1. 1. 1. es ging nicht um ein 0815-Paper in einem low-impact Journal, sondern um einen potentiell relevanten bioinformatischen Beitrag^{[Lamichhane et a., 2003]}.
      2. der Code von damals war “natürlich” nicht versioniert (vgl. mein Beitrag, der das auch beleuchtet).
      3. zu wenig, von dem was zur Nutzung zu wissen ist und was durchgeführt wurde, war dokumentiert. Nur der damalige Autor konnte das nachvollziehen.
      4. die Abhängigkeiten zu best. Softwarepaketen waren nicht transparent.
      5. Code, der nur dem ursprünglichen Autor irgendetwas sagen könnte und selbst der bekennt nun geraten zu haben, als es um den Versuch ging das wieder zum Laufen zu bringen (R-Code):

         temp <- negenes(mydata[,1], mydata[,2], mydata[,3], mydata[,4], n.mcmc=50000, skip=49, return=TRUE, trace=FALSE)
         

Das ist selbstverständlich nur ein Beitrag. Nicht repräsentativ. Doch wenn Ihr Euch mal weitere Veröffentlichungen der “Ten Years Reproducibility Challenge” anschaut, die oben verlinkt sind und wenn ich meine eigene Arbeit betrachte, wo durchaus immer wieder von Nutzern Variablen “mydata” genannt werden, gute Kommentare im Code Mangelware sind und man sich häufig durch Code wühlen muss um zu erfahren, was die eine bestimmte Funktion so für ein Hobby hat, weil jedwede Doku fehlt … da kommt man um die Befürchtung “Das ist vielleicht nicht repräsentativ, aber doch ein nicht von der Hand zu weisendes Problem!” nicht umhin.

Ich erlaube mir mal zwei Zitate aus den bioinformatischen Themen in Re-Science:

• After some minor corrections and modifications of the original description of the model, we were able to reproduce the original results, confirming the correctness of the original implementation of the model.^{[Topalidou and Rogier, 2015]}

• … In general, the original model is easily implemented. … However, in some experimental protocols important information is missing^{[Detorakis, 2016]}

Und so geht es weiter … den Rest erspare ich Euch. So weit ich lese, steht da überwiegend: “Wir/ich habe(n) die alte Software irgendwie ans Laufen gebracht. (Oft erfolgreich, manchmal nicht.)” Oder anders gesagt: Die Welt aller möglichen Anwender hätte wohl erhebliche Schwierigkeiten und würde meist scheitern.

Spätestens jetzt sind einige Kommentare provoziert: “In meinem Metier … Und bei uns im Betrieb … ist das anders.” Ja, da mag das “anders” sein und doch ist das irrelevant: Hier geht es um wissenschaftliche Software, mit der Ergebnisse “produziert” wurden. Diese wurden veröffentlicht, die Veröffentlichung als gegebenes Resultat zitiert und diskutiert. Wenn nun jedoch diese Software bereits die (Simulations)-Ergebnisse manchmal nicht und häufig nur in den Händen der Schöpfer funktioniert, dann können die Ergebnisse von Dritten nicht nachvollzogen werden und sind somit definitionsgemäß nicht reproduzierbar. Manche der damals getroffenen Aussagen sind sicherlich im Sinn der damals getroffenen Aussagen gültig – aber für mehr als “Im Zweifel für die Autoren” reicht es nicht.

Andererseits …

… geht es bei der “Ten Years Reproducibility Challenge” vielfach nicht um produktiv eingesetzte Software. Software also, die wieder und wieder in der bioinformatischen Datenanalyse Verwendung findet. Ist damit das Problem des Beitrags zur Reproduzierbarkeitskrise entschärft? In gewisser Weise: Ja, weil vermuten dürfen, dass die vielen Softwarepublikationen und Publikationen, die auf Software basieren nur deshalb nicht reproduzierbar sind, weil niemand die fragliche Software dokumentiert findet und oder installieren kann. Leider hilft selbst dieser Zynismus nicht weiter, denn Publikationen mit Software fragwürdiger Qualität sind immer noch nicht selten.

Und doch, der nächste Artikel wird zeigen: Alte Software ist ein Problem. Und zusammen mit fehlender Info (wie Workflow-Beschreibungen) in wirklich relevanten Veröffentlichungen ein großes …

+++++++++

• Nicht, dass ich behaupten möchte durch Archivieren virtueller Maschinen (VMs) oder Containern das Problem lösen zu können, aber die Mode ist z. Zt. hartnäckig.

https://scienceblogs.de/rupture-de-catenaire/2020/10/21/zutaten-zur-reproduzierbarkeitskrise-5-alternde-software/?utm_source=rss&utm_medium=rss&utm_campaign=zutaten-zur-reproduzierbarkeitskrise-5-alternde-software