Zeigen, dass die Zeitschrittgröße in einem Code mit automatischer Schrittgrößenauswahl klein genug ist

Ich habe kürzlich einen großen Teil des Legacy-Codes geerbt, der ein sehr steifes, vorübergehendes Problem löst. Ich möchte zeigen, dass die räumlichen und zeitlichen Schrittgrößen so klein sind, dass sich die qualitative Natur der berechneten Lösung nicht ändert, wenn sie verringert wird. Mit anderen Worten, ich möchte zeigen, dass die Lösung qualitativ "konvergiert". Da ich die räumliche Maschengröße explizit festlegen kann, ist dieser Teil unkompliziert. Da der Code jedoch die automatische Zeitschrittgrößensteuerung verwendet, kann ich die Zeitschrittgröße nicht direkt einstellen.

Der Algorithmus ändert den Zeitschritt zwischen zwei Grenzen basierend auf der Anzahl der Jacobi-Iterationen, die erforderlich sind, um eine Fehlertoleranz während der letzten Zeitschritte zu erreichen . Die Tatsache, dass es eine jacobianische Iteration verwendet, macht mich ziemlich sicher, dass es sich um eine Art implizites Schema handelt, aber ich kann nicht absolut sicher sein. Es berücksichtigt nicht den Fehler, den es im aktuellen Zeitschritt sieht, was dazu führt, dass es gelegentlich in die Iterationsgrenze gerät (vielleicht ein Dutzend Mal im Verlauf von mehreren tausend Zeitschritten, fast immer während der dynamischsten Abschnitte des Simulation). Die aktuellen Läufe, die ich abschließe, setzen die Zeitschrittgrenzen zweieinhalb Größenordnungen auseinander ( bis ). $n$$10^{-13}$$5 \cdot 10^{-11}$

In den Läufen habe ich die Kontrolle über die Zeitschrittgrenzen, die Anzahl der vergangenen Zeitschritte, in denen der aktuelle Zeitschritt ausgewählt wird, die maximale Änderung des Zeitschritts (Verhältnisse), die Zielanzahl der Jacobi-Iterationen, die maximale Anzahl von Iterationen und die Fehlergrenze. Ich würde gerne wissen, ob mich jemand auf den richtigen Weg bringen könnte, um die Zeitschrittunabhängigkeit zu analysieren oder zumindest herauszufinden, welcher Algorithmus verwendet wird.

Der Zweck der automatischen Fehlerschätzung und Schrittgrößensteuerung besteht darin, Sie von dem Problem zu befreien, manuell zu bestimmen, welche Schrittgröße ausreichend klein ist. Ihre Frage ist also ein bisschen wie die Frage: "Jemand hat mir dieses Auto mit Automatikgetriebe gegeben. Wie kann ich feststellen, in welchem ​​Gang ich mich befinde?" Der Punkt ist, dass Sie nicht wissen müssen sollten. Wenn das Getriebe fehlerhaft ist, müssen Sie es möglicherweise auseinander nehmen und reparieren, aber das ist ein viel größeres Problem.

In Ihrem Fall besteht der richtige Ansatz normalerweise darin, zu bestimmen, welche Art von Fehler akzeptabel ist, und dies durch die automatische Schrittgrößensteuerung aufzuerlegen. Es ist nicht perfekt, da die Fehlerkontrolle in diesem Sinne normalerweise nur eine lokale Fehlerkontrolle ist , sodass Sie den globalen Fehler nicht direkt kontrollieren, was Sie wahrscheinlich interessiert.

Eine Sache, die Sie im Zweifelsfall leicht tun können, ist, die Simulation mit einer Folge von immer engeren (dh kleinen) Fehlertoleranzen auszuführen. Sobald die Lösung (unabhängig von Ihrer Metrik) unempfindlich gegenüber einer Verringerung der Toleranz erscheint, können Sie aufhören.

Nachtrag : In Bezug auf das Problem der maximalen Iterationsgrenze (die zu einem lokalen Fehler führt, der die angegebene Toleranz überschreitet) schlage ich Folgendes vor.

Anscheinend glaubt der Code, dass es richtig ist, den Schritt zu akzeptieren , wenn er die maximale Anzahl von Iterationen überschreitet . Ich würde sagen, das ist das Falsche. Ein besserer Ansatz besteht darin, den Schritt abzulehnen und diesen Schritt mit einer reduzierten Schrittgröße erneut zu beginnen. Natürlich besteht die Gefahr, dass die Stufe unter die Mindestschrittgröße reduziert wird. In diesem Fall ist es richtig , die Simulation abzubrechen. Wenn Sie jedoch der Meinung sind, dass eine falsche Lösung besser ist als keine Lösung, können Sie den Schritt einfach akzeptieren und fortfahren, wenn beide Bedingungen erfüllt sind: Die minimale Schrittgröße wird erreicht und die maximale Anzahl von Iterationen wird überschritten.

In einem gut gestalteten Code ist es trivial, diese Art von Änderungen vorzunehmen, in einem beliebigen Code kann dies jedoch beliebig schwierig sein.