---

tk2umag.png tk2.tar.gz

Hallo FOAMer,

bei der Auswertung meines Cases (simpleFoam, k-epsilon) mit paraFoam kamen optisch schöne Bilder zustande, jedoch haben mich die entstandenen Werte etwas stutzig gemacht.

Zum Testen habe ich dann eine sehr einfache Geometrie erstellt - ein einfaches Rohr mit Innendurchmesser 7mm, welches in x-Richtung durchströmt wird. Ich gehe von einem Massenstrom von 70Gramm/Sek aus, und komme bei gegebenem Druck und Temperatur so auf eine Fluidgeschwindigkeit von knapp 60 m/s, welche ich am Inlet definiere.

Falls ihr mal nachrechnen wollt, hier ein paar Angaben:
Druck 100 bar,
Temperatur 500°C,
Dichte 30.476 kg/m³,
kin.Viskosität 0,9505*10^(-6) m/s²
Rohrdurchmesser 7mm (rund)

Im Bild erkennt man eine Einschnürung, die sich durch die Haftbedingung am Rand entwickelt. Der gemessene Druckunterschied im Rohr ist jenseits von Gut und Böse und die sich einstellende Höchstgeschwindigkeit in der Rohrmitte beträgt ca. 116 m/s (und ist damit gefühlt zu hoch).

Im Paraview schaut das Strömungsprofil parabelförmig (=> laminar) aus, jedoch sollte es laut der Literatur (zB Böswirth - Technische Strömungslehre) bei den vorliegenden hohen Reynolds-Zahlen eher flach (=> turbulent) sein. Wenn ich meine Werte in die dort gegebenen Formeln einsetze und zurück rechne, bekomme ich auch andere mittlere Geschwindigkeiten als Ergebnis. (also ca. 100 - 110 m/s)

Daher meine Frage:
Wie verifiziert ihr, ob eure Ergebnisse halbwegs realistisch sind!?
Und wenn nicht, wie geht ihr dann vor!?

Vielen Dank schonmal!

Gruß,
Christoph

------------------
...im CAD hats gepasst.

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

---

Hallo Christoph,

auf Grund deiner Angaben würd ich pauschal sagen das das doch gar nicht so schlecht ist. 110m/s verglichen mit 116 m/s ist für mich schon mal ein guter Wert. Nicht zu vergessen solltest du das in turbulenten Strömungen mit Modellen gerechnet wird und oft quantitativ falsche Ergebnisse vorliegen (siehe Ferziger). Für den Ingenieur ist zudem oft nur eine Tendenz notwendig, welches Design optimal ist. Auch wenn die quantitativen Ergebnisse oftmals abweichen, kann aufgezeigt werden, dass ein Optimum in der CFD oftmals auch ein Optimum im realen Design darstellt. Hier ist auch ein schönes Beispiel im Ferziger enthalten.

Zudem sehe ich auf deinem Plot definitiv ein sehr sehr sehr grobes Netz (zumindest scheint das auf der Linie so). Heißt, du hast grad mal 10 Zellen drin, rechnest wohl mit Wandfunktionen und y+ wird irgendwo im nirgendwo sein 

Solltest das definitiv prüfen und immer im Hinterkopf behalten - MODELLE - du rechnest erstens mit RANS, dann mit Turbulenzmodellen (hier ein Zwei-Gleichungs-Modell, das auch eine isotrope Dissipation annimmt). Nimmst du ein anderes Modell, dann wirst du feststellen, dass du wohlmöglich komplett andere Werte bekommst.

Validierung und Verifizierung von CFD Daten mach ich immer anhand von Messdaten oder korrekter Theorie.
Wenn ich kurz was auffassen darf: In meinem Lehrstuhl (Metallurgie) simulieren wir die Erstarrungsvorgänge von Metallschmelzen. Alles mit Modellen etc, was gute Ergebnisse liefert aber auch nur Modelle sind. Richtige Strömungslehrstühle, die mit DNS etc. rechnen lachen unseren Lehrstuhl sicher aus, dass eben alles was wir machen falsch ist, da nur Modelle verwendet werden. Man muss eben auch immer den Kostenaufwand zur Genauigkeit sehen.

Extreme Turbulenzen sind sowieso ein wahnsinns Thema und diese dann auch noch richtig aufzulösen bedarf es extrem feine Netze und hohe Rechenleistungen.

------------------
Best regards,
Tobias Holzmann

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

---

Zitat:

---

// OpenFOAM rechnet mit rho-normalized pressure p*=p/rho, rho = 30.4759 kg/m³

---

Bitte beachte, dass das nur bei inkompressiblen Lösern der Fall ist, da alle Gleichungen durch die Dichte geteilt werden (da rho = k.).
Auch bei der Auswertung den Druck wieder mit der Dichte multiplizieren, sonst passt das nicht.

------------------
Best regards,
Tobias Holzmann

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

---

tk2.png

Weitere Anmerkungen:

• Inlet und Outlet sind bei dir Wände und werden dann mit Wandfunktionen belegt (falsch)
  
• Inlet kann man mit wesentlich besseren Turbulenzapproximationen belegen
  
• Ein Rechner für Turbulenzgrößen findet sich auf cfd-online.com
  
• ResidualControl ist schon sehr vage. Bei 10-3 aufzuhören kann in Ordnung sein, muss aber nicht
  
• Netz ist nicht sonderlich gut für Wandfunktionen
  
• An der Wand verwendest du gar keine Wandfunktion (wenn du das nicht machen willst, muss das Netz sehr fein sein, y+ ~ 1)
  

Ich habe deinen Case neu aufgesetzt, und neu vernetzt. Ein Ergebnis (nicht auskonvergiert) ist im Anhang zu sehen. Unterscheided sich schon deutlich von deinem. Bei weiterem Voranschreiten der Simulation wird der Bereich von turbulenter Strömung hin zur Wand krasser, heißt die Steigung an wird größer. Zudem habe ich eine gemittelte Geschwindigkeit in nem Slice von 61 m/s, wobei am Einlass ca. 60 m/s vorliegen - passt also. Kann sein das ich eine falsche RB am Inlet genommen habe aber soweit sieht das meiner Meinung nach gut aus.

Hoffe das es dir weiterhilft.

------------------
Best regards,
Tobias Holzmann

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

---

Hey Tobias, vielen Dank dir!

Inkompressibel ist der Fall, (Ma = 0,09 < 0,3), den Druck korrigiere ich per Calculator-Filter.

Die Turbulenzgrößen habe ich selbst berechnet, und mit dem Tool auf cfd-online überprüft. Dieser kam weitestgehend auf die gleichen Ergebnisse. Wie würdest du die Turbulenzapproximationen ändern, und warum?

Grade eben rechne ich den gleichen Fall nochmal mit einem feineren Netz, und werde dann sehen wie sich das Ergebnis verändert. Bin ja auch noch ein OpenFOAM-Neuling und mich würde interessieren welchen Effekt die verschiedenen Features haben...

Könntest du mir deinen geänderten Case bitte mal hochladen /schicken? So könnte ich am besten sehen was du verändert hast. Das Strömungsprofil wie du es herausbekommen hast, hätte ich nämlich auch gerne, und die 61 m/s hören sich wesentlich plausibler an 

Gruß,
Christoph

------------------
...im CAD hats gepasst.

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

---

tk2.tar.gz

Hallo Christoph,

hab einiges geändert auch deine Triangulation finde ich nicht sehr gut. Trotz deiner feinen Auflösung kann man das wesentlich besser gestalten, vor allem weil ein Triangle bei dir über die ganze länge geht. In wie weit sich das negativ auswirkt kann ich nicht beurteilen aber mein sHM läuft wesentlich schneller durch (:

Code:

---

tar xzf *.tar.gz
ideasToUnv cad/backgroundMesh.unv
surfaceFeatureExtract
snappyHexMesh -overwrite
## remove entry defaultFaces
cp -r 0.org 0
simpleFoam

---

Was ich noch erwähnen möchte. Der in diesem Beispiel erreichte y+ Wert beträgt:

Code:

---

Patch 2 named wand y+ : min: 32.7592453 max: 52.6601447 average: 34.4478312

---

Für die Wandfunktionen sollte der Zellmittelpunkt der ersten Zelle im logarithmischen Bereich liegen (also nicht in der viskosen Unterschicht). Heißt y+ > 30 (laut Ferziger). Was du noch machen könntest wäre die Verwendung von Low-Re-Modellen. Low-Re bedeutet aber nicht das kleine Geschwindigkeiten in der Strömung vorherschen sondern viel mehr das bei Ablösungen andere Modelle oder auf das lineare Profil umgeschaltet wird.

• Turbulenzgröße k: turbulentIntensityKineticEnergyInlet (oder so ähnlich)
  
• Turbulenzgröße omega: turbulentMixingLenghtDissipationRateInlet (oder so ähnlich)
  
• Analog für epsilon
  

Für k und Epsilon hab ich grob überschlagen (frag mich aber nicht mit welcher Geschwindigkeit ich gerechnet hab), spielt auch keine Rolle bei den oben verwendeten Bedingungen, da die Werte für k, omega und epsilon berechnet werden (also besser wie fixedValue).

weiterer Hinweis
Hab mal U am outlet angegeben und p am Inlet, da dies physikalisch sinnvoller ist.
Dürfte aber keine Rolle spielen, außer das du einmal am Inlet keine Grenzschicht hast und einmal am Outlet.

------------------
Best regards,
Tobias Holzmann

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

---

Danke!

für das ideasToUnv brauche ich aber Salome oder?
Das hab ich noch nicht drauf, muss ich mir erstmal anschaun jetzt...

------------------
...im CAD hats gepasst.

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

---

Nein, das ist ein OpenFOAM Befehl und konvertiert das *.unv Mesh für OpenFOAM.

------------------
Best regards,
Tobias Holzmann

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

---

Zitat:

---

ideasToUnv cad/backgroundMesh.unv
ideasToUnv: Befehl nicht gefunden.

---

Nachdem ich den Befehl gegoogelt habe, kamen ein paar Hinweise auf Zusammenhänge mit Salome, daher dachte ich das kommt evtl daher...

edit:
meinst du evtl
ideasUnvToFoam??

------------------
...im CAD hats gepasst.

[Diese Nachricht wurde von Turbo Encabulator am 09. Apr. 2015 editiert.]

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

---

Jop genau den Befehl meine ich.

------------------
Best regards,
Tobias Holzmann

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

---

Ok, jetzt bin ich wieder einen Schritt weiter.

mit welchem Befehl removest du die default Faces?
"## remove entry defaultFaces" klingt eher ein wenig wie ein Kommentar aus einem Skript...
(und sonst wirft er mir auch einen Fatal Error "Cannot find patchField entry for defaultFaces...)  

edit:
Ich habs geschafft!
Ähnlich wie hier beschrieben, habe ich meine /constant/polyMesh umgeschrieben, die defaultFaces rausgelöscht und die Zahl am Anfang von 4 auf 3 gesetzt, jetz läuft der Löser zumindest schon mal an...

...obs richtig war, seh ich ja dann wenn er fertig ist 

Schönen Gruß,

Christoph

------------------
...im CAD hats gepasst.

[Diese Nachricht wurde von Turbo Encabulator am 09. Apr. 2015 editiert.]

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

---

Hallo Christoph,

alles richtig gemacht. Du könntest noch das inHouse Tool createPatch verwenden um die Einträge zu löschen. Alle Einträge mit nFaces 0 sind ohne Belangen, da kein Face zu dieser Boundary gehört. Kann man also löschen. Die Zahl zu Beginn gibt die Anzahl an Boundarys an. Da du eine rausgenommen hast, muss die Zahl natürlich um eins vermindert werden. Somit hast du alles richtig gemacht.

Sollte nun alles funktionieren, bitte ich das Thema als gelöst zu markieren (:

Danke und ein schönes erfolgreiches Weekend.

------------------
Best regards,
Tobias Holzmann

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

---

Also der Fall ist bei mir wunderbar durchgelaufen, und die Werte gefallen mir sehr gut!
Danke vielmals Tobias!

Aber damit tun sich auch gleich wieder neue Abgründe auf: Wie hast du den Case denn erstellt? (Wie erstellst du die backgroundMesh.unv? Wofür braucht man die cyclinder.hdf, und wie erstellt man die?)
Gibts dazu Veröffentlichungen die du mir empfehlen könntest?

Die regionSTL.stl muss ich mir auch nochmal anschauen, und für createPatch benötige ich noch eine createPatchDict...

------------------
...im CAD hats gepasst.

[Diese Nachricht wurde von Turbo Encabulator am 10. Apr. 2015 editiert.]

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

---

Hallo,

also ich habe die Geometrie in Salome Meca erstellt (Projekte haben die Endung *hdf). Mache dort auch immer mein Hintergrundnetz (*unv). Kannst aber auch mit BlockMesh machen.

www.salome-platform.org

Es gibt viele Wege die zum Ziel führen. Du entscheidest also.

createPatchDict findest du in OpenFOAM

Code:

---

find $FOAM_TUTORIALS -name "createPatchDict"

---

------------------
Keep Foaming | Viele Grüße,
Tobias Holzmann

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

---

Also das Salome-Meca hab ich mir jetzt mal kurz angeschaut, und hat mich auf den ersten Blick gleich mal ein wenig erschlagen. Ich glaube ich mach das vorerst lieber weiter mit blockMesh, da kenn ich mich schon ein wenig aus.

Wie hattest du das mit der Triangulation gemeint? Meinst du das der stl-Datei?
Die hab ich nämlich im Solid Works erzeugt, und das ist für stl anscheinend nicht so gut geeignet.
Das Gitter würde ich für diesen Fall hier in Salome wahrscheinlich noch hinbekommen, aber die Geometrie die ich eigentlich simulieren will ist dann doch ein Stück komplexer, insofern wärs schon toll das irgendwie im SW zusammenzubauen 

die y+ Werte hast du dir mit

Code:

---

yPlusRAS

---

ausspucken lassen, nehm ich an?

------------------
...im CAD hats gepasst.

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

---

Hallo,

Auf mit dem Befehl ,,yPlusRAS" bekommst du meines Wissens nach den y* Wert. Da bin ich selber mal drauf reingefallen. Für höhere y+ Werte sind die Abweichungen zu y* nicht ganz so ,,trastisch" (y+ > 20 in etwa).

gruß Marcel

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

---

@Christoph:

• Geometrie in SW erstellen und als STEP exportieren
  
• STEP in Salome importieren und dann dort die Oberflächen vernetzen
  
• Salome Meca kann sehr vieles (heute mal ne Helix gemacht, geht ganz einfach)
  

@Marcel

• yPlusRAS gibt dir den y+ Wert aus
  
• In meinem Lieblingsbuch finde ich gerade auch nichts über y*
  

Code:

---

Description
    Calculates and reports yPlus for all wall patches, for the specified times
    when using RAS turbulence models.

---

Um das Rätsel etwas deutlicher aufzulösen:

Berechnet wird:

Code:

---

return pow025(Cmu_)*y*sqrt(kwc)/nuw;

---

Das ist die gleiche Formel die auch im Ferziger auf Seite 353 Gleichung (9.39) vorliegt und somit eindeutig ein y+ liefert und kein y*.
Beachte, dass hier die Formel für inkompressible Strömungen verwendet wird. Bei Kompressiblen fehlt nur der Faktor Rho. Es wird in der Gleichung angenommen, dass sich die Strömung in Wandnähe im lokalen Gleichgewicht befindet. Heißt also das Produktion und Dissipation der kinetischen Energie  der Turbulenz ungefähr gleich groß sind.

Anderenfalls ist die Schubspannungsgeschwindigkeit:

Code:

---

sqrt(|tau_w|/rho)

---

das aber nich implementiert ist.

Gegenfrage:

• Wo liegt bei dir der Unterschied zwischen y+ und y* (Literatur)?
  

------------------
Keep Foaming | Viele Grüße,
Tobias Holzmann

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

---

Hallo,

Die Formel die du genannt hast wird zur Bestimmung von y* verwendet (CFD Schwarze S.152, Jahr 2013).

Y+ wird folgendermaßen bestimmt:
(nach Schlichting - Grenzschichttheorie, S.520 ; 10.Auflage)
(und nach Schwarze S.150)

Code:

---

y+ = y*ut/nu

---

dabei ist die Schubspannungsgeschwindigkeit

Code:

---

ut=sqrt(-Tw/Rho)

---

Tw ist die Wandschubspannung

Code:

---

Tw = mu(du/dy)

---

// also Geschwindigkeitsänderung von Wand zu Zellmitte)

Der Unterschied liegt wie du selber siehst darin, dass y* aus Turbulenzgrößen gebildet wird. Wenn du in die Wandfunktion reinschaust, siehst du dass diese y* benutzt (u*=y* für viskose Unterschicht usw.)
y+ ist numerisch nicht so stabil wie y* daher wird dieser verwendet (so steht es im schwarze, Seite 152).

Ich habe bei einer einfach Rohrströmung mal nachgerechnet, die Werte über "yPlusRAS" sind y* werte. Und im Gegenzug das selbe Netz mit CCM+ gerechnet, hier hat es mit der "Handrechnung" übereingestimmt.

Wenn du mehr Informationen dazu willst, kannst du dich gerne direkt an mich wenden.

gruß Marcel

[Diese Nachricht wurde von Marcel-E am 14. Apr. 2015 editiert.]

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

---

Grüß dich Marcel,

danke für die Literatur. Schwarze + Schlichtling liegen bei mir zu Hause. Werde das dann heut mal nachschauen. Allerdings wiederholst du das was ich bereits oben erwähnt hab. Die Berechnung von y+ in OpenFOAM beruht darauf das die Annahme, die ich oben verlauten lassen habe, verwendet wird. Anderenfalls wird die Schubspannungsgeschwindigkeit anders berechnet (vgl. Ferziger S.353))

Bei der Annahme das Dissipation und Produktion im Gleichgewicht sind wird ut wie folgt definiert:

Code:

---

ut=C_mu^0.25 * sqrt(k)

---

Wird diese Annahme nicht verwendet wird ut, wie du bereits oben erwähnt hast, wie folgt berechnet:

Code:

---

ut = sqrt(|tw|/rho)

---

Somit wäre dann ja alles gesagt.
Der einzige Unterschied liegt an der Annahme die oben getroffen wird. Das im Schlichting und Schwarze das mit y* deklariert ist wusste ich nicht.
Aber das wäre jetzt auch geklärt.

------------------
Keep Foaming | Viele Grüße,
Tobias Holzmann

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

---

Das mit dem STEP werd ich mal probiern, jetzt wo ich Salome eh drauf hab   

Haha, die Seite 353 hatt ich im Ferziger auch grade offen   

Auf CFD-Online wurde z.B hier und hier die Frage zu y+/y* auch schon diskutiert, mit dem Hinweis

Zitat:

---

y-star is related to turbulent kinetic energy while y-plus relates to friction velocity(that relates to wall skin friction in its own)

---

Hab allerdings noch keine Literatur diesbezüglich gefunden bisher...

edit:
Ok, ich war wohl zu langsam  

Mit

Code:

---

yPlusRAS -compressible

---

funktionierts anscheinend auch kompressibel, habs aber selbst noch nicht ausprobiert...

------------------
...im CAD hats gepasst.

[Diese Nachricht wurde von Turbo Encabulator am 14. Apr. 2015 editiert.]

[Diese Nachricht wurde von Turbo Encabulator am 14. Apr. 2015 editiert.]

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

---

Na da untermauerst du ja nochmals meine Aussage 
Wunderbar. Wäre das also alles geklärt. Für mich ist es immer y+ nur muss ich eben wissen wie ut berechnet wird. Natürlich ist eine Klassifizierung anhand von + und * sinnvoll und ich werd es mir merken 

Bezüglich deinem Argument compressible, kannst du dann eben für dichtebasierende Löser dein y+ berechnen.
Die Berechnungen sind identisch nur eben wird hier noch die Dichte mit berücksichtigt.

------------------
Keep Foaming | Viele Grüße,
Tobias Holzmann

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

---

yplus_ystern.JPG

Hallo,

hier noch als kleiner "Abschluss" ein Vergleich von y+ und y* bei einer einfachen Rohrströmung (Reynolds-Zahl = 10.000). (siehe Anhang)

Man sieht für niedrige y+ Werte, dass y+ eben nicht identisch mit y* läuft. Gerade bei low-Re Modellen sollte man hier aufpassen.

gruß Marcel

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

---

Hallo Marcel,

danke für deine Grafik. Ist natürlich verständlich das y* hier ungenauer sein wird, als y+, da mit (wie du bereits erwähnt hast) turbulenten Größen gearbeitet wird. Ist jedenfalls sehr interessant und sollte bei Stoff- und Wärmeübertragung  die an Wänden passieren definitiv beachtet werden. Wenn du möchtest kannst du auch gerne für alle eine Aufklärung zu y+ und Wandfunktionen tätigen. Das würd ich dann in den Sticked Thread verschieben bzw. einen neuen aufmachen.

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

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

---

gv1.png

Guten Tag der Herr  

ich sehe dass Sie eine sehr hilfreiche Antwort auch für mich gepostet haben.
Ich schreibe meine Bachelorarbeit über turbulente Strömungen über eine zurückspringende Stufe mit OpenFoam. ich benutze auch den Simple Solver und kam auch auf Ergebnisse.
Sie haben jedoch eine schöne parabelförmige Abbildung erschaffen, welche bei mir mehr eckig wirkt (siehe Anhang). Ich komme leider nicht drauf wieso. Bitte um ihre Hilfe.
Das ist das Bild bzw die Grafik von Ihnen: https://ww3.cad.de/foren/ubb/uploads/Shor-ty/tk2.png
Das ist mein Ergebnis im Vergleich zum Experiment (falls das Bild angezeigt wird: http://de.tinypic.com/r/jtnj34/9

Mit freundlichen Grüßen
Enes

Shor-ty: URL Korrigiert

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

---

Hallo Enes,

ich sehe keine Frage in Ihrer Nachricht. Das Profil das Sie von mir aufzeigen, ist lediglich das Geschwindigkeitsprofil in normalen Rohrströmungen. Je turbulenter desto mehr weicht es von der Parabelform für laminare Strömungen ab. Die Grafiken die Sie zeigen sind berechnungen von irgendwelchen anderen Werten. Ich nehme mal an, dass dies nicht das Geschwindigkeitsprofil darstellen soll.

------------------
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

---

gv-4.png Auswahl_001.png

Hallo Shor-Ty

tut mir leid dass ich es so schlecht formuliert habe.
Also auf dem Bild, welches ich geschickt hatte, gehören die Punkte zu experimentellen Ergebnissen. Die Linie ist meine Simulation. Ich werde jetzt das die Ergebnisse bei -4H=x hochladen, damit wir VOR der Stufe sind. Das ganze passiert auf der linken Hälfte des zweiten Anhangs, also VOR der Stufe.
Mein Problem ist, dass mein Ergebnis rechts oben und unten fast eckig sind. Es soll nicht exakt wie die Lösung des Experiments sein, jedoch auch parabelförmig. Ich habe die Vorstufe länger gezogen damit es einlaufen kann, jedoch wieder nur das gleiche Ergebnis.

Ich möchte auch die Verzeichnisse 0, constant un system hochladen wie der Kollege oben, bekomme es jedoch nicht hin.

Hoffe Sie können mir helfen.

Grüße
Enes

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

---

Guten Abend,

ein Diagramm sollte Achsen haben die beschriftet sind oder zumindest im Text sollte bezeichnet werden was da drauf zu sehen ist. So wie es aussieht ist das ein Geschwindigkeitsprofil vor der Stufe. Dein Problem ist, dass es so kantig ist und nicht glatt. Wie wäre es mit einer Netzverfeinerung? Vielleicht ist dein Netz auch numerisch alles andere als gut oder du verwendest ein falschen Filter oder machst das Post-Processing falsch.

------------------
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

---

vergleich.png

Guten Tag,

tut mir leid es ist direkt aus dem Gnuplot abgespeichert. Es ist die Geschwindigkeit in x-Richtung und die Höhe in y-Richtung. Mein Gitter müsste eigentlich sehr gut sein und ich habe wieder neue Sachen mit mehr Zellen ausprobiert. Ich meine es hat sich leicht verändert aber nicht viel.
Ich habe es mit verschiedenen Modellen ausprobiert, SKE, RLZKE, k-omega, etc aber immer das gleiche.

Im Anhang ist ein SKE mit ca 160k Zellen. etwas abgerundet fehlt jedoch noch einiges.

Keine Ideen an was es noch liegen könnte?

Liebe Grüße
enyo

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

---

• Falsche Randbedingungen
  
• Falsche Dimensionen
  
• Netz
  
• Numerik
  
• Lineare Löser
  
• Konvergenz-Einstellungen
  
• Verwendeter Löser
  
• Physikalische Größen
  
• Verwendete Modelle
  
• Diskretisierung
  
• Einsatzgebiet des Lösers
  
• 2D vs 3D
  

Allerdings musst du dir das selber beantworten. Ohne einen Case ist das alles nur raten. Dennoch viel Erfolg  

------------------
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

---

ske.tar.gz

Ich habe es geschafft die Dateien einzupacken 

Bitte sie sind im Anhang

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

---

• Du weißt schon das dir deltaT = 0.1 nichts bringt, nur dass du anstatt 1000 Iterationen 10000 machst. Man setzt aber endTime dann auf 10000.
  
• Turbulenzgrößen / BC
  
• Druckgleichung kannst du nicht relaxieren - nicht hier - außerdem fehlt ein Strickpunkt
  
• Dein Outlet ist wahrscheinlich zu nah an der Stufe
  
• Netz zu fein - kannst um einiges vergröbern
  

Des Weiteren kann ich keine genaue Aussage bezüglich dem Profil machen. Denke aber das ich es gut treffe. Deine Plots sind undurchsichtig. Keiner kann nachvollziehen an welcher Position diese gemacht worden sind. PlotOverLine ist übrigens meines Erachtens für genaue Auswertungen nicht empfehlenswert. Diesbezüglich ist eine weitere Diskussion etwas schwer... Wenig Aufwand und Zeit für die Frage investiert, wenig Aufwand für die Antwort - eigentlich schon zu viel 

Hinweis zur Relaxation. Das Feld wird relaxiert, nicht die Gleichung. Bringt hier auch nichts weil du keine Schockwellen bei inko hast und die Matrix stets Diag-Dominant ist, außer du machst essentielle Fehler.

Code:

---

    // Explicitly relax pressure for momentum corrector
    p.relax();

---

------------------
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