Reading Time: 9 minutes

Validierung und Verifizierung (V&V) sind wesentliche Qualitätssicherungsprozesse für PDE-Simulationen. Die Verifizierung stellt sicher, dass Ihr Code die Gleichungen richtig löst (das Lösen der Gleichungen richtig). Die Validierung bestätigt, dass Ihr Modell die reale Physik (Lösen der richtigen Gleichungen) genau darstellt. Ein robustes V&V-Framework kombiniert die Code-Verifizierung über Methoden wie die Methode der hergestellten Lösungen, die Lösungsprüfung mit Netzkonvergenzstudien und die Validierung gegenüber Benchmark-Problemen oder experimentellen Daten. Die Einhaltung etablierter Standards wie ASME V& V 10/20 trägt zur Gewährleistung der Glaubwürdigkeit und Reproduzierbarkeit im wissenschaftlichen Rechnen bei.

Vorstellung

Partielle Differentialgleichungssimulationen (PDE) untermauern unzählige wissenschaftliche und technische Entscheidungen – von der Materialwissenschaft bis zur Strömungsdynamik. Eine Simulation ist jedoch nur so vertrauenswürdig wie die dahinter liegenden Verifizierungs- und Validierungs-Prozesse. Die Konsequenzen einer unzureichenden V & V können schwerwiegend sein: falsche Forschungsergebnisse, fehlerhafte technische Konstruktionen und verschwendete Rechenressourcen.

Dieser Leitfaden bietet ein praktisches, implementierungsorientiertes Framework für V & V in PDE-Simulationen. Wir werden den theoretischen Jargon durchschneiden und Ihnen umsetzbare Verfahren geben, die Sie auf Ihre endlichen Volumenlöser (wie FIPY), Finite-Elemente-Codes oder jede PDE-basierte Simulationssoftware anwenden können.

Verstehen der V & V-Unterscheidung

Vor dem Eintauchen in Verfahren ist es wichtig, den grundlegenden Unterschied zwischen Verifizierung und Validierung zu verstehen. Diese Unterscheidung wird oft verwechselt, bildet aber die Grundlage jedes glaubwürdigen V & V-Programms.

Verifizierung: Lösen wir die Gleichungen richtig?

Die Überprüfung fragt: „Haben wir das Modell richtig aufgebaut?“ Es ist ein mathematischer und Codequalitätsprozess, der bestätigt:

  • Die numerische Implementierung löst die maßgeblichen PDEs korrekt
  • Diskretisierungsfehler werden richtig geschätzt und kontrolliert
  • Iterative Löser konvergieren zur richtigen Lösung
  • Programmierfehler und Logikfehler werden eliminiert

Bei der Verifizierung geht es um Interne Konsistenz – das Verhalten des Codes verhält sich genau so, wie es das mathematische Modell vorschreibt, unabhängig davon, ob dieses Modell physikalisch korrekt ist.

Validierung: Lösen wir die richtigen Gleichungen?

Validierung fragt: „Haben wir das richtige Modell erstellt?“ Es wird bewertet, ob die Simulation das reale physikalische System für den vorgesehenen Zweck genau darstellt:

  • Stimmen die Modellausgaben mit experimentellen Beobachtungen innerhalb der Unsicherheitsgrenzen überein?
  • Sind die gewählten Physik und Randbedingungen angemessen?
  • Tut das Modell über den erwarteten Betriebsbereich zuverlässig?

Bei der Validierung geht es um Externe Genauigkeit – das Vertrauen, dass dem Modell bei der Entscheidungsfindung vertraut werden kann.

Key Takeaway: Die Überprüfung muss vor der Validierung liegen. Sie können einen nicht überprüften Code nicht validieren. Dies validiert lediglich die fehlerhafte Implementierung.

Codeüberprüfung: Der Nachweis Ihrer Implementierung ist korrekt

Die Codeüberprüfung ist der rigorose Prozess, um zu demonstrieren, dass Ihr PDE-Solver das zugrunde liegende mathematische Modell korrekt implementiert. In der Praxis werden zwei Hauptansätze verwendet.

1. Methode der hergestellten Lösungen (MMS)

Die Methode der hergestellten Lösungen ist der Goldstandard für die Codeverifizierung in der Computerwissenschaft. Es bietet eine systematische, mathematisch strenge Möglichkeit, Ihren Solver zu testen, ohne sich auf bereits vorhandene analytische Lösungen zu verlassen, die möglicherweise nicht Ihren spezifischen Randbedingungen oder Gleichungsformen entsprechen.

Wie MMS funktioniert

  1. Wählen Sie eine analytische Lösung (u_m(mathbf{x}) ), die glatt und ausreichend differenzierbar ist (z. ))
  2. substitute (u_m ) in Ihren regierenden PDE-Operator (mathcal{L}), um den erforderlichen Quellbegriff (s) zu berechnen:
    [
    s(mathbf{x}, t) = mathcal{L}(U_M)
    ]
  3. Simulation durchführen mit dem hergestellten Quellbegriff( s ) und geeigneten Grenz-/Anfangsbedingungen abgeleitet von ( u_m )
  4. Vergleiche Die numerische Lösung (U_H) zur exakt hergestellten Lösung ( U_M )
  5. Maschenverfeinerungsstudien, um zu überprüfen, ob die beobachtete Genauigkeit der theoretischen Reihenfolge Ihres Diskretisierungsschemas entspricht

Die Kraft von MMS liegt in seiner Universalität: Sie können jeden Code für jeden PDE überprüfen, unabhängig von den Randbedingungen, da Sie eine kompatible Lösung auf Anfrage herstellen.

Practical tip: Verwenden Sie symbolische Berechnungstools (Symy, Mathematica, Maple), um analytische Derivate zu berechnen, die für (S) erforderlich sind, insbesondere für komplexe nichtlineare PDEs. Automatisieren Sie den Prozess mit Skripten, um Testfälle systematisch zu generieren.

MMS-Ressourcen

Für detaillierte MMS-Verfahren und Beispiele:

2. Reihenfolge der Genauigkeitsprüfung

Die Reihenfolge der Genauigkeitstests überprüft, ob Ihr Code die erwartete Konvergenzrate unter Netzverfeinerung erreicht. Bei einem Finite-Volumen-Schema zweiter Ordnung sollte die Halbierung des Netzabstands den Fehler um ungefähr den Faktor 4 verringern.

Verfahren

  1. Wählen Sie ein Problem mit einer bekannten exakten Lösung (kann aus MMS- oder Lehrbuch-Benchmarks stammen)
  2. Lösen Sie eine Folge von zunehmend verfeinerten Netzen (z. B. 32 × 32, 64 × 64, 128 × 128)
  3. Berechnen Sie die Fehlernorm (L1, L2 oder L∞) auf jeder Verfeinerungsebene
  4. Plotfehler vs. Mesh-Größe in einem Log-Log-Plot und berechnen Sie die beobachtete Reihenfolge:
    [
    text{order} = frac{log(e_{coarse}/e_{fine})}{log(h_{coarse}/h_{fine})}
    ]
  5. Bestätigen Sie, dass die beobachtete Reihenfolge der theoretischen Diskretisierungsreihenfolge innerhalb der Toleranz entspricht (± 0,1–0,2 aufgrund von Grenzeffekten, Maschinengenauigkeit)

Dies ist eine minimale Anforderung für jeden PDE-Code, der Korrektheit beansprucht.

Common Pitfall: Zu grobe Maschen oder zu einfache Probleme, die nicht alle Begriffe in der PDE ausüben. Testen Sie komplexe, realistische Szenarien, einschließlich Nichtlinearitäten, Diskontinuitäten und gekoppelter Physik.

3. Cross-Code-Vergleich (Vorsicht)

Das Vergleichen von Ergebnissen zwischen zwei verschiedenen Codes kann nützlich sein, aber Ersatz ist kein Ersatz für die Überprüfung gegen analytische Lösungen. Beide Codes könnten den gleichen systematischen Fehler enthalten. Verwenden Sie den Cross-Code-Vergleich nur als Ergänzungsprüfung nach ordnungsgemäßer MMS- oder Auftragsprüfung.

Lösungsüberprüfung: Quantifizierung numerischer Fehler

Sogar ein verifizierter Code erzeugt numerische Approximationen mit inhärenten Fehlern. Die Lösungsüberprüfung schätzt diese Fehler für einen bestimmten Simulationslauf.

Diskretisierungsfehlerschätzung

Die Hauptquellen für numerische Fehler in PDE-Simulationen sind:

  • Diskretisierungsfehler (Mesh/Grid-Auflösung)
  • Iterationsfehler (Solver-Konvergenztoleranzen)
  • Abrundenfehler (Gleitkommagenauigkeit)

Diskretisierungsfehler sind typischerweise dominant. Richardson-Extrapolation kann eine Fehlerschätzung liefern, indem die Ergebnisse von zwei Netzen verwendet werden:

[
varepsilon_{richardson} = frac{u_{h_1} – u_{h_2}}{r^{p} – 1}
]

wobei (r) das Verfeinerungsverhältnis und (p) die beobachtete Genauigkeitsreihenfolge ist.

Konvergenzkriterien

Stellen Sie immer sicher, dass iterative Solver (z. B. Newton-Methode, lineare Systemlöser) auf die gewünschte Toleranz konvergiert sind, bevor Sie den Ergebnissen vertrauen. Überprüfen Sie:

  • Restreduktion um mehrere Größenordnungen
  • Lösungsänderungen zwischen Iterationen unter dem Schwellenwert
  • Konservierungsfehler (bei Finite-Volumen-Methoden)

Warnung: „konvergiert“ bedeutet nicht „korrigieren“. Ein iterativer Solver kann zu einer falschen Lösung konvergieren, wenn die anfängliche Vermutung schlecht oder das Problem schlecht konditioniert ist. Aus diesem Grund sind sowohl Verifizierung als auch Validierung notwendig.

Validierung: Vergleich mit der Realität

Die Validierung beurteilt, ob Ihr Simulationsmodell für den beabsichtigten Zweck ausreichend genau ist, indem Vorhersagen mit unabhängigen experimentellen Daten verglichen werden.

Benchmark-Probleme

Benchmark-Probleme sind standardisierte Testfälle mit gut charakterisierten experimentellen oder High-Fidelity-Referenzdaten. Sie dienen als objektive Validierungsziele.

Common PDE Benchmark Categories

  • Fluiddynamik: Vorbei an einem Zylinder (RE=20–1000), Deckel-gesteuerter Hohlraum, Rayleigh-Bénard-Konvektion
  • Transportgleichungen: 1D-Advektionsdiffusion mit bekannten analytischen Lösungen
  • Phasenfeld: Allen-Cahn, Cahn-Hilliard-Muster gegen Mikroskopie
  • Diffusionsreaktion: Fisher-KPP-Wellengeschwindigkeitsvalidierung

Repositories wie pdebench bieten standardisierte Datensätze zum Vergleichen von maschinellem Lernen und numerischen Methoden.

Best Practices für die Validierung

  1. Unabhängige Daten verwenden: Niemals mit demselben Datensatz validieren, der für die Kalibrierung oder Codeüberprüfung verwendet wird
  2. Unsicherheit quantifizieren: experimentelle Messungen haben Unsicherheit; Modellvorhersagen haben numerische Fehler. Vergleichen Sie innerhalb der kombinierten Unsicherheitsgrenzen
  3. Mehrere Validierungspunkte: Testen Sie über den Parameterraum, nicht nur eine Betriebsbedingung
  4. Dokumentenvalidierungsbasis: Erfassen Sie, welche Probleme verwendet wurden, Ergebnisse und Pass-/Fail-Kriterien

Kritischer Fehler: Verwenden von experimentellen Daten, um Modellparameter (Kalibrierung) zu optimieren und dann die Validierung mit denselben Daten zu beanspruchen. Das ist kreisförmige Argumentation. Reservieren Sie einen separaten Validierungsdatensatz.

Wenn experimentelle Daten nicht verfügbar sind

Für viele Forschungsprobleme sind qualitativ hochwertige experimentelle Daten knapp. In solchen Fällen:

  • Verwenden Sie High-Fidelity-Referenzlösungen (z. B. DNS für turbulente Strömungen), falls verfügbar
  • Vergleichen Sie mit analytischen Lösungen für vereinfachte Fälle
  • Führen Sie einen Cross-Code-Vergleich mit mehreren unabhängigen, gut verifizierten Codes durch
  • Seien Sie transparent über die Einschränkung und charakterisieren Sie die prädiktive Unsicherheit durch Sensitivitätsanalyse

Standards und Frameworks

Die Übernahme etablierter Standards verleiht Ihrem V&V-Prozess Glaubwürdigkeit und stellt die Vollständigkeit sicher.

ASME V & V-Standards

Die American Society of Mechanical Engineers (ASME) hat eine Reihe von Standards für die Glaubwürdigkeit der Computermodellierung entwickelt:

Diese Standards bieten strukturierte Verfahren für:

  • Planung von V & V-Aktivitäten
  • Quantifizierung der numerischen Unsicherheit
  • Bewertung der Glaubwürdigkeit des Modells anhand von Beweisen
  • Dokumentationsanforderungen

Rahmenhierarchie

Ein umfassendes V&V-Framework folgt dieser Hierarchie:

  1. Codeüberprüfung → Beweisen Sie, dass der Code korrekt ist
  2. Lösungsüberprüfung → Numerischer Fehler für diesen Lauf schätzen
  3. Validierung → Vergleiche mit experimentellen/Referenzdaten
  4. Unsicherheitsquantifizierung → Eingabeunsicherheit an die Ausgaben weitergeben
  5. Vorhersagefähigkeit → Vertrauen in die Entscheidungsnutzung herstellen

häufige Fehler und wie man sie vermeidet

Basierend auf der Literatur und dem Expertenkonsens finden Sie hier die häufigsten V&v-Fehler:

Überprüfungsfehler

  • Vorausgesetzt, der Code ist fehlerfrei – selbst weit verbreitete Codes enthalten unentdeckte Fehler. Regelmäßige Regressionstests mit MMS-Fällen fangen neue Fehler ein.
  • Vernachlässigung der Auftragsgenauigkeit – Ohne die theoretischen Konvergenzraten zu bestätigen, können Sie sich nicht auf die Fehlerschätzungen verlassen.
  • Cross-Code-Vergleich als einzige Verifizierung – Zwei falsche Codes können zustimmen. Schließen Sie immer analytische oder hergestellte Lösungen ein.
  • Einmalige Überprüfung – Die Verifizierung sollte fortlaufend erfolgen, keine einmalige Aktivität. Jede Codeänderung erfordert eine erneute Verifizierung der betroffenen Module.

Validierungsfehler

  • Kalibrierung vs. Validierungsverwirrung – Abstimmungsparameter auf experimentelle Daten und dann „Validieren“ mit denselben Daten erhöhen das Vertrauen künstlich. Halten Sie die Kalibrierungs- und Validierungsdatensätze getrennt.
  • Ignorieren der experimentellen Unsicherheit – Eine Diskrepanz von 5% kann statistisch unbedeutend sein, wenn der experimentelle Fehler 10% beträgt. Messen Sie immer die Messunsicherheit.
  • Extrapolation – Validierung eines Modells in einem Regime (z. B. niedrige Reynolds-Zahl) und dann in einem völlig anderen Regime (hohe Re, Turbulenzen) ohne zusätzliche Validierung ist ungerechtfertigt.
  • Schlechte Dokumentation – Ohne detaillierte Aufzeichnungen über Validierungsprobleme, Ergebnisse und Entscheidungen kann die Glaubwürdigkeit nicht von anderen (oder sich selbst Monate später) bewertet werden.

Allgemeine V & V-Fehler

  • Schlecht charakterisierte Eingaben – Müll rein, Müll raus. Die Unsicherheit der Materialeigenschaften, Randbedingungen oder Geometrie muss quantifiziert und weitergegeben werden.
  • Kein unabhängiger Peer Review – V&V sollte von Experten überprüft werden, die nicht an der Entwicklung beteiligt sind. Dies erwischt Bestätigungsvoreingenommenheit und Versehen.
  • Mangel an Reproduzierbarkeit – Alle V&V-Fälle sollten mit versionsgesteuerten Eingabedateien und Skripten automatisiert werden, damit andere Ihre Ergebnisse genau reproduzieren können.

Implementierung eines praktischen V&V-Workflows für PDE-Codes

Hier ist ein schrittweises Framework, das Sie für Ihre PDE-Simulationsprojekte implementieren können:

Phase 1: Code-Verifizierung (vor jeder Produktion)

  1. MMS-Testsuite entwickeln Abdeckung:
    • Jeder PDE-Typ Ihr Code löst (Diffusion, Advektion, Reaktion, gekoppelt)
    • Alle Randbedingungstypen (Dirichlet, Neumann, Mixed)
    • Komplex Geometrien, falls zutreffend
  2. Auftragsgenauigkeitstests automatisieren bei repräsentativen Problemen. Integration in Continuous Integration (CI), damit jeder Code-Commit diese Tests ausführt.
  3. Konvergenz iterativer Solver auf strenge Toleranzen verifizieren (Restreduktion ≥ 10⁻⁶ für lineare Lösung).
  4. Ergebnisse zur Dokumentenüberprüfung Mit Konvergenzdiagrammen, Fehlertabellen und Pass-/Fail-Kriterien.

Phase 2: Lösungsprüfung (für jeden Simulationsfall)

  1. Mesh-Konvergenzstudie mit mindestens 3 Mesh-Ebenen (grob, mittel, fein)
  2. Diskretisierungsfehlerschätzung (Richardson Extrapolation oder Multi-Grid-Methoden)
  3. Solver-Konvergenz überprüfen – Bestätigen Sie Residuen und Lösungsänderungen erfüllen Toleranzen
  4. Metriken für die Qualität der Metrik aufzeichnen (Orthogonalität, Seitenverhältnisse)
  5. Berichte geschätzte numerische Unsicherheit in wichtigen Interessensbeständen

Phase 3: Validierung (Building Glaubwürdigkeit)

  1. Select appropriate benchmark problems matching your application domain
  2. Validierungsfälle mit denselben Mesh-Auflösungs- und Solvereinstellungen wie Produktionsläufe
  3. Validierungsfehler quantifizieren anhand von Referenzdaten, Berücksichtigung der experimentellen / Benchmark-Unsicherheit
  4. Formularfehler beurteilen – Wenn Abweichungen die numerische Unsicherheit überschreiten, fehlende Physik oder falsche Annahmen identifizieren
  5. Document Validation Evidence mit Vergleichsdiagrammen, Fehlermetriken und Schlussfolgerungen zur Angemessenheit für den beabsichtigten Gebrauch

Phase 4: Unsicherheitsquantifizierung (erweitert)

Bei kritischen Entscheidungen propagieren Sie Eingabeunsicherheiten (Materialeigenschaften, Randbedingungen) bis zu Ausgaben mit:

  • Sampling-Methoden (Monte Carlo, Latin Hypercube)
  • Polynome Chaos-Erweiterungen für effiziente Ausbreitung
  • Sensitivitätsanalyse zur Identifizierung dominanter Unsicherheitsquellen

Das umfassende vvuq-Framework von Roy et al. integriert V & V mit Unsicherheitsquantifizierung.

Besondere Überlegungen zu Finite-Volumen-PDE-Solvern

FIPY und ähnliche endliche Volumencodes haben spezifische V& V-Überlegungen:

Diskretisierungsprüfung

  • Überprüfen Sie Face Gradient Berechnungen mit hergestellten Lösungen, die Quellbegriffe ungleich Null erzeugen
  • Testen Sie Verschiedene Netztypen (strukturiert vs. unstrukturiert), da die Fehlerkonstanten unterschiedlich sind
  • Validierung von Flusserhaltung durch Berechnen von Integralbilanzen – Finite-Volumen-Methoden sollten Mengen exakt erhalten (bis zu Solver-Toleranz)

Übliche FIPY-spezifische Überprüfungen

Wenn Sie FIPY verwenden, stellen Sie sicher, dass Sie Folgendes überprüft haben:

  • Korrekte Implementierung von Randbedingungsarten (Festwert, Gradient, etc.)
  • Umgang mit anisotropen oder tensorwerten Diffusionskoeffizienten
  • Time-Stepping-Schemata für vorübergehende Probleme (Einhaltung der CFL-Bedingung)
  • Gekoppelte Physik-Wechselwirkungen (z. B. Elektrochemie + Diffusion)

Informationen zu integrierten Überprüfungsproblemen finden Sie in der FIPY-Benchmark-Dokumentation.

Fallstudie: Überprüfung einer Phasenfeldsimulation

Gehen wir durch ein konkretes Beispiel. Angenommen, Sie implementieren ein Cahn-Hilliard-Phasenfeldmodell in FIPY:

  1. Code-Überprüfung mit MMS:
    • Wählen Sie eine hergestellte Lösung, die die Cahn-Hilliard-Gleichung mit einem Forcing-Term erfüllt
    • Erzeugen Sie exakte Lösung und Quellenbegriff symbolisch
    • Ausführen auf einem 2D-Mesh und Vergewissern Sie sich, dass der L2-Fehler bei zweiter Ordnung konvergiert
  2. Lösungsüberprüfung:
    • Run Mesh-Verfeinerung (z. B. 50×50, 100×100, 200×200)
    • Compute-Schnittstellenbreite und freie Energie auf jedem Netz
    • Verwenden Sie die Richardson-Extrapolation, um den Diskretisierungsfehler in der Energie zu schätzen

      • ›

  3. Validierung:
    • Simulieren Sie die spinodale Zerlegung und vergleichen Sie die charakteristische Längenskala mit analytischen Vorhersagen oder veröffentlichten Ergebnissen
    • Validieren Sie die Kinetik der Coarsing-Kinetik (L ∝ t^{1/3}) übereinstimmt Theorie
  4. Dokumentation:
    • Speichern Sie alle Eingabedateien, Skripte und Ergebnisse in einem versionsgesteuerten Repository
    • Erstellen Sie einen Verifizierungsbericht mit Plots und Tabellen

Entscheidungsleitfaden: Wann verwenden Sie welche V&V-Methode?

Lage Empfohlener Ansatz
Neuer PDE-Code oder wesentliche Überarbeitung Volle MMS-Suite + Auftragsgenauigkeitsprüfung
Kleinere Fehlerbehebung Gezielte MMS-Tests für betroffene Module
Produktionssimulation Lösungsprüfung (Mesh-Studie) obligatorisch
Modellentwicklungsphase Validierung vor 3+ Benchmark-Problemen
Regulierungs- oder High-Stakes-Nutzung Volles ASME V&V 40 Framework mit unabhängiger Peer Review
Forschungscode ohne experimentelle Daten Dokumentenbeschränkungen; Verwenden Sie mehrere unabhängige Überprüfungsmethoden
Leistungsoptimierung Nach der Optimierung erneut verifizieren, um keine Korrektheitsregression zu gewährleisten

Bottom Line: Die Strenge von V & V sollte mit den Folgen des Scheiterns übereinstimmen. Der akademische Forschungskodex erfordert noch eine grundlegende Überprüfung, aber die vollständige V & V 40-Konformität kann übertrieben sein. Industrie- oder sicherheitskritische Anwendungen erfordern umfassende, dokumentierte V&V.

Verwandte Anleitungen

Zu verwandten Themen in wissenschaftlichen Simulations-Workflows:

Zusammenfassung und nächste Schritte

Validierung und Überprüfung sind keine optionalen Add-Ons. Sie sind integraler PDE-Simulationen. Der hier beschriebene praktische Rahmen liefert eine Roadmap:

  1. Start mit der Code-Verifizierung Mit der Methode der hergestellten Lösungen zur Festlegung der Basiskorrektheit
  2. Numerische Fehler quantifizieren durch Lösungsüberprüfung für jeden Produktionslauf
  3. Validierungsnachweise mit Benchmark-Problemen und unabhängigen Daten
  4. Standards wie ASME V& V 10/20, um Ihren Prozess zu strukturieren
  5. Vermeiden Sie häufige Fehler – insbesondere die Verifizierungs-/Validierungsverwirrung und zirkuläre Kalibrierung
  6. Dokumente alles für Reproduzierbarkeit und Peer-Review

Die Implementierung eines einfachen V&V-Programms (MMS-Tests + Mesh-Konvergenz) erhöht das Vertrauen in Ihre Simulationsergebnisse erheblich und spart Zeit, um Fehler frühzeitig einzufangen.

Nächste Schritte: Prüfen Sie Ihren aktuellen Simulationsworkflow. Überspringen Sie die Überprüfung vollständig? Nur Single-Mesh-Berechnungen ausführen? Fügen Sie Ihrem nächsten Projekt mindestens einen Überprüfungstest (MMS oder Bestellgenauigkeit) hinzu und messen Sie den Unterschied in der Vertrauensstellung und der Fehlererkennung.

Benötigen Sie Hilfe bei der Implementierung von V & V für Ihr Simulationsprojekt?

Die Etablierung eines robusten V & V-Prozesses erfordert Fachwissen und Vorabinvestitionen. Wenn Sie Probleme haben mit:

  • Einrichten hergestellter Lösungstests für Ihren PDE-Code
  • Entwerfen von Netzkonvergenzstudien für komplexe Geometrien
  • Validierungsergebnisse interpretieren und Unsicherheit quantifizieren
  • Vorbereitung der V & V-Dokumentation für die Veröffentlichung oder behördliche Einreichung

Unser Team von Computational Science-Experten kann helfen. Wir spezialisieren uns auf die Erstellung von Verifizierungs-Frameworks für wissenschaftliche Python-Codes, einschließlich FIPY-basierter Simulationen. Wenden Sie sich über unser Issue-Tracking-System, um die Glaubwürdigkeitsbedürfnisse Ihres Projekts zu besprechen.

Referenzen und Weiterlesen

  • Roy, C. J. (2005). „Überprüfung von Code- und Lösungsprüfungsverfahren für die Computersimulation.“ Journal of Computational Physics .
  • Oberkampf, W. L. & Roy, C. J. (2010). Überprüfung und Validierung im wissenschaftlichen Rechnen . Cambridge University Press.
  • AIAA-Leitfaden zur Verifizierung und Validierung von Simulationen der computergestützten Fluiddynamik (1998).
  • ASME V&V-Standards: v & v. 10 , V & V. 20 , vvuq 1 .