time step continuity errors / bounding (FEM / Genormte Berechnungen/OpenFOAM)

Hallo zusammen,

im Moment habe ich mit 2 Dingen zu kämpfen
Ich führe grad verschiedene Rechnungen (gleiches Modell, unterschiedliche Eintrittsgeschwindigkeiten) aus und verwende zum Vergleich zum einen das RNG k-epsilon Modell und zum anderen das SST k-omega Modell.
Ab und zu läuft mal eine Rechnung durch, die manchmal auch konvergiert ist, aber die Regel ist:
- RNG k-epsilon bricht ab wegen bounding epsilon oder bounding k
- SST k-omega bricht ab wegen time step continuity errors (Summe wird sehr groß)

Nun hab ich schon die verschiedensten Einstellungen probiert, aber leider hilft nichts so richtig oder verschiebt nur den Abbruchzeitpunkt.
Vielleicht gibt es ja hier noch die eine oder andere Anregung, sodass es doch noch was wird mit den Rechnungen.

PS: Nebenbei führe ich eine rasCavitatingFoam Simulation (auch mit dem gleichen Modell) durch. Die lief stabil durch, aber lieferte unglaublich große unphysikalische Drücke und Geschwindigkeiten. Gibt es denn eine Regel oder Faustformel, wovon die Länge und die Schrittweite einer Rechnung abhängt?

Viele Grüße!

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo,

nebenbei erwähnt schlägst sich eine Freundschaft auch mit dem rasCavityFoam herum und ich kann bestätigen, dass auch er super hohe Drücke erhält. Da scheint noch ein Grundlagenproblem bei diesem Solver zu sein...

Zitat:
wovon die Länge und die Schrittweite einer Rechnung abhängt?

Das ist jetzt vom Löser abhängig. Wenn du einen PISO verwendest, würde ich mal nach der Courant Zahl schauen: http://de.wikipedia.org/wiki/CFL-Zahl

Gruß Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo,

ich hätte mal eine allgemeine Frage zu den time step continuity errors.

Ich verwende aktuell den rhoPorousSimpleFoam solver. Dieser schreibt für jeden Zeitschritt verschieden time step continuity errors. z.B:

time step continuity errors : sum local = 7.71772e-08, global = -1.27783e-08, cumulative = 0.216318

Was bedeuten diese genau? Und wie groß darf welcher Wert werden, so dass ich noch von einem vernünftigem Ergebnis ausgehen kann?

Mit freundlichen Grüßen
Chrisi

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo Thomas,
danke für deine Antwort. Also die Abschätzung der Schrittweite hatte ich mithilfe der Co-Zahl schon durchgeführt.

zu rasCavitatingFoam: Also ich weiß halt echt nicht, woran es liegt... Wenn dein Bekannter auch ebenfalls so große Drücke bekommt, dann stimmt mich das nicht so zuversichtlich. Aber mein Vorgänger soll wohl vernünftige Rechnungen dammit durchgeführt haben, aber leider hab ich seinen case nicht zur Verfügung.
Ich werde mal versuchen, das Tutorial durchzuführen und dann weitersehen, ob ich es auf mein Beispiel anwenden kann.

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

@Chrisi:

Ich kann nur kurz antworten... wieder stress

Zitat:

Erros presented as:
- sum local: sum of continuity errors in each cell
- global: across the boundary of the domain
- cumulative: global error accumulated over time

@bephi: Vielleicht kann ich euch beide in Verbindung bringen???

Gruß Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo,
leider hab ich es noch nicht in den Begriff bekommen und ich bekomme jetzt fast immer Abstürze wegen dem time step continuity errors. Ich dachte wenn ich für writeControl adjustableRunTime wähle, dann passt er sich die Schrittweite selber an und das Problem sollte nicht mehr auftauchen... Könnt ihr vielleicht nochmal kurz sagen, wodurch solch ein Fehler verursacht wird und was idR dagegen getan wird? Weil soviele scheinen ihn ja nicht zu haben...

Code:

Time = 0.02255
DILUPBiCG: Solving for Ux, Initial residual = 9.61828e-05, Final residual = 4.24765e-06, No Iterations 2
DILUPBiCG: Solving for Uy, Initial residual = 0.000134347, Final residual = 2.86692e-06, No Iterations 3
DILUPBiCG: Solving for Uz, Initial residual = 4.02222e-05, Final residual = 2.36364e+27, No Iterations 1001
DICPCG: Solving for p, Initial residual = 1, Final residual = 0.00964546, No Iterations 22
DICPCG: Solving for p, Initial residual = 0.093425, Final residual = 0.000902955, No Iterations 71
DICPCG: Solving for p, Initial residual = 0.00620905, Final residual = 5.95986e-05, No Iterations 105
time step continuity errors : sum local = 4.84518e+20, global = 6.73707e+19, cumulative = 6.73707e+19
63 additional processes aborted (not shown)

Vielen Dank!

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo,
irgendwas ist bei Uz im Argen. Kannst du deinen Fall genauer beschreiben? Spielt sich bei dir das meiste in z-Richtung ab?

Gruß
ThomasS

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hallo Thomas,
also rechne ein Modell eines vertikalen Kolbenventils und gebe mir oben am Einlass eine Geschwindigkeit z.B. mit (0 0 -1.04) vor. Also nur eine z-Komponente. Am Auslass habe fixed value für den Druck.

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Steady state läuft es ok auf dem selben Gitter? Also konvergiert runter bis zu einem bestimmten Level?
Und oszilliert dann zum Beispiel?

ThomasS

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Mein Problem ist irgendwie, dass es manchmal klappt und manchmal nicht... Ich führe die Rechnungen dann mit 8 verschiedenen Eintrittsgeschwindigkeiten durch und will mir die Druckabfälle an den Drosselbohrungen anschauen, aber sobald die Geschwindigkeit zu hoch wird, tritt wahrscheinlich auch Kavitation auf und die Rechnung macht ne Biege... Das ist aber auch nicht immer der Fall und zum Teil bekommt man auch für hohe Geschwindigkeiten "realistische" Ergebnisse, die aber nich so schön konvergieren, wie bei niedrigen Geschwindigkeiten.
Ist denn das Abschätzen von k und omega wirklich von so großer Bedeutung?

EDIT: Du sprichst auch steady-state an. Da habe ich noch ein kleines Verständnisproblem. Was unterscheidet denn bei openFoam stationäre Rechnungen von transienten? Meine Geschwindigkeiten am Einlass halte ich ja konstant. Zu Beginn der Rechnung werden für die Geschwindigkeitskomponenten immer nur wenige Iterationen benötigt und die meisten Iterationen benötigt p. Bei dem Abbruch aber (siehe oben) sind ja die Iterationen eindeutig bei U_z zu hoch. Kommt die Berechnung jetzt erst bei dem Teil der Geometrie an, der sehr fein vernetzt ist und wo große Geschwindigkeitsänderungen auftreten oder wird stets in jedem Zeitschritt jede Zelle berechnet?

Da stellt sich mir auch die Frage, wenn es von oben nach unten durchgerechnet werden sollte, wie lang ich die Rechnung dann normalerweise laufen lassen sollte. Bis das Ergebnis konvergiert ist oder bis die Strömung einmal komplett durch die Geometrie geströmt ist?

Viele Grüße!

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

[Diese Nachricht wurde von bephi am 08. Jun. 2010 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Ich habe jetzt nochmal eine Rechnung gestartet und alles läuft soweit gut und dann auf einmal bricht er ab. Diesmal ist allerdings nicht U_z sondern U_x verantwortlich:

Code:

Time = 0.009216
DILUPBiCG: Solving for Ux, Initial residual = 7.03068e-05, Final residual = 8.62915e-07, No Iterations 4
DILUPBiCG: Solving for Uy, Initial residual = 8.86516e-05, Final residual = 6.61131e-06, No Iterations 2
DILUPBiCG: Solving for Uz, Initial residual = 4.36736e-05, Final residual = 7.02592e-07, No Iterations 3
DICPCG: Solving for p, Initial residual = 6.84149e-07, Final residual = 9.55466e-08, No Iterations 67
DICPCG: Solving for p, Initial residual = 7.42541e-07, Final residual = 9.35941e-08, No Iterations 7
DICPCG: Solving for p, Initial residual = 1.63758e-07, Final residual = 9.84311e-08, No Iterations 1
time step continuity errors : sum local = 1.77059e-09, global = 2.25009e-10, cumulative = 3.93352e-07
DILUPBiCG: Solving for omega, Initial residual = 7.54699e-06, Final residual = 5.05242e-07, No Iterations 2
DILUPBiCG: Solving for k, Initial residual = 9.39811e-06, Final residual = 4.15949e-07, No Iterations 2
ExecutionTime = 2927.67 s ClockTime = 2930 s
Time = 0.009218
DILUPBiCG: Solving for Ux, Initial residual = 6.90198e-05, Final residual = 4.30807e+25, No Iterations 1001
DILUPBiCG: Solving for Uy, Initial residual = 8.58077e-05, Final residual = 7.7175e-06, No Iterations 3
DILUPBiCG: Solving for Uz, Initial residual = 4.39214e-05, Final residual = 6.37199e-07, No Iterations 3
DICPCG: Solving for p, Initial residual = 1, Final residual = 0.00939632, No Iterations 40
DICPCG: Solving for p, Initial residual = 0.294145, Final residual = 0.00274622, No Iterations 20
DICPCG: Solving for p, Initial residual = 0.0461433, Final residual = 0.000424192, No Iterations 98
time step continuity errors : sum local = 8.75773e+19, global = 9.34851e+17, cumulative = 9.34851e+17
55 additional processes aborted (not shown)

Kommt er an dieser Stelle vielleicht zu einer schlechten Zelle oder so?

Zusätzlich habe ich hier mal den Verlauf der Residuen angehängt:

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

[Diese Nachricht wurde von bephi am 08. Jun. 2010 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hmmm. Gitter ist ok?
Kannst du mal dein checkMesh Output hier posten?

Zum Verständnis: konstante Randbedingungen müssen nicht zwangsläufig zu einer stationären Strömung führen. siehe Wirbelstrasse. Sobald also "eigentlich" instationäre Phänomeme vorhanden wären, dürfte es schwer fallen eine konvergierte Steady State Lösung zu erhalten. Es sein denn man nimmt ein grobes Gitter oder trickst sonst einwenig in der Numerik umher. Akkurat ist man dann natürlich nicht mehr.

ThomasS

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Danke! Der checkMesh output kommt morgen früh! Ist aber eigentlich okay.. Vielleicht siehst du trotzdem was.

Okay, also dann sollte ja bei der nicht so leichten Geometrie eine instationäre Strömung vorliegen, die nicht zu jeder Zeit gleich in die Ecken und Vertiefungen fließt, richtig!? Wie siehts dann also mit der Zeit aus? Hat die Start-/Stopp-zeit und Zeitschrittweite irgendetwas mit der physikalischen Zeit oder Dauer zu tun, die die Strömung benötigt, um einmal komplett durch die Geometrie zu fließen?

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Ja bei transienten Berechnungen ist gerade das Zusammenspiel Zeitschrittweite, Zellengröße und Geschwindigkeit entscheidend. Die Courant oder CFL Zahl sollte 1 nicht überschreiten, nirgendwo, um ganz sicher zu gehen.
Ohne die Geomtie zu kenn, nehme ich mal an, dass du gerade im Bereich der hohen Geschwindigkeiten fein aufgelöst hast?
Du kannst dein steady state Ergebnis nutzen um die benötigte Zeitschrittweite abzuschätzen.

Gruß
ThomasS

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Ja also die Co-Zahl hatte ich schon ganz am Anfang immer abgeschätzt, als ich laminar gerechnet habe. Meine Schrittweite liegt jetzt bei 10e-7, obwohl eigentlich 3.5e-5 ausreichen würden. Außerdem ist die Co-Zahl ja laut controlDict begrenzt durch den adjustableTimeStep.
Das sollte eigentlich abgesichert sein. Gibt es sonst noch mögliche Ursachen für die Abbrüche?

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Wie gesagt, hier die Ausgabe des checkMesh:

Code:
Create time
Create polyMesh for time = constant
Time = constant
Mesh stats
points: 264075
faces: 2299690
internal faces: 2198160
cells: 1083085
boundary patches: 10
point zones: 0
face zones: 0
cell zones: 2
Number of cells of each type:
hexahedra: 0
prisms: 165510
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 917575
polyhedra: 0
Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).
Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
wall 46560 24275 ok (non-closed singly connected)
inlet 71 51 ok (non-closed singly connected)
outlet 35 27 ok (non-closed singly connected)
symmetry1 14759 8493 ok (non-closed singly connected)
symmetry2 4076 2613 ok (non-closed singly connected)
kolbenstange 2927 1750 ok (non-closed singly connected)
fenster 3151 1645 ok (non-closed singly connected)
steuerkanten_unten 14426 7386 ok (non-closed singly connected)
steuerkanten_oben 5965 3147 ok (non-closed singly connected)
drosselbohrungen 9560 5012 ok (non-closed singly connected)
Checking geometry...
Overall domain bounding box (-0.0275 -0.0194454 -0.2) (-2.77556e-19 0.019445 4 0.175)
Mesh (non-empty) directions (1 1 1)
Mesh (non-empty, non-wedge) dimensions 3
Boundary openness (-2.03019e-15 -7.26158e-16 -5.23735e-18) OK.
Max cell openness = 6.5676e-16 OK.
Max aspect ratio = 20.867 OK.
Minumum face area = 4.02052e-12. Maximum face area = 9.85618e-05. Face area magnitudes OK.
Min volume = 4.51572e-18. Max volume = 2.82205e-07. Total volume = 0.000134 676. Cell volumes OK.
Mesh non-orthogonality Max: 66.2831 average: 16.4084
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 2.47072 OK.
Mesh OK.
End

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

checkMesh sieht ok aus.
Hast du die Chance ein hexa Gitter zu erstellen? Eventuell mit snappy?
Ist dein Geometrie geheim?

Gruß
ThomasS

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Ein Hexa-Netz hab ich schon versucht, aber das sieht bisher noch nicht schön aus, wenn ich die Grenzschichten hinzufüge.
Die Geometrie darf ich wahrscheinlich nicht rausgeben.

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Hmmm,
wie hoch werden denn deine Geschwindigkeiten lokal?

Gruß
ThomasS

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Also die Geschwindigkeit am Einlass (Kreisringquerschnitt mit 36mm außen und 25mm innen) gebe ich mir mit 1,04 m/s vor. Irgendwann trifft die Strömung dann auf die Drosselbohrungen, die in der Anzahl variieren, aber alle einen Durchmesser von 1,7mm besitzen. Somit ergeben sich Maximalgeschwindigkeiten im Bereich 50-80 m/s.

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Ok, und hast du mal die Lösung kurz vor dem Abschmieren angesehen?
Wie hoch werden die Geschwindigkeiten?

ThomasS

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Also die Residuen werden ja (wie oben gezeigt) von den Geschwindigkeitskomponenten sehr sehr groß kurz vorm Abbruch. Wie kann ich mir denn die Werte für die Geschwindigkeit selbst vorm Abbruch anschauen?

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

In der Standardversion von OF sollte zumindest ein min max function object sein, mit dem man sich per Iteration die min max Werte anziegen lassen kann. Soweit ich weiss.

ThomasS

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Also wenn ich zum Beispiel den rasCavitatingFoam-solver laufen lasse, dann erscheinen im log-file pro Zeitschritt auch die von dir benannten max-min-Werte. Aber beim simpleFoam bekomm ich halt nur diese Angaben:

Code:
Time = 0.009218
DILUPBiCG: Solving for Ux, Initial residual = 6.90198e-05, Final residual = 4.30807e+25, No Iterations 1001
DILUPBiCG: Solving for Uy, Initial residual = 8.58077e-05, Final residual = 7.7175e-06, No Iterations 3
DILUPBiCG: Solving for Uz, Initial residual = 4.39214e-05, Final residual = 6.37199e-07, No Iterations 3
DICPCG: Solving for p, Initial residual = 1, Final residual = 0.00939632, No Iterations 40
DICPCG: Solving for p, Initial residual = 0.294145, Final residual = 0.00274622, No Iterations 20
DICPCG: Solving for p, Initial residual = 0.0461433, Final residual = 0.000424192, No Iterations 98
time step continuity errors : sum local = 8.75773e+19, global = 9.34851e+17, cumulative = 9.34851e+17
55 additional processes aborted (not shown)

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

Also ich hab nochmal die Zeitschrittweite verändern bzw. auch die Rechenlänge und jetzt brechen die Rechnungen aber immernoch ab. Jedoch anscheinend nicht, weil ein Parameter zu groß wird, sondern weil anscheindend liegts aum cumulative error...

Code:

Time = 0.36632
DILUPBiCG: Solving for Ux, Initial residual = 0.00824517, Final residual = 9.88361e-05, No Iterations 3
DILUPBiCG: Solving for Uy, Initial residual = 0.0064465, Final residual = 0.000300608, No Iterations 2
DILUPBiCG: Solving for Uz, Initial residual = 0.00537108, Final residual = 0.00025516, No Iterations 2
DICPCG: Solving for p, Initial residual = 2.65796e-06, Final residual = 9.871e-08, No Iterations 596
DICPCG: Solving for p, Initial residual = 2.14212e-06, Final residual = 9.98308e-08, No Iterations 6
DICPCG: Solving for p, Initial residual = 2.77798e-07, Final residual = 9.98884e-08, No Iterations 1
time step continuity errors : sum local = 19.0478, global = 0.389618, cumulative = 62677.8
DILUPBiCG: Solving for omega, Initial residual = 0.000462361, Final residual = 4.33417e-05, No Iterations 2
DILUPBiCG: Solving for k, Initial residual = 0.000899215, Final residual = 5.3798e-05, No Iterations 1
ExecutionTime = 25137.2 s ClockTime = 25158 s
Time = 0.36633
DILUPBiCG: Solving for Ux, Initial residual = 0.0126915, Final residual = 0.000657026, No Iterations 2
DILUPBiCG: Solving for Uy, Initial residual = 0.00954027, Final residual = 0.000545504, No Iterations 2
DILUPBiCG: Solving for Uz, Initial residual = 0.00808909, Final residual = 0.000426527, No Iterations 2
DICPCG: Solving for p, Initial residual = 7.40292e-07, Final residual = 9.93734e-08, No Iterations 45
DICPCG: Solving for p, Initial residual = 5.64208e-07, Final residual = 9.98093e-08, No Iterations 4
DICPCG: Solving for p, Initial residual = 1.38451e-07, Final residual = 9.08471e-08, No Iterations 1
time step continuity errors : sum local = 11.0104, global = -0.956176, cumulative = 62676.9
63 additional processes aborted (not shown)

Außerdem habe ich mal meinen Residuenverlauf angehängt. Was ist denn ein möglicher Grund, dass die Residuen immer mal wieder ausbrechen, dann wieder zu konvergieren scheinen und dann wieder ausbrechen?

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP