Über die Qualität der Software von Klimamodellen

Bild © Chris Frey

Unsere Kenntnis der Qualität von Software hinsichtlich von Klimamodellen ist theoretisch und konzeptionell vage. Der Unterschied zwischen Software von hoher und von geringer Qualität ist uns nicht klar; ebenso wie wir nicht wissen, auf welche Aspekte der Modelle oder des Modellierungsprozesses wir schauen müssen, um verlässlich hierüber Aufschluss zu bekommen.


Über die Qualität der Software von Klimamodellen: eine Analyse der Fehlergrenzen von drei Modellen

J. Pipitone und S. Easterbrook

Abstract: Ein Klimamodell ist eine Beschreibung der Theorie des Klimas; das Modell verwandelt klimatologische Theorien in Software, so dass die Theorien simuliert und ihre Implikationen untersucht werden können. Folglich muss man darauf vertrauen können, dass die Software, die das Klima beschreibt, das Klima korrekt abbildet. Unsere Studie erforscht die Natur der Software-Qualität im Zusammenhang mit der Modellierung des Klimas. Wir führten eine Analyse der Fehleranzeigen und fehlerhafter Festlegungen in vielen Versionen führender Klimamodelle durch, indem wir fehlerhafte Daten von Fehlersuchdateien und aus Fehlerprotokollen sammelten. Wir fanden heraus, dass die Klimamodelle alle sehr geringe Fehlergrenzen haben, jedenfalls im Vergleich mit gut bekannten Projekten ähnlicher Größenordnung mit offenen Quellen. Wir diskutieren unsere Ergebnisse, um Aussagen über die Vertrauensbasis der Modellsoftware zu machen.

Aus: Assessing climate model software quality: a defect density analysis of three models, by J. Pipitone and S. Easterbrook, Geosci. Model Dev. Discuss., 5, 347-382, 2012, www.geosci-model-dev-discuss.net/5/347/2012/, doi:10.5194/gmdd-5-347-2012

Kommentar von Judith Curry: Bei diesem Journal handelt es sich um ein Online-Diskussionsportal (von welchem ich ein großer Fan bin). Bis heute wurden zwei interaktive Kommentare gepostet (hier und hier). Beide diese Begutachtungen sind positiv. Die folgende Begutachtung habe ich per E-Mail erhalten, und zwar von jemandem, der anonym bleiben möchte (diese Begutachtung ist nicht positiv). Diese Person hat die Absicht, eine Begutachtung online an das Discussion Journal zu senden und möchte die Kommentare hier sorgfältig lesen, um die Begutachtung vor dem Absenden hieb- und stichfest zu machen. Einen Blogbeitrag von Easterbrook zu dieser Studie findet man hier, zusammen mit einem guten Kommentar von Nick Barnes.

Begutachtung der Studie von Pipitone und Easterbrook von Anonymus

Einführung

Folgende Punkte in der Studie von Pipitone und Easterbrook werden in diesem Kommentar angesprochen:

  1. Fehlende Eindeutigkeit bei der Entwicklung der Software der Globalen Klimamodelle (GCMs)
  2. Auswirkungen des Advanced Strategic Computing Initiative (ASCI)-Projektes auf die Entwicklung moderner Verifikations- und Bewertungsverfahren
  3. Fehlende Präzision einfacher Fehleraufzeichnungen als Indikator der Software-Qualität.
  4. Fehlende Überlegungen zur Eignung von Produktionsbeiträgen zur Software im Bereich der Unterstützung von Entscheidungen.

Wissenschaftliche Software-Entwicklung

Hinsichtlich der erforderlichen großen Erfahrung, der Komplexität der Phänomene, einer großen Anzahl von Systemfunktionen, die hier von Interesse sind und in jeder anderen Hinsicht sind die Globalen Klima-(Zirkulations-)Modelle alles andere als eindeutig.

Jede wissenschaftliche und Ingenieurs-Software in Zusammenhang mit Anwendungen in der realen Welt erfordert hohe Aufmerksamkeit durch Experten mit umfangreichen Kenntnissen der physikalischen Aspekte, und diese Experten müssen entscheidend im Prozess der Software-Entwicklung mitwirken. Das Klima der Erde und andere natürliche Phänomene und Prozesse sind hier keine Ausnahme. Einige Systeme und damit verbundene physikalische Prozesse sind mindestens ebenso inhärent komplex wie die Klimasysteme der Erde. Modelle und Software für derartige Systeme erfordern auch intensive Kenntnisse über eine Vielfalt verschiedener Phänomene und Prozesse, die für die Modellierung von Bedeutung sind. Sie sind auch für die Beschreibung der Prozesse und die Kopplung zwischen Komponenten zur Beschreibung dieser Prozesse wichtig. Aus den gleichen Gründen müssen die Anwender der Software auch über großes Wissen und Erfahrung über das physikalische Problem verfügen, das heißt auf dem Gebiet der Anwendung.

Wie in der Studie von Pipitone und Easterbrook erwähnt, nutzen die Entwickler der Modelle, Methoden und Software diese komplexen Systeme, um sowohl über die zugrunde liegende Physik als auch über die Software selbst Erfahrungen zu sammeln. Intensive iterative Wechselwirkungen zwischen Experten aus Physik, Mathematik und Softwareentwicklung sind die Regel. Die GCMs sind in dieser Hinsicht keine Ausnahme.

Das Problem der  Softwarequality in wissenschaftlicher Software

Easterbrook und Johns (2009) haben eine Übersicht über einige der Techniken präsentiert, die in einigen Laboren der GCM-Modellierung bei der Entwicklung der GCM-Software angewendet worden sind. Alle von den Autoren beschriebenen Techniken sind standardmäßige Operationsprozesse, die während der Ausarbeitung von Forschungsversionen aller wissenschaftlichen und technischen Software vor Veröffentlichung der Codes benutzt werden.

Die von Easterbrook und Johns beschriebenen Aktivitäten werden manchmal als entwicklungsbedingte Einschätzungen bezeichnet: Sie werden von Entwicklern während des Entwicklungsprozesses verwendet. Die von den Autoren beschriebenen Techniken sind jedoch als Nachweis, dass die Modelle, Methoden und Software korrekt erstellt worden sind, oder dafür, dass sie für Anwendungen geeignet sind, nicht ausreichend. Im Besonderen geben die von den Autoren beschriebenen Aktivitäten zur entwicklungsbedingten Einschätzung keinen Aufschluss über die Zusammenführung der verschiedenen numerischen Methoden und der Genauigkeit der berechneten Ergebnisse für alle reagierenden Funktionen des Systems, die hier von Interesse sind.

Stevenson (1999) sowie die ersten beiden, in Tevenson, Gustafson (1998) und Larzelere (1998) genannten Referenzen waren unter den ersten Studien, in denen man sich über die Konsequenzen der Advanced Strategic Computing Initiative (ASCI) des Stockpile Stewardship-Projektes zur Verifikation und Bewertung der Modelle, der Methoden und der Computersoftware Gedanken gemacht hatte. Dieses Projekt hat zum Ziel, experimentelle Tests in großem Umfang durch berechnete und im Rahmen kleinere Experimente zu ersetzen. Die Studien machten sich Gedanken über dieses Ziel unter all den anderen, jemals unternommenen Projekten, diese komplexen physikalischen Phänomene und Prozesse zu modellieren. Diese drei Studien stellten die Bandbreite der Wirksamkeit hinsichtlich Verifikation und Bewertung zu Recht in Frage. Die Autoren dieser Studien waren nicht allzu optimistisch, dass man die immensen Herausforderungen hinsichtlich Verifikation und Bewertung durch den ASCI erfolgreich beschreiben könnte.

Die Ziele standen im Zusammenhang mit Software-Entwicklungen innerhalb des National Laboratory Systems, für welches derartige Verifikations- und Bewertungsprozeduren formal nicht existierten. Allerdings haben alle in das ASCI-Projekt involvierten Laboratorien die Herausforderungen angenommen und wichtige Beiträge zur Entwicklung und erfolgreichen Anwendung moderner Verifikations- und Bewertungsverfahren geleistet.

Die von Patrick Roache initiierten Entwicklungen hinsichtlich Verifikation und Bewertung mit signifikanten zusätzlichen Entwicklungen von William Oberkampf und Kollegen am Sandia National Laboratory und anderen sowie mit Beiträgen von Industrie und Akademien haben alle Fragen beantwortet, die in jenen ersten Studien von Stevenson und anderen aufgeworfen worden waren.

Aus ASCI entwickelte Methoden zur Verifikation und Bewertung

Die modernen Methoden zur Verifikation und Bewertung mathematischer Modelle, numerischer Methoden und der damit verbundenen Computer-Software sind der einfachen Auflistung der Bandbreite von Fehlern als Mittel zur Bestimmung der Qualität von Software weit überlegen. Die Bücher von Patrik Roache (1998, 2009) sowie Oberkampf und Roy (2010) haben die Evolution der Methoden dokumentiert. Zusätzlich haben Oberkampf und seine Kollegen am Sandia National Laboratory eine große Anzahl technischer Berichte des Labors erstellt, besonders Oberkampf, Trucano und Hirsch (2003). Die Methoden wurden erfolgreich angewendet auf eine Vielfalt wissenschaftlicher  und Ingenieurssoftware. Und sie wurden von vielen wissenschaftlichen und professionellen Ingenieursgesellschaften übernommen als Maßgabe zur Veröffentlichung in begutachteten Journalen. Eine Eingabe in Suchmaschinen wie Google, Google Scholar oder www.osti.gov wird eine große Anzahl von Treffern ergeben.

Das Buch von Knupp und Salari (2002) über die Method of Manufactured Solutions (MMS), einer Methode, die zuerst von Roache eingeführt worden war, zeigt eine kraftvolle Methode zur Quantifizierung der Genauigkeit numerischer Methoden zur damit verbundenen theoretischen Effizienz und zur Entdeckung von Verschlüsselungsfehlern. Auch hier wird die Suche nach Literatur zu einer großen Zahl nützlicher Berichte und Studien mit zahlreichen Anwendungsbeispielen führen. Die MMS sind goldener Standard zur Verifikation numerischer Lösungen.

Das Zählen von Fehlern ist fehlerhaft

Die Daten, auf denen die Studie von Pipitone und Easterbrook basiert, wurden von Pipitone (2010) zusammengetragen und präsentiert. Diese These und die Diskussionsstudie selbst sprechen die nicht so idealen Charakteristika der Fehlerbestimmung relativ zur Bestimmung der Softwarequalität an. Das Buch von Oberkampf und Roy (2010) widmet der Fehlerbestimmung einen einzelnen, langen Absatz. Die Rohdaten der These zeigen diese große Anzahl von Fehlern in absoluten Zahlen, die in den begutachteten GCMs präsent waren.

Das Zählen der Fehler führt nicht zu brauchbaren Beiträgen in drei der wichtigsten Attribute der Softwarequalität, wie der heute benutzte Satz zeigt: Verifikation und Bewertung [Verification and Validation (V&V)] sowie die Bestimmung der Ungewissheit [uncertainty qualification (UQ)]. Bei der modernen Softwareentwicklung ist die Verifikation ein mathematisches und die Bewertung ein physikalisches Problem, einschließlich der Art und Weise von Bewertungstests.

Das Zählen der Fehler wäre sinnvoller, wenn die Daten als Funktion der Zeit nach Einführung der Software präsentiert werden würden, um eine stetige Verbesserung und eine genaue Klassifizierung des Fehlers zu gewährleisten. Das Zählen wäre auch nützlicher, wenn es nur mit neueren Versionen der Software verbunden wäre. Und die Anzahl der von den Anwendern abgedeckten verschiedenen Reaktionsfunktionen ist auch von Interesse: eine sehr grobe Annäherung an die Modelle. Im Allgemeinen werden die verschiedenen Reaktionsfunktionen eine grobe Proxy für die Konzentration auf wichtige Teile der mathematischen Modelle sein.

Das Zählen der Fehler wäre noch viel nützlicher, wenn man auch den Fehlertyp betrachten würde. Es gibt folgende vier Fehlerklassen: (1) Fehler des Anwenders, (2) Verschlüsselungsfehler, (3) Grenzen des Modells oder der Methode und (4) Defizite im Modell oder der Methode. Von diesen zählt nur die zweite Klasse Verschlüsselungsfehler. Die erste Klasse, ein Fehler des Anwenders, könnte ein Hinweis darauf sein, dass eine Verbesserung bei der Dokumentation der Codes erforderlich ist, und zwar für die theoretische Basis der Modelle und Methoden und/oder die Anwendungsprozeduren und/oder das Verstehen der grundlegenden Natur der berechneten Systemreaktionen. Die dritte Klasse, Grenzen des Modells oder der Methode bedeutet, dass ein gewisser Grad der Repräsentation zwar vorhanden ist, ein Anwender aber eine Grenze entdeckt hat, die das Entwicklungsteam nicht erwartet hatte. Die vierte Klasse bedeutet, dass ein Anwender eine neue Anwendung und/oder Reaktion entdeckt hat, die in der Originalentwicklung fehlte. Diese vier erfordern allgemein eine signifikante Vorbereitung des Modells, der Methode und der Software-Modifikationen relativ zur Korrektur des Fehlers.

Die Punkte (3) und (4) könnten ein wenig mehr Klarstellung brauchen. Eine Grenze des Modells oder der Methode kann mit einem turbulenten Fluss illustriert werden, für welchen das Personal, das das Originalmodell entwickelt hat, die Konstanten spezifiziert hat zu jenen, die mit parallelen Scherungsströmungen korrespondieren, und ein Anwender hat versucht, die Modellergebnisse mit experimentellen Daten zu vergleichen, deren Rückführung wichtig ist. Punkt (4) kann auch durch einen turbulenten Fluss illustriert werden. Man denke sich einen Fall, in welchem die Entwickler eine numerische Lösungsmethode verwendet haben, die nur für parabolische/fortlaufende physikalische Situationen möglich ist, obwohl der Anwender einem elliptischen Fluss gegenüberstand.

Die Studie von Pipitone und Easterbrook enthält nur wenige Informationen über die Art der Fehler, die man entdeckt hatte.

Eignung für Produktionsanwendungen

In der Studie von Pipitone und Easterbrook geht es nicht um die Aspekte der Anwendung der GCMs; stattdessen konzentriert sich die Studie auf die Lernaspekte des Modells. Wie in diesem Kommentar schon erwähnt, sind diese Aspekte allen Modellen gemeinsam, nämlich immer dann, wenn die Komplexität eine wichtige Komponente ist – Komplexität sowohl hinsichtlich der Physik als auch der Software.

Die Ziele der Modell- und Softwareentwicklung sind die Erzeugung von Tools und Anwendungsprozeduren, die für Vorhersagen ausreichender Genauigkeit in der realen Welt geeignet sind. Die Grundlage ausreichender Genauigkeit ist die Bewertung dieser Vorhersagen im Vergleich mit gemessenen Daten aus den Anwendungsregionen. Alle Funktionen der Systemreaktionen müssen durch Testbewertungen geprüft werden. Die Begutachtungsstudie von Easterbrook spricht keinerlei Aspekte der Bewertung an, da dieses Konzept in den Berichten und Studien definiert ist.

Die Bewertung ist für alle Modelle, Methoden, Software, Anwendungsprozeduren und die Anwender erforderlich, die die Basis politisch-öffentlicher Entscheidungen bilden. Die Bewertung muss nach der Verifikation erfolgen. Im Allgemeinen werden Verifikation und Bewertung dieser Arbeitsmittel und Prozeduren von Personen durchgeführt, die unabhängig von dem Team sind, das die Modelle und Prozeduren entwickelt hat. Die Auflistung von Fehlern, vor allem solcher, die während der Entwicklung zutage treten, hat in dieser Hinsicht nichts zu bieten.

Schlussfolgerung

Die Studie präsentiert ein sehr schwaches Argument für die Qualität der GCM-Software. Die weithin akzeptierten und erfolgreichen modernen Verifikations- und Bewertungsmethoden, welche in vielen wissenschaftlichen Softwareprojekten Verwendung finden, werden in der Studie nicht einmal erwähnt. Noch wichtiger, die Brauchbarkeit der GCMs für Anwendungen, die politische En tscheidungen beeinflussen, wird ebenfalls nicht erwähnt. Das einfache Aufzählen von Fehlern kann keine Informationen relativ zu Bewertung und Anwendung bei politischen Entscheidungen bieten.

References

Easterbrook, Steve M. and Johns, Timothy C., Engineering the Software for Understanding Climate, Computing in Science & Engineering, Vol. 11, No. 6, pp. 65 – 74, 2009.

Gustafson, John, Computational Verifiability and Feasibility of the ASCI Program, IEEE Computational Science & Engineering, Vol. 5, No. 1, pp. 36-45, 1998.

Knupp, Patrick and Salari, Kambiz, Verification of Computer Codes in Computational Science and Engineering, Chapman and Hall/CRC, Florida 2002.

Larzelere II, A. R., Creating Simulation Capabilities, IEEE Computational Science & Engineering, Vol. 5, No. 1, pp. 27-35, 1998.

Oberkampf, William F. and Roy, Christopher J., Verification and Validation in Scientific Computing, Cambridge University Press, Cambridge, 2010.

Oberkampf, William F., Trucano, T. G., and Hirsch, C., Verification, Validation, and Predictive Capability in Computational Engineering and Physics , Sandia National Laboratories Report SAND 2003-3769, 2003.

Pipitone, Jon, Software quality in climate modeling, Masters of Science thesis Graduate Department of Computer Science, University of Toronto, 2010.

Roache, Patrick J., Verification and Validation in Computational Science and Engineering, Hermosa Publishers, Socorro, New Mexico, 1998.

Roache, Patrick J., Fundamentals of Verification and Validation, Hermosa Publishers, Socorro, New Mexico, 2009.

Roache, Patrick J., Code Verification by the Method of Manufactured Solutions, Journal of Fluids Engineering, Vol. 114, No. 1, pp. 4-10, 2002.

Stevenson, D. E., A critical look at quality in large-scale simulations, IEEE Computational Science & Engineering, Vol. 1, No. 3, pp. 53–63, 1999.

Kommentar von Judith Curry: Zur Hintergrundinformation folgen hier einige Beiträge zur Klimamodellierung V&V:

Meine persönliche Ansicht hierzu liegt mehr auf der Linie dessen, was Anonymus hier präsentiert als auf dem, was von Pipitone und Easterbrook kommt.

Link: http://judithcurry.com/2012/04/15/assessing-climate-model-software-quality/

Übersetzt von Chris Frey EIKE

image_pdfimage_print

Wir freuen uns über Ihren Kommentar, bitten aber folgende Regeln zu beachten:

  1. Bitte geben Sie Ihren Namen an (Benutzerprofil) - Kommentare "von anonym" werden gelöscht.
  2. Vermeiden Sie Allgemeinplätze, Beleidigungen oder Fäkal- Sprache, es sei denn, dass sie in einem notwendigen Zitat enthalten oder für die Anmerkung wichtig sind. Vermeiden Sie Schmähreden, andauernde Wiederholungen und jede Form von Mißachtung von Gegnern. Auch lange Präsentationen von Amateur-Theorien bitten wir zu vermeiden.
  3. Bleiben Sie beim Thema des zu kommentierenden Beitrags. Gehen Sie in Diskussionen mit Bloggern anderer Meinung auf deren Argumente ein und weichen Sie nicht durch Eröffnen laufend neuer Themen aus. Beschränken Sie sich auf eine zumutbare Anzahl von Kommentaren pro Zeit. Versuchte Majorisierung unseres Kommentarblogs, wie z.B. durch extrem häufiges Posten, permanente Wiederholungen etc. (Forentrolle) wird von uns mit Sperren beantwortet.
  4. Sie können anderer Meinung sein, aber vermeiden Sie persönliche Angriffe.
  5. Drohungen werden ernst genommen und ggf. an die Strafverfolgungsbehörden weitergegeben.
  6. Spam und Werbung sind im Kommentarbereich nicht erlaubt.

Diese Richtlinien sind sehr allgemein und können nicht jede mögliche Situation abdecken. Nehmen Sie deshalb bitte nicht an, dass das EIKE Management mit Ihnen übereinstimmt oder sonst Ihre Anmerkungen gutheißt. Wir behalten uns jederzeit das Recht vor, Anmerkungen zu filtern oder zu löschen oder zu bestreiten und dies ganz allein nach unserem Gutdünken. Wenn Sie finden, dass Ihre Anmerkung unpassend gefiltert wurde, schicken Sie uns bitte eine Mail über "Kontakt"

Bitte beachten Sie unsere Datenschutzerklärung

Erst Registrieren dann Kommentieren

Zum Kommentieren müssen Sie eingeloggt sein. Bitte hier auf Registrieren klicken, um ein Login zu erhalten.

Kommentar hinzufügen

Sie haben nicht das korrekte Login oder Passwort eingegeben

Sie müssen eingeloggt sein, um einen Kommentar schreiben zu können.

3 Kommentar(e)

Neueste zuerst
nach Bewertung Neueste zuerst Älteste zuerst
1

Es ist ein alter Traum der Menschheit, das Wetter und das Klima und überhaupt alles auf dieser Welt zu beherrschen, oder in Formeln zu pressen. Geht aber bei einem äußerst komplexen Thema wie Klima oder auch Wetter meistens in die Hose. Einfach mal nach "Der unzufriedene Bauer" googeln!
Soll jetzt das Klima und dessen Entwicklung in Formeln (=Software) gepreßt werden, ohne daß man über die Anzahl, Auswirkung und Zusammenwirken der unzähligen Faktoren überhaupt etwas mehr als 1 Prozent weiß? Für eine Software, in die nicht alle(!) Faktoren einfließen gilt der GIGO-Effekt (GIGO= Garbage in - Garbage out)!

2

Bei mir sind durch die Kälte diesen Winter alle Rosenstöcke erfroren. Die Bauern klagen auch schon darüber (und wollen Geld). Letztes Jahr bekamen die Weinbauern Geld wegen der Anf. Mai erforenen Weinreben. Trotzdem war lt. Propagande auch dieser Winter wieder zu warm.
Es ist schon so weit, dass der Bürger 2 x zur Klimakasse gebeten wird. Einmal zur Kampffinanzierung gegen die Erwärmung und zusätzlich zur Schadensfinanzierung wegen der untypischen Kälte.

Zur Softwarequalität kann ich nur sagen, dass in meinen Berufsjahren die wirklich hohen Problemkosten in Großprojekten immer die SW verursacht hat. Wird beim Klimawandel wohl nicht anderst sein.

3

Über die Qualität der Wetter- Klimasoftware kann man dieser Tage wieder erstauntes feststellen. Seit zwei Tagen wird über die Medien wieder einmal ein sommerlich heißes Wochenende für ganz Deutschland propagierd. Heute wird schon wieder etwas zurückgerudert und es werden jetzt anscheinend nur im Süden und Osten die 30 Grad erreicht. Das ist dem starken Wind aus dem Süden von der Sahara her kommend zu verdanken. Die Luft kann dadurch mit feinen Sandstaub getrübt sein. Evtl. kommen dadurch dann doch nicht die 30 Grad im Süden bzw. Osten zustande..;)
Im Norden und Westen Deutschland bestimmt die kalte Luft über Nord- und Ostsee das Wochenendwetter. Mit 10-15 Grad soll es kühl und auch nass werden.
Und das, obwohl der menschengemachte CO2 Anteil immer weiter steigt. 😉
Jaja solche Computermodelle sind halt nur was für Programmierer und müssen sich zum Schluss immer der Realtität messen und zum großen Teil auch geschlagen geben.