---

Hallo zusammen,

ich bekomme bei meiner rhoSimpleFoam Simulation ständig Rechenabbrüche wegen einer Gleitkomma-Ausnahme (Floating Point Exception). Nachdem ich recherchiert habe bin ich auf folgende mögliche Ursachen/Abhilfen gestoßen:
- zu viele nicht-orthogonale Zellen im Netz
- zu wenig non-orthogonality-correctors verwendet
- upwind-Differenzierung in divSchemes verwenden
- Startbedingungen mit simpleFoam oder potentialFoam ermitteln
- AMG Solver für Druck verwenden
- Diskretisierung von p bei laplacian von Gauss linear corrected zu Gauss linear limited ändern
-Druck und Geschwindigkeit Randbedingungen prüfen

Nun habe ich den selben case mit einer simplen Zylinder-Geometrie gerechnet, ohne erfolg. Also gehe ich davon aus, das mein Netz in Ordnung war (laut checkMesh OK).

Die Rechenabbrüche geschehen immer nachdem h gelöst wurde und bevor p berechnet wird.
Was könnte ich noch probieren? Gibt es noch irgendwelche Tricks?

Grüße,
Max

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

---

Hallo,

deine Randbedingungen sind wahrscheinlich noch nicht in Ordnung. Hast du mal ohne Turbulenz gerechnet? Es werden die Feldvariablen im Zeitordner Null noch falsch sein.

Gruß Thomas

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

---

Hallo Thomas,
ja das habe ich auch vermutet, jedoch läuft der gleiche case mit einer einfachen Geometrie durch. Ich habe nur den polyMesh Ordner ersetzt, und siehe da es geht.
Also habe ich gedacht es liegt am Netz. CheckMesh liefert mir jeodch keine Fehler, außer ein paar nicht-orthogonalen Zellen, und sagt "Mesh OK".
Komischerweise bekomme ich teilweise sehr hohe Geschwindigkeiten um die 30000 m/s. Ich habe aber nur 1m/s als Randbedingung. Könnte das am Netz liegen?
Ohne Turbulenz habe ich auch schon gerechnet, jedoch ohne Erfolg.

Ich habe mal die Randbedingungen für U und p angehängt, wäre super wenn du die mal kurz überfliegen könntest.

GESCHWINDIGKEIT U

internalField  uniform (0 0 0);

inlet                 
type        fixedValue;       
value      uniform (0 -1 0);
   
outlet         
type            zeroGradient;

wall   
type            fixedValue;
value          uniform (0 0 0);

DRUCK p

internalField  uniform 100000;

inlet
type      zeroGradient;

outlet
type            fixedValue;
value     $internalField;

wall 
type            zeroGradient;

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

---

Hallo Max,

rhoSimple hat nach meiner Erfahrung häufig ein "Dichte"problem, d.h. es kommt zu Solversabstürzen aufgrund einer negativer Dichte (resultierend aus starken Druckschwankungen während der ersten Iterationen). Meist hilft da nur: So gut wie möglich Initialisieren, Dichte in den ersten Iterationen sehr stark unterrrelaxieren ("einfrieren") (z.B. 0.001), dann warten bis sich sich stabiles Druckfeld ausgebildet hat (pmin und rho min/max im log-File verfolgen), dann kann die Dichterelaxation wieder zurück genommen werden.
Aber vorher checken ob T auch als absolute Temperatur definiert wurde.

Gruss

Ulrich

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

---

Hey Ulrich,
Danke für den Tipp.
ich werd das gleich bei den nächsten Durchläufen mal verfolgen und ggf. die Unterrelaxierung ändern.

Grüße,
Max

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

---

Hallo,
ich habe nun die Dichte-Unterrelaxierung ausprobiert, der case ist länger als sonst gelaufen, jedoch nachdem ich die relaxierung wieder gelockert habe, bricht er irgendwann (und noch zu früh) mit dem selben Fehler ab.

Dabei ist der Final residual für h bei 102.32 und 1001 durchgeführten Iterationen.
Ich vermute mal ich habe die Unterrelaxierung zu früh gelockert.
rho max/min ist konstant um die 0.87, das scheint ok zu sein.
"p min" wird mir im log nicht angezeigt, kann man das irgendwie aktivieren?

Temperatur ist absolut als 400K angegeben.
Ich habe mir die Ergebnisse in paraview angesehen, und die Druckwerte sind im normalen Bereich um 1 bar herum. Auch die U-Werte sind diesmal ok.

Ein problem ist auch dass die epsilon-Werte teilweise stark schwanken, von negativen Werten bis hin zu 10^8.
es wird dann "bounding epsilon" ausgegeben, ich nehme mal an dass damit die Werte begrenzt werden? Für die nächsten Rechnungen werde ich die Turbulenz wieder mal abschalten.

Woran kann ich denn abschätzen, ob das Druckfeld stabil ist oder nicht?

Grüße,
Max

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

---

Hallo Max,

entschuldige meine verspätete Antwort. Gerade viele Sachen zu tun.

Ich benutze den "rhoSimpleFoam" ziemlich oft in HVAC Bereich und ich muss dir sagen, dass es auch bei mir mal einen "rhoSimpleFoam"-Case gab, der mich fast zum Selbstmord trieb  

"bounding Epsilon" ist nicht unbedingt ein Fehler, wenn die Werte sehr klein bleiben. Manchmal verschwinden diese auch über die Zeit. Eine endgültige Lösung für solche Fälle habe ich aber auch noch nicht gefunden. Mir wurde mal gesagt, dass man die Nicht-Orthogonalität so klein wie möglich halten sollte (Mesh), ein anderes Schema für Epsilon oder k benutzen (Upwind), oder bessere Startbedingungen für die Turbulenz vorgeben , besonders für das "Internel Field" (höhere Werte vorgeben). Sehr stark unterrrelaxieren für k oder Epsilon hat den Abruch bei mir nur verzögert, war also auch keine Lösung.

Lösung bei mir: Ich habe es im Griff bekommen, dass einfach das Turbulenzmodell nicht für mein Case geeignet war.

Trotzdem sollte es nicht zu einem Gleitkomma-Ausnahmefehler kommen, auch wenn die Turbulenz ausgeschaltet ist. Ich vermute immer noch, dass deine Anfangsbedingung für den rhoSimpleFoam nicht gut beschrieben sind.

Code:

---

outlet
type      fixedValue;
value     $internalField;

---

Hast du hier mal was anderes ausprobiert?

Gruß Thomas

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

---

Hi Thomas,
ich habe $internalField durch verschiedene Absolutwerte ersetzt (z.b. uniform 100000), und habe inlet und outlet Bedingungen beim Druck vertauscht, jedoch leider ohne Erfolg. So langsam gehen mir die Ideen aus.

Ich habe noch die Vermutung, dass rhoSimple nicht mit meiner Geometrie zurechtkommt, da ich geometriebedingt quasi an mehreren Stellen eine Geschwindigkeitsänderung in die entgegengesetzte Richtung über einen kleinen Radius habe:
also das Gas strömt nacht rechts unten, und knickt über einen scharfen Radius nach links ab.

evtl. macht das irgendwelche Probleme?

Auch ohne Turbulenz ergeben sich keine Verbesserungen.
Ich bin mir nicht sicher, ob das Netz gut ist. Ich habe ca. 1/1000 nicht orthogonale Zellen, also ca. 150 von 150000.

Ansonsten kann ich, wie du geschrieben hast, nur falsche Startbedingungen vermuten, jedoch komme ich nicht dahinter wo der Fehler steckt...

Grüße,
Max

[Diese Nachricht wurde von StudentMax am 12. Apr. 2010 editiert.]

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

---

Hi,

jetzt bin ich neugierig und würde mir gerne mal den Fall ansehen wollen 

Bist du dir denn überhaupt sicher, dass "rhoSimpleFoam" für dein Case richtig ist? Vielleicht muss ein anderer Solver ran?

Gruß Thomas

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

---

Hi Thomas,
ich habe dir eine PM geschickt.

Ich möchte meinen Fall kompressibel mit Turbulenz rechnen, und die Strömung ist stationär bis auf die Turbulenz. Da bin ich bei rhoSimpleFoam gelandet. Ich habe auch dreimal mit rhoPisoFoam gerechnet, jedoch auch Abbrüche erhalten. rhoPiso hat etwas länger durchgehalten, aber ist auch irgenwann instabil geworden.

Da ich später auch noch Wärmeübertragung in die Wand mit einbauen will, habe ich überlegt, ob ich gleich mit einem Wärmeübertragungsfoam rechne, doch die basieren ja zum Teil auch auf SIMPLE. Ich denke da würde ich auch nicht weiterkommen, deshalb wollte ich den case erstmal mit rhoSimple zum laufen bringen.

Danke schonmal für die Mühe,
Grüße
Max

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

---

residuals-gnuplot2.JPG

Hallo,
ich habe nun eine laminare Berechnung mit rhoSimple durchgeführt, und erhalte beim plotten der Residuals den angehängten Graph. Nur was ist da ab Iteration 800 passiert?
Ab da schwanken die Werte um einen Mittelwert, ohne sich groß zu verändern....
Wurde hier bereits Konvergenz erreicht?

Grüße
Max

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

---

Hallo Max,

der Plot sieht doch gut aus. Deine Rechnung scheint jetzt gut zu laufen  Es scheint konvergiert zu sein.

Gruß Thomas

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

---

Hi Thomas,
alles klar, ich war nur etwas unsicher, weil die Werte im Zickzack schwanken.
Aber dann passt das ja,
vielen Dank,
Grüße
Max

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

---

residuals-plot1.png

Hallo zusammen,
ich habe nun wieder einmal das Problem mit plötzlichen Rechenabbrüchen.
Die Lösung scheint erst zu konvergieren, jedoch nach ca. 150 iterationen bricht der Solver wegen einer Floating Point Exception ab.  
Ich habe den Residual-plot als Grafik angehängt.

@Thomas: Du kennst den case ja schon, ich habe lediglich ein neues Netz verwendet, mit prismatischen Randschichten, erzeugt mit Ansys ICEM-CFD. Ansonsten habe ich erstmal alles bei dem case belassen, den du verbessert hast.

CheckMesh sagt das Netz ist ok, und auch mit anderen Netzen bringe ich den case nicht mehr zum laufen. Nachdem ich von dem funktionierenden case nur das Netz, also den polyMesh-Ordner ersetzt habe, muss es ja daran liegen!?

Evtl. ist es auch eine netzbezogene Einstellung, wie z.B. nNonOrthogonalCorrectors, oder die Parameter des GAMG Solvers...
Gibts es sonst noch netzbezogene Einstellungen, die ich übersehen habe, an denen es evtl liegen könnte?

Bin für jeden Tipp dankbar,
Grüße
Max

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

---

Hallo Max,

hmmm, als du den polyMesh Ornder ausgetauscht hast, hast du auch die "boundary"-Datei wieder angepasst? Darauf geachtet, was "patch" oder "wall" sein sollte?

Versuche mal die gleiche Berechnung mit der aktuellen OF 1.5-dev.

Gruß Thomas

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

---

Hi Thomas,
ja patch und wall habe ich in der boundary angepasst. Ok, ich versuche es jetzt mal mit der vorherigen Version, kann ich den case ohne Anpassungen damit laufen lassen?
Ich hab immer mal wieder gelesen, dass in 1.6 einiges neu prorammiert wurde und Wandfunktionen o.ä. anders aufgerufen werden oder solche Sachen...
Danke,
Grüße
Max

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

---

Hallo Max,

habe dein Case gerade nicht zur Hand. Versuche dein Case einfach mal in OF 1.5-dev zu starten. Sollte etwas fehlen, wird dir OF schon mitteilen, was es braucht.

Gruß Thomas

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

---

Hi Thomas,
also ich habe es mit der Windows-Version 1.5 probiert, da bringe ich den case gar nicht zum laufen. Erst Probleme mit der fvSolution-Syntax, dann hier und da...

Die 1.5-dev Version bekomme ich glaube auf meinem Linux-Rechner nicht zu installieren, ohne meine 1.6-Version zu zerstören...

Ich werde mal noch ein paar Netze erstellen mit verschiedenen Programmen und diese testen.
Wenn ich ein Netz mit feineren Zellen erstelle, muss ich da am GAMG Solver die Anzahl der Zellen im gröbsten Level anpassen,oder müsste das auch so gehen?

Ich muss sonst ja nur die nNonOrthogonalCorrectors ans Netz anpassen..?
Bis jetzt habe ich 1...5 nNonOrthogonalCorrectors verwendet, je nach Netz.
Laut Theorie sollte der case doch dann ohne Probleme laufen...

Grüße
Max

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

---

Hallo Max,

du kannst mehrere OpenFOAM Version parallel installieren. Ich mache das so, dass ich in meiner .bashrc immer einstelle, welche Version ich verwenden möchte.

Meine Installation sieht so aus:

OpenFOAM/OpenFOAM-1.5-dev
OpenFOAM/OpenFOAM-1.6.x
OpenFOAM/ThirdParty
OpenFOAM/ThirdParty-1.6.x

Wegen GAMG: http://www.tfd.chalmers.se/~hani/kurser/OS_CFD_2008/TimBehrens/tibeh-report-fin.pdf

Kannst du mir nochmal dein neuen Case senden? Ich mache dann daraus einen OF-1.5-dev Case...

Gruß Thomas

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

---

Hi Thomas,
durch verändern der Turbulenz-Randbedingungen (k und epsilon Startwerte) habe ich den case zum laufen gebracht.   Dadurch dass ich ausser dem Netz nichts verändert habe, waren nicht meine selbst berechneten Turbulenzwerte eingestellt. Offensichtlich ist der Solver durch die physikalisch sinnlosen Werte (aus dem Tutorial) gecrasht.

Ich bin jetzt ein paar Tage offline, und melde mich wieder wenn ich wieder Internet habe.
Vielen Dank für dein Angebot den case anzuschauen und zu konvertieren , ich komme gern darauf zurück (ich fürchte wenn ich alle BCs gesetzt habe und ein endgültiges Netz habe, gibt es bestimmt wieder Probleme mit dem Solver...)
Grüße
Max

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

---

Hallo,
wie kann man denn solche Risidual-Plots anfertigen und welche programme brauch man dafür ?
(->Dummerweise gibts dieses foamLog nicht bei der windows version von openfoam.)

LG Thomas

[Diese Nachricht wurde von Thomas Flath am 15. Nov. 2010 editiert.]

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