---

Hallo,
ich lerne gerade OpenFoam und habe dazu ein klassisches Beispiel zur Überprüfung der Rechenergebnisse herangezogen: Es geht um eine laminare Rohrströmung mit Wasser. Das Rohr soll 10mm Durchmesser haben, bei einer Länge von 1m. Die Eintrittsgeschwindigkeit soll 0,1m/s betragen, am Auslass 0 Pa Druck. Analytisch lässt sich die Rechnung sehr leicht mit dem Gesetz von Hagen-Poiseulle nachrechnen. Das Ergebnis ist 32 Pa.
Mit simpleFoam komme ich auf ganz andere Werte. Ich dabei so vorgegangen: Das Rohr wurde als "Stange" mit einem Durchmesser von 10mm und 1m Länge mit Solidworks modelliert und als Step abgespeichert. Mit Salome wurde dann vernetzt, beim Import auf die Einheit mm/m geachtet! Das Netz dann als UNV File exportiert und mit OpenFoam konvertiert. Dann wurde die Turbulenz abgeschaltet und mit SimpleFoam gerechnet.
Am Ende der Berechnung habe ich den Befehl "postProcess -func 'totalPressureIncompressible(p,U)" genutzt. Ergebnis sind 0,006 Pa. Das widerspricht dem analytischen Ergebnis deutlich. Zweiter Ansatz war das Nutzen des Befehls "postProcess -func 'patchAverage(name=inlet,p')". Da kommen dann (wenn man den Output noch mit der Dichte Multipliziert) 56 Pa heraus. Auch eine starke Abweichung. Woher kommen diese Abweichungen? Klar gibt es Differenzen, aber zum Vergleich: Mit Solidworks Flow Simulation lande ich bei 37 Pa.

Hier ist der komplette Case für simpleFoam (ggf. die decomposepardict anpassen) :

https://drive.google.com/file/d/0BwY586Nmlij8Ym8zLWhaRDJMYk0/view?usp=sharing

Ich arbeite mit OpenFOAM+v1612 unter Ubuntu 16.04 (ohne Docker).
Grüße,

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

---

simpleFoam ist ja prinzipiell für den turbulenten Fluß geeignet. Es lohnt sich meiner Meinung nach zu prüfen, ob nicht in Grenzschichtnähe turbulente Effekte berechnet werden, welche dann freilich eine turbulente Scheinreibung hervorrufen. Bei Re=1000 kann das schon sein.
Der Vergleich mit isoFoam kann auch lohnen.

Wenn das nicht weiterhilft: Es lohnt weiter zu prüfen, ob das Geschwindigkeitsprofil über dem Querschnitt quadratisch ist.

Wenn du auch dann keine Ursache findest, rate ich, die Parameter einzeln zu ändern: Den Radius, die Strömungsgeschwindigkeit, die Rohrlänge, die Zähigkeit. Und dann prüfen, ob sich wenigstens die Änderungen analog zum Hagen-Gesetz verhalten. Du solltest dann die "Ecke" finden, an der die Simulation klemmt.

------------------
Uwe Pilz
--
Sie ahnen nicht, wieviel Poesie in der Berechnung
einer Logarithmentafel enthalten ist (Carl Friedrich Gauß)

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

---

Hallo Uwe,

mich würde interessieren woher deine Äußerung rührt, dass simpleFoam für turbulente Strömungen verwendet werden sollte und bei Laminarer versagt?

Für mich ist das eindeutlich das numerische Netz + Schemen.

------------------
Viele Grüße,
Tobias Holzmann

OpenFOAM Tutorials | Publikationen | Für Anfänger wiki.openfoam.com

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

---

> dass simpleFoam für turbulente Strömungen verwendet werden sollte und *bei Laminarer versagt*?

Da hast du mich falsch verstanden: Ich meine nicht, dass es simpleFoam bei laminarer Strömung zwangsläufig versagt. Es kann aber sein, dass bei ungünstig gestaltetem Netz überhaupt turbulente Effekte als (falsches) Rechenergebnis entstehen können.

------------------
Uwe Pilz
--
Sie ahnen nicht, wieviel Poesie in der Berechnung
einer Logarithmentafel enthalten ist (Carl Friedrich Gauß)

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

---

Ich habe es einmal versucht durchzurechnen - mit dem Netz stimmt etwas nicht.
Nach

Code:

---

writeCellCentres -latestTime

---

sind die Felder für x/y, z und U ungleich groß. Lediglich U enthält genau so viele Daten wie Zellen, alle anderen enthalten mehr. Das sieht man auch in paraFoam: Es wird nicht auf die Geometrie zentriert.
x/y enthalten mehr Einträge als z. Gibt es hier zweidiemensionale Zellen?

Meine Mitschriften aus der Konsole (Ordner 194, das war der letzte Iterationsschritt):

Code:

---

$ cat ccx | wc -l
1138396

$ cat ccy | wc -l
1138396

$ cat ccz | wc -l
1137672

$ cat U | wc -l
910831

---

U ist korrekt. Es enthält ein paar Zeilen mehr als Zellen (910783), weil es ja den Dateikopf und die schließenden Klammern gibt.

------------------
Uwe Pilz
--
Sie ahnen nicht, wieviel Poesie in der Berechnung
einer Logarithmentafel enthalten ist (Carl Friedrich Gauß)

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

---

Hallo Uwe,

ich persönlich wäre vorsichtig mit vorschlüssigen Äußerungen dieser Art. Sollte deine Hypothese stimmen, dann müsste FOAM crashen. Was du machst ist prinzipiell richtig aber ein Vergleich zwischen U und denn Zellmittelpunkten ist ganz klar unsinnig, da U auch noch die Randbedingungen enthält. Zudem ist der Header denn du bei U erwähnst, in jeder anderen FOAM Datei auch zu finden und ist immer identisch. Hier meine Punkte:

• wc -l wäre für mich nur sinnvoll wenn es sich um eine ASCII Datei handelt; tut es hier aber nicht - bzw. du hast es nicht umgestellt. Ob es ein Argument für Binäre Dateien gibt weiß ich adhoc nicht aber das Manual wirds schon wissen.
  
• Ein Vergleich der Einträge würde ich höchstens mit dem folgenden Befehl prüfen (wenn überhaupt) - auch nur auf ASCII:
  

Code:

---

grep -A 1 'internalField' 200/*

---

Das gibt dir sowas:

Code:

---

20/ccx:807:internalField   nonuniform List<scalar>
20/ccx-848-910783
--
20/ccy:807:internalField   nonuniform List<scalar>
20/ccy-848-910783
--
20/ccz:807:internalField   nonuniform List<scalar>
20/ccz-848-910783
--
20/p:806:internalField   nonuniform List<scalar>
20/p-847-910783
--
20/phi:812:internalField   nonuniform List<scalar>
20/phi-853-1707790
--
20/U:806:internalField   nonuniform List<vector>
20/U-847-910783

---

Und zeigt dass alle Felder gleich groß sind. Aber wenn checkMesh funktioniert, dann ist alles okay. Ich weiß nicht welche Methode SolidWorks verwendet aber ich Tippe mal auf FEM. Ich mag Tetreader bei Fluiden nicht wenn es um die FVM geht.  Alleine schon deswegen: http://www.holzmann-cfd.de/index.php/en/numerical-schemes

Ich würde die numerischen Schemen erstmal ändern und wenn das nichts bringt, dann einfach das Netz als Hexadominant.

------------------
Viele Grüße,
Tobias Holzmann

OpenFOAM Tutorials | Publikationen | Für Anfänger wiki.openfoam.com

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

---

> Zellmittelpunkten ist ganz klar unsinnig, da U auch noch die Randbedingungen enthält.

Meiner Meinung nach wird bei der Finite-Volumen-Methode U für die Zellmittelpunkte und der Druck für die Flächen berechnet. Bei mir war cellcentres und U immer gleich. Und selbst wenn es Randbedingungen gibt, die in U schreiben: Hier sind es mehr Koordinaten als Geschwindigkeiten, das müßte anders herum sein.

Ich habe die Dateien in ascii umgewandelt, das hätte ich erwähnen sollen. Ich habe auch die Header verglichen, und habe mir die Dateien auch einzeln angesehen. Meine wc -l-Ausgaben sind nur die Kurzfassung.

Was insbesondere verwunderlich ist, Beispiel ccx: Vor den Werten steht deren Anzahl, im Beispiel 910783:

Code:

---

dimensions      [0 1 0 0 0 0 0];

internalField   nonuniform List<scalar>
910783
(
-0.00231205
0.00163978
-0.000825612

---

Geliefert werden aber 1138364, hab's an den Zeilennummern meines Editors geprüft und den Header abgezogen. Hier stimmt etwas nicht. Es kleben auch nicht Tausende Zeilen hinten dran, die Datei endet auf

Code:

---

--0.00028611
-4.91505e-018
)
;
    }
}

// ********************************* //

---

( ****-Kommentar gekürzt).

Übrigens: Alle zellbasierten Felder, also U, ccx, ccy und ccz haben denselben identische Längenangabe 910783, was identisch ist mit der Anzahl der Zellen:

Code:

---

Mesh stats
    points:           214680
    faces:            1935342
    internal faces:   1707790
    cells:            910783
    faces per cell:   4
    boundary patches: 3
    point zones:      0
    face zones:       0
    cell zones:       0

---

Ich bin überzeugt, dass hier etwas nicht stimmt.

------------------
Uwe Pilz
--
Sie ahnen nicht, wieviel Poesie in der Berechnung
einer Logarithmentafel enthalten ist (Carl Friedrich Gauß)

[Diese Nachricht wurde von piu58 am 29. Mrz. 2017 editiert.]

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

---

Grüß dich Uwe,

ich möchte nicht so rüber kommen als würde ich es besser wissen aber ich arbeite mit FOAM seit über Sechs Jahren ohne GUI und all dem Wirrwarr (nur VIM). Meine Anmerkungen:

• FOAM rechnet Druck und Geschwindigkeit und alle anderen Größen im Zellmittelpunkt
  
• Heißt also wir verwenden ein colocated Grid und kein staggered Grid; das macht Fluent übrigens auch
  
• Würden wir ein staggered Grid verwenden, dann würden wir auch nicht den Druck auf der Fläche berechnen (wie du erwähnt hast) sondern die Geschwindigkeit
  
• Auf was du wohl anspielen willst ist wahrscheinlich die Problematik wenn beide Größen im Zellzentrum berechnet/gespeichert werden (Oszillationen). Allerdings verwenden wir die Rhie-Chow Interpolationsmethodik um dem engegenzuwirken (Fluxes an den Faces)
  

Was du mit deinen Zellzentren und U Analyse machst ist mir nicht schlüssig. Bei mir sind alle Felder exakt identisch mit genau 910783, dass exakt zu checkMesh und allen andern Files passt. Ich habs nun erwähnt und wenn man dazulernen möchte gerne, anderenfalls auch gerne 

------------------
Viele Grüße,
Tobias Holzmann

OpenFOAM Tutorials | Publikationen | Für Anfänger wiki.openfoam.com

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

---

Ich danke Euch für die Beiträge. Ich werde mich vorr. am Wochenende mal an die Arbeit machen. Feedback hier im Thread natürlich.

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

---

Nachdem Tobias und ich ein paar interne Details diskutiert haben, die dir aber wohl nicht weiterhelfen, einige Hinweise von mir.

Generell ist Fluiddynamik kompliziert. Sich irgendwoher eine Geometrie zu besorgen und damit zur rechnen, führt nicht automatisch zu physikalisch oder technisch richtigen Ergebnissen. Ein erstes Beispiel erlebst du gerade. Dabei hast du hier noch Glück, dass du mit etwas beginnst, wo es Literaturwerte gibt: So weißt du wenigstens, das etwas nicht stimmt. Wie nun weiter?

Wenn du OF nimmst, dann solltest du dich auch voll darauf einlassen. Ich würde für dieses einfache Beispiel keine externen Vernetzer/Netzkonverter benutzen. Da weiß man nie, wie das Netz wirklich ist. Ich habe mir dein Netz in paraFoam angesehen, und das sieht von der Struktur sehr gut aus. Dennoch gibt es "Effekte" zumindest bei mir.

Tobias hat schon angesprochen, dass wir von Tetraëderelmenten abraten. Der Grund dafür: Im Inneren von Zellen können die Flußgrößen generell nicht physikalisch richtig abgebildet werden, sondern müssen durch ein Modell angenähert werden ("Ansatz").In Tetraëdern kann man  auf Grund der vorhandenen Freiheitsgrade nur lineare Ansätze wählen, z.B. der Druck kann sich also zwischen den Flächen nur linear ändern. Hexaëder ("Würfel" und deren Abkömmlinge) sind viel besser, hier sind quadratische Ansätze eingebaut. Die Flußgrößen ändern sich parabelförmig.

Die Modelle innerhalb der Zellen sind ja nun nicht physikalisch exakt. Der numerische Effekt, der sich daraus ergibt, ist die künstliche Diffusion: Ein Geschehen, was in der Wirklichkeit eng begrenzt ist, verquirlt sich auf ein größeres Gebiet. Es ist allgemein üblich, für ernsthafte Arbeiten wenigstens quadratische Ansätze zu nehmen, um diese numerische Diffusion in Grenzen zu halten.

Dein Beispiel ist axialsymmetrisch. Im laminaren Fall ändern sich die Flußgrößen mit dem Winkel auch nicht. Es genügt  deshalb, einen schmalen Sektor von wenigen Grad zu berechnen. Den kannst du entweder selbst bauen (in der Mitte ein keilförmiges Element und darauf Hexaeder) oder du benutzt das Programm makeAxialMesh von dieser Seite (musst du selbst bauen, Makefile ist dabei).

Diese einfache Geometrie rechnet dann auch nicht mehrere Stunden, sondern ein paar Minuten. Damit kannst du ausprobieren:
- Wie ändert sich die Lösung mit dem Solver?
- Wie ändert sich die Lösung bei unterschiedlich großen Zeitschritten?
- Wie ändert sie sich bei feiner aufgelöstem Netz? Lohnt es, das Netz in Wandnähe zu verfeinern?

All das sollte zu Erkenntnissen führen.

------------------
Uwe Pilz
--
Sie ahnen nicht, wieviel Poesie in der Berechnung
einer Logarithmentafel enthalten ist (Carl Friedrich Gauß)

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

---

Noch ein kleiner Beitrag von mir. Du wirst ja eine konstante Geschwindigkeit auf dem Eintritt vorgeben. Daher muss sich noch entlang der Rohrlänge ein laminares Geschwindigkeitsprofil ausbilden. Dies hat in dem Einlaufbereich einen höheren Strömungswiderstand zur Folge. Bei der analytischen Berechnung des Druckverlusts wird davon ausgegangen, dass das laminare Geschwindigkeitsprofil voll ausgebildet ist.

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