---

RechnungsRB.zip

Moin!

Ich schreibe gerade meine Diplomarbeit und soll dafür eine Twinscroll-Turbine mit OpenFoam berechnen. Ich muss dazu sagen, dass ich mehr oder weniger ins kalte Wasser geworfen wurde was die CFD-Simulation angeht, aber bis jetzt ging es trotzdem ganz gut.

Hab jetzt aber folgendes Problem:
Ich habe eine Twinscroll-Turbine, welche aufgeteilt ist in 3 Teile (Volute, Turbine, Downpipe). Diese habe ich einzeln mit Hilfe von cFMesh vernetzt und denn mit mergeMeshes verbunden. Des Weiteren wurde in der Turbine ein Set erstellt, da die sich später mit Hilfe von MRF drehen soll. Das Set wurde dann in das mergeMeshes-Netz eingefügt und mit setsToZones in eine Cellzone gewandelt.
Die einzelnen Interfaces sind mit cyclicAMI zueinander verbunden.

Soweit so gut. Nun gebe ich folgende Randbedingungen vor: T in: fixedValue; T out zeroGradient; p in zeroGradient; p out fixedValue; U in flowRateInletVelocity; U out inletOutlet
Turbulenzmodell is komegaSST

Ich kann so bis zu einem bestimmten Punkt relativ gut rechnen. Meine Drehzahl bekomme ich mittels fvOptions auch auf die Solldrehzahl, nur leider geht beim Massenstrom nicht mehr als 0,02... ich müsste aber auf 0,023...
Sobald ich den Volumenstrom auf 0,021 erhöhe fangen die Residuen aber stark an zu schwingen und die Rechnung bricht ab.
Bis dahin (habe mal versucht in einzelnen Schritten dahin zu rechnen, erst Drehzahl, dann Volumenstrom erhöht) sieht es ganz gut aus. Die Werte klingen bis dahin auch plausibel.

Jemand eine Idee woran das liegen könnte?

Im Anhang noch meine fvSolutions, fvSchemes und co.

logFile kommt später, da ich es bis zum Fehler leider nicht geloggt habe und es somit nochmal bis dahin rechnen muss...

EDIT: Logfile sowie Residuenverläufe (bis 0,02 und ab 0,02 Volumenstrom) jetzt im Anhang mit drin.
[Diese Nachricht wurde von SchuKingR am 27. Jun. 2017 editiert.]

[Diese Nachricht wurde von SchuKingR am 27. Jun. 2017 editiert.]

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

---

Grüße dich SchuKingR,

ich stell mir immer wieder die Frage wieso man AMI + MRF und Steady-State in Verbindung bringt. Für mich ist das alles recht unsinnig aber ich kann mich da auch irren.

Via MRF ist es möglich Rotationen zu simulieren, bei denen das Netz statisch ist und somit keine Flux-Korrektion und die Bewegung des Netzes mitbetrachtet werden müssen. Somit scheided AMI auch aus weil das AMI genau dafür programmiert wurde, um sich zueinander drehende Regionen zu verbinden (mappen/interpolieren) und das wiederum mit transienten Berechnungen verbunden ist bei denen sich das Netz dynamisch ändert.

Allerdings übersehe ich etwas, das hier essentiell ist, da AMI auch eine Schwachstelle darstellt.

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

---

Guten Morgen Tobias!

erstmal schonmal vielen Dank für deine Antwort!

Das cyclicAMI nutze ich deshalb, da ich mit dem normalen cyclic das Problem hatte, dass die Interfaces nie die gleiche Zellenanzahl bzw. Knotenanzahl hatten und somit immer ein Fehler auftrat.

Das cyclicAMI bildet einfach den Mittelwert, falls eine Zelle zwei Partner hat und somit ist das Problem gelöst.

Falls es da eine andere Variante geben sollte die ich vielleicht einfach nicht kenne, wäre ich froh, wenn du dir mir zeigen könntest.

Ich arbeite das erste mal mit OpenFoam und hab den Tipp mit cyclicAMI auch nur von einer Kollegin.

Aber dürfte eigentlich auch nicht weiter schlimm sein, da es bis zu dem Punkt ja funktioniert. Also die Daten werden korrekt durch die Interfaces übertragen. Zumindest rein optisch laut paraview.

Viele Grüße,
Toni

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

---

Hallo Toni,

ich hab das oft genug gefragt wieso AMI mit MRF benutzt wird aber nach deiner Aussage wird es endlich klar. Gerade für komplexere Teile macht es jetzt (auch für mich) Sinn. Allerdings sollte es auch ohne irgendeine cyclic Randbedingung gehen, wenn man das Netz mit sHM macht, und das Interface entsprechend behandelt. Müsst ich aber selber mal probieren ob snappy das kann, oder ob man mit stichMesh irgendwas erreicht.

Soweit so gut. Dann sollte hier mal kein Problem vorliegen. Übrigens wenn du einen Komplettcase mit einem Runskript hättest, würde ich mir das anschauen. Die einzelnen Files zu analysieren mach ich nicht mehr sehr gerne  

PS: Du definierst p und U am inlet, das ist für inkompressible Strömungen nicht geeignet, da die Matrix nicht gut konditioniert ist. Druck sollte am Outlet sein! oder du machst das inlet für U auf pressureINletVelo und setzt am Outlet deine totale flow rate.

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

---

Hallo Tobias,

ich weiß leider keine richtige Alternative zu der cyclicAMI Bedingung, deshalb nutz ich die halt 

Zwecks sHM: bedingt dadurch, dass ich cFMesh nutze, was meiner Meinung nach 1000mal besser und schneller funktioniert (zumindest wenn man als Anfänger an OpenFoam rangeht), hab ich leider keine Ahnung wie snappy funktioniert. Mit stitchMesh hatte ich mich auch kurz auseinandergesetzt, bin dann aber zu dem Entschluss gekommen, dass das eindeutig zu kompliziert ist und auch anscheinend nur in den seltensten Fällen funktioniert.
Aber wie du auch sagst, da dürfte das Problem eigentlich nicht liegen.

Leider kann ich dir den komplettcase nicht geben, da es einer gewissen Geheimhaltung unterliegt und somit ich die Geometrie nicht rausgeben darf. Würde ich dies dürfen, würde ich das natürlich sehr gerne tun, denn sonst komm ich hier nämlich nicht weiter 

zu PS: ich habe eine kompressible Strömung, deshalb rhoSimpleFoam 
das andere verstehe ich nicht ganz, da ich am Inlet eigentlich kein Druck vorgebe (zeroGradient), sondern nur am Outlet fixedValue ist.
U ist am Inlet als Volumen- bzw. Massenstrom vorgegeben und am Outlet als inletOutlet. (hatte da auch schonmal zeroGradient, was aber kaum einen Unterschied macht)

Viele Grüße,
Toni

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

---

Hi Toni,

sorry das ich das mit deiner kompressiblen Strömung schon wieder wegrationalisiert hab. Allerdings ist p und U am inlet nur dann vorteilhaft wenn man über Ma > 0.3 ist (soweit ich mich entsinnen kann - diese Überschallströmungen sind nicht mein Spezialgebiet).

Ich habe mir mal deine U und p Files angeschaut aber hab anstelle p das T File geöffnet und daher am VO_INI die fixedValue gesehen. Habs jetzt nochmals geprüft und passt soweit.

Übrigens wenn du Ma < 0.3 bist, kannst du auch den pimpleFoam verwenden und das T-Feld (sofern es von Interesse ist) via einer passiven skalaren Größe modellieren. Natürlich enfallen dann die standard Möglichkeiten ein thermodynamisches Modell zu verwenden. Ob es nötig ist musst du selber entscheiden. In deinem Fall wäre es natürlich auch möglich mit FOAM-dev zu rechnen. Es hat sich vieles getan seit 2.3.x und aus deinen Header-Daten nehme ich mal an das du diese Version verwendest (bzw. aus deiner Info links 2.4).

cfMesh hab ich mal getestet, war mir aber zu unübersichtlich  
Soll aber anscheinend wesentlich besser mit Layer-Erzeugung umgehen können und die Speicherplatzverwaltung besser organisieren und wie du sagst, schneller sein. Vielleicht sollt ich dem ganzen nochmals ein Versuch geben.

Die Aussage 1000x besser ist natürlich recht unbedacht, da du mit snappyHexMesh keine Erfahrungen hast  

InletOutlet ist eigentlich zeroGradient, nur wenn man aus irgendwelchen Gründen eine Rückströmung hätte, setzt inletOutlet die Faces auf Null (kein Flux in die numerische Domäne).

Da du sonst keine weiteren Informationen lieferst, kann ich dir nicht helfen. Du solltest mal jeden Zeitschritt speichern und versuchen visuell die Problemstelle zu finden. Denn da du überall upwind hast, muss irgendwo ein gravierender Fehler sein.

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

---

Hallo Tobias,

Da ich die Turbine noch in anderen Punkten berechnen soll denke ich, dass ich über Ma 0,3 kommen werde, falls ich es nicht sogar schon bin. Also entfällt pimpleFoam.

Eine neuere Version würde ich gerne testen, aber leider ist hier in meiner Diplomstelle nichts neueres als 2.4 gegeben. (Bin aber dran Version 4.x zu organisieren, da ich schon davon gelesen habe, dass die paar gute Neuerungen haben soll.)

cfMesh ist wirklich sehr einfach, wahrscheinlich zu einfach  Im Vergleich zu snappy dachte ich zuerst auch "das kann doch jetzt nicht schon alles gewesen sein was ich hier eingeben muss"
Aber doch, man muss wirklich nicht viel eingeben und bekommt ein doch recht ordentliches Netz.

Meine Aussage war etwas übertrieben, gebe ich zu 

Das mit dem Zeitschritt werde ich nochmal versuchen, ist eine sehr gute Idee. Vielen Dank! 

Dachte mir schon, dass mir so nur schwer jemand helfen kann. Aber ich bin trotzdem froh, dass du es zumindest mit meinen doch eher spärlichen Informationen versuchst und mir Tipps gibst.

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

---

OpenFOAM auf deiner Maschine zu kompilieren ist sehr banal. Wenn du auf einem Cluster bist, ist es ebenso banal, da du alles lokal auf deinem User-Folder machen kannst und die Systemkonfig nicht anrührst. Auf m Server ist das mit MPI dann ggf. noch etwas komplezierter aber allgemein easy to handle. Seit FOAM-4.x (Foundation) gibt es einige interessante Punkte für Programmierer (C++11 Standard Support etc). Auch die FDIC ist gut, da hier bis 10% schneller gerechnet werden kann. Du solltest, sofern dein Netz groß ist auch renumberMesh verwenden. Speedup bis 20%, je nach dem wie zerstreut deine Matrix ist.

cfMesh hatte ich mir mal angeschaut. Explizit die Tutorials, allerdings hat mich das nicht so überzeugt. Letztlich ist es ja nur ein Derivat von snappyHexMesh mit einigen Improvements (zumindest lese ich das so raus und im OFW16 in Portugal wurde cfMesh ja hoch gelobt). Wäre interessant ob meine Berechnungen mit cfMesh funktionieren, da sHM mir Prismen, Pyramiden, Wedges etc. liefert die ich nicht brauche. Aber das ist ein anderes Thema.

Du könntest mal ein Logfile posten mit 10 - 20 Iterationen bevor dein Solver abbricht. Da könnte man ggf. ein paar Hinweise bekommen. Gerade auch der Abbruchfehler selber zeigt welche C++ Funktion / Operation letztlich den Fehler verursacht.

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

---

bedingt dadurch, dass ich keine Ahnung von Linux habe und somit nur ein Nutzer des Programms bin, habe ich auch leider keinerlei Erfahrungen wie das ganze mit dem kompilieren usw. funktioniert. Ich vertraue da komplett auf die IT-Abteilung unserer Firma.

Ich hatte aber auch schon den Gedanken, mir die neuste OpenFoam-Version auf meinem Heimrechner zu installieren und das denn dort zu probieren. Das scheiterte aber daran, dass ich nicht einmal Linux installieren konnte, da nach dem vermeindlichen Setup-Start nur ein schwarzer Bildschirm folgte. Das werde ich aber nächsten Monat wahrscheinlich nochmals in Angriff nehmen.

reconstruct (ohne Mesh) nutze ich schon für meine Rechnung, da es sonst Ewigkeiten dauern würde. Mein Netz besteht zurzeit aus 9 Millionen Elementen. Es ist ein Hexaeder-Netz.

Ein Logfile ist schon in der Zip-Datei enthalten. "logrhosimplefoam" müsste die heißen, dort sieht man den kompletten Verlauf der letzten Rechnung. Also von der Berechnung mit Volumenstrom 0,02 aus gestartet mit einem geänderten Volumenstrom auf 0,023 in beiden Inlets.

Verwunderlich sind dort die fallenden minimalen Druckwerte, die dann auch ins Negative gehen.

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

---

Ich bin heute nicht auf der Höhe sorry. Ich meinte renumberMesh und nicht reconstructMesh (letzteres gibts ja gar nicht). Und die das übersehen der Logdatei - sorry.

Deine Rechnung macht schon von Beginn an einen komischen Eindruck. Dein pMin zwischen 6005 und 6006 geht von 3280 Pa auf 34171 Pa. Da kann was nicht passen. Ich kann mir nicht vorstellen das du solche Druckschwankungen hast. Und bei 6054 hast du schon ein negativen Druck, das physikalisch nicht möglich ist. Denk mal an das Ideale Gasgesetzt. Da müsst ja dann ein negatives Volumen dabei rauskommen, oder eine Temperatur kleiner 0 K. Mich wundert es aber das dein Löser nicht abbricht. Was verwendest du für ein Thermo-Modell? Kann keins mit einer Idealen oder Realen Gasgleichung sein, außer du hast irgendwo noch ein Limiter für den Druck. Aber da ist schon ganz am Anfang was im Argen. Möglicherweise eine numerische Zelle. Du hast auch ständig das Bounding von k, das wiederum ein Indiz dafür ist. Normalerweise sollte vor allem beim Steady-State, das Bounding aufhören. Du hast es aber immer. Am Schluss hast du eine Division durch Null (Floating Point Exception). Da triffst du halt genau eine Größe in irgendeiner Zelle die den Wert 0 hat und die bei einer Division im Nenner steht. Und du meintest ein Hex-Dominantes Netz, da cfMesh keine Hexaeder-Netze macht. Wäre ja schon wenn dem so wäre 

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

---

kein Problem. Kann man schon mal übersehen, vielleicht hattest ja auch noch eine der ersten hochgeladenen Varianten zuerst ohne Logfile. Ich hatte da so meine Probleme beim Hochladen...

Das mit den Werten ist mir auch aufgefallen, vor allem der negative Druck bzw. die überhaupt sehr niedrigen Druckwerte...
Das der Löser da weitermacht verwirrt mich aber auch etwas. Wenn man eine negative Temperatur hat, bricht er dafür sofort ab. (hatte das mal zum Anfang meiner CFD-/OpenFoam-Karriere, also vor ca 1,5 Monaten)
ThermoModell ist hePsiThermo, bedingt dadurch, dass kein anderes für mich sinnvoll klang und ich dort das sutherland Transportmodell nutzen kann, was ich ja benötige, da sich die Dichte und Temperatur ja mit verändern soll.
Entschuldige die Nachfrage, aber was ist ein bounding beim k? Also was bedeutet dies?

Ja meinte Hex-Dominantes-Netz. Bin irgendwie auch nicht ganz auf der Höhe heute...

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

---

Bounding ist wenn die Werte für k und epsilon unphysikalisch sind. Die können nämlich nur positiv sein. Bounding ist eine Funktion, die die Werte <0 auf Null setzt und ist ein Indiz das was nicht passt. Die Tatsache das mit negativem Druck gerechnet werden kann (wenn auch nicht physikalisch) liegt wohl an Zusatzfunktionen wie:

Code:

---

    rho = thermo.rho();
    rho = max(rho, rhoMin);
    rho = min(rho, rhoMax);

---

Damit gehst du sicher, dass deine Dichte immer zwischen deinen in fvSolution angegebenen Werten ist. Temperaturabhängige WErte kannst du auch mit Polynomansätzen machen, das mach ich normalerweise immer. Rho, Cp, k, lambda kann man so über Polynome (bis 8ten Grades glaub ich) angeben. Hast du eine fvOption constrain für irgendwelche Felder drin? Nach all den Hinweisen würde ich mal auf eine numerische Zelle tippen, die dir Probleme macht. Sicherlich irgendwo eine Zelle die ganz komisch aussieht und irgendwo an einer Boundary sitzt. Daher mal die Iterationen rausschreiben und mit dem Treshhold-Filter kucken wo sich die Maximalen U, p Werte und k/omega Werte befinden - ggf. auch T. Das sollte dir recht schnell die Problemzone zeigen.

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

---

Guten Morgen Tobias!

Hab gestern und heute morgen noch etwas rumprobiert. Ich habe jetzt die rhomin auf 0 und rhomax auf 800 gesetzt, damit diese die Rechnung nicht weiter begrenzen.

In fvOptions habe ich nur die MRF-Funktion drin, mehr nicht.

der Threshhold-Filter brachte mich leider auch nicht weiter, da dort wo der vermeindliche seltsame Bereich anfängt das Netz soweit ganz gut aussieht.

Habe jetzt nochmal ein Netz komplett ohne Layer erstellt um zu schauen, ob es nicht daran liegen könnte. Dem scheint aber nicht so. Zumindest der Residuenverlauf scheint sich nicht verändert zu haben.

Zwischenzeitlich hatte ich auch die Funktion "transonic" im fvSolver probiert, aber damit bekomme ich meine Rechnung gar nicht zum Laufen, bzw bricht diese nach ein paar Iterationen ab.

Ich bleib dran und schaue ob ich eine Lösung finde. Falls ich was weiß melde ich mich wieder 

Viele Grüße,
Toni

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

---

Hi,

leider fällt mir dazu jetzt nichts konkretes mehr ein. Du könntest k und omega auf 0.1 relaxieren und schauen was passiert. Hast du alle Größen mit dem Threshhold betrachtet? Übrigens gibts rhoMin/rhoMax in der FOAM-Dev Version gar nicht mehr. Hier limitiert man den Druck p. Du könntest auch mal die nonOrthoCorr auf 2 oder 3 setzen. Damit löst du die Druckgleichung mehrmals. Mit dem Keyword transonic geht du in eine andere Berechnung von p. Hier hast du auch die Möglichkeit die Matrix selber zu relaxieren. Ansonsten ist die Berechnung fast identisch. Bei der DEV version könntest du noch den SIMPLEC testen  Allerdings sind alle meine Vorschläge jetzt nur irgendwelche Vermutungen. Vielleicht auch eine falsche Randbedingung - aber das musst du wissen.

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

---

Hallo Tobias,

ich habe jetzt ein vereinfachtes Modell erstellt was von meinem GoogleDrive unter folgendem Link runterzuladen ist. https://drive.google.com/file/d/0B1_GHmlShv4OZi1fTmp0WU9EdXc/view?usp=sharing
Es hat eine runscript.sh womit er startet, auf 16 Kernen decomposed, reconstructed, die Proc-Ordner danach löscht und auch loggt.

Hierbei kann der Massenstrom bis zu einem Wert von 0.025 erhöht werden. Ab 0.026 bringt das Modell irgendwann unplausible Werte und bricht bei Iteration ~270 ab.

Bei 0.025 bricht das Modell nach ca. 1600 Iterationen auch mit seltsamen Werten ab. Bei 0.02 scheint es aber nicht abzubrechen.

nonOrthoCorr hatte ich auch auf 2 gesetzt, macht aber soweit keinen größeren Unterschied. Rechnet bei 0.026 bis ~260 und bricht dann ab.

Laut einem Internet Rechner habe ich bei meinen 600°C und bei der Geschwindigkeit von ca 360 m/s eine Machzahl von 0,6. Vorausgesetzt ich habe alles richtig eingestellt, dass ich auch mit Luft rechne. Ich muss zugeben, dass ich das ganze System bei OpenFoam noch nicht ganz verstanden habe, wo ich da die Stoffwerte ändern kann.
Habe somit einfach die Werte von meiner Vorgängerin, welche auch eine Turbine gerechnet hat, übernommen.

Außerdem wollte ich mir den Massenstrom aus den inlet und outlet anzeigen lassen. Seltsamerweise kennt OpenFoam 2.4 die Funktion patchMassFlow nicht mehr. Bei 2.0 funktioniert diese noch.

[Diese Nachricht wurde von SchuKingR am 05. Jul. 2017 editiert.]

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

---

Hi,

zum Case
habs mir gerade angeschaut. Interessant. Für ein Fallbeispiel kann man aber Inlet/Outlet extrem stark verkleinern. Wenn ich die STL hätte (vom vereinfachten Modell), könnt ich das mit snappyHexMesh mal nachbauen (interessant wäre für mich auch die cfMeshDict). Bezüglich den Abbrüchen. Ich nehme an das auch andere abbrechen werden, sofern du lang genug rechnest. Des Weiteren würde ich nur ein AMI verwenden anstelle von zwei.

Ich hab deinen Case jetzt auf die FOAM-dev version umgeschrieben und gleich einen Massenstrom von 0.03 vorgegeben. Übrigens ein kleiner Tipp ohne Kommentar: renumberMesh. Achja und kennst du pyFoam? Damit kann man die Residuen auch schön darstellen + Conti etc.

Analyse

Abbruch nach 37 Iterationen (p am Inlet gesetzt). Interessanterweise ist es die erste Rechnung (seit langem) die meine CPU's nicht zu 100% ausnutzt. Das schwankt zwischen 95-100 (egal). Okay, meine ersten Hinweise:

• Inlet macht Probleme -> U > 3000 m/s (kann ich nicht glauben) - zum Vernetzen würde ich das Inlet um 45 Grad drehen, damit das mit dem Hintergrundnetz ausgerichtet ist.
  
• Druck macht auch Probleme am Inlet
  

Abbruch nach 8 Iterationen (p am Outlet gesetzt).

• Geschwindigkeitskomponente sieht immer noch nicht vernünftig aus (>1.400 m/s)
  
• Druck sieht besser aus
  
• Temperatur wischen 649 und 1111 K
  

-> Skalierung der Geometrie ist falsch? Ich hab 0.15m in x, 0.158m in y etc. Ist das korrekt? Falls ja, ist das eine Miniaturturbine!

Zum Bestimmen der Fluxes
In den neueren FOAM Versionen wurden alle post-processing Tool in die postProcess Applikation geschoben. Das ist viel besser zu warten und neue Funktionalität einzubauen.

Thermodynamic
Du hast die Möglichkeit verschiedene Modelle zu verwenden (siehe User-Guide eins der letzten Kapitel). Du kannst auch irgendeinen Unsinn reintippen, dann bekommst du die Liste der Möglichkeiten. Für temperaturabhängige Werte verwende ich meistens die Polynomansätze.

[b]Brachte mich zum schmunzeln[b]

Code:

---

h      0.7;//vorher net da;

---

Darf man fragen woher du kommst? 

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

---

STLs.zip

Moin,

STLs findest du im Anhang, ich weiß nicht ob du die so brauchst oder als geschlossener Körper, da ich ja kaum bis gar nicht mit snappy arbeite.

Die meshDicts vom cfMesh hab ich dir auch da mit reingelegt.

Zum Verständnix vielleicht noch meine Arbeitsreihenfolge:
1. mit dem "cat" Befehl einzelne STLs zu Gruppen zusammenfügen (Rotor, Inlet, Downpipe)
2. Vernetzen der einzelnen Geometrien mittels cfMesh
3. topoSet für die RotorCellZone im Rotor
4. mergeMeshes zu einem Gesamtnetz
5. RotorSet in Gesamtnetz kopieren
6. setsToZones um CellZone zu erhalten
7. transformPoints um das Netz auf die richtige Größe zu skalieren

Ich brauche deshalb zweimal AMI, da ich es sonst nur schwer hinbekomme die Turbine ordentlich zu vernetzen. Also zumindest mit cfMesh. Außerdem bekomme ich es so auch einfacher hin die komplette Turbine im topoSet zu erwischen. Ist bei dem Modell nicht so schwer, da zylindrisch, aber im richtigen Modell ist der Rotor etwas komplizierter geformt.

Zu den Abbrüchen: ich konnte die mit 0.02 Massenstrom durchrechnen bis die Rechnung durch das Erreichen von 10e-5 bei den Residuen gestoppt hat. Also soweit passt das zumindest bei 0.02.
Bei 0,024 pegelt sich alles bei 10e-3 bzw. 10e-4 ein, außer der Druck, der ist bei 10e-2. Aber dort bleibt es selbst nach 8000 Iterationen.

renumberMesh und pyFoam gucke ich mir mal an, kenne ich beides bis jetzt noch nicht. Wenns beim pyFoam aber nur um die Residuen geht, dann werde ich da erstmal bei gnuplot bleiben, da ich mir nicht zu viel neues auf einmal anschauen möchte. Ich hab ja so schon genug damit zu tun OpenFoam zu verstehen   

Skalierung der Geometrie passt    Es handelt sich um eine Turbine für ein PKW. Die sind nicht sehr groß.

Also wenn das bei dir auch nicht funktioniert, dann habe ich anscheinend einen gröberen Fehler in den Randbedingungen oder bei den Stoffwerten.

mit postProcess meinst du ja wahrscheinlich paraview oder? Denn schau ich da mal wo ich das da finde.
EDIT: hab's gefunden. Also zumindest kann ich jetzt schonmal die Machzahl berechnen und anzeigen. Massenstrom an einem bestimmten Patch hab ich jetzt noch nicht entdeckt.

Das mit den Polynomansätzen habe ich noch nicht ganz verstanden wie man das denn dort implementiert. Hast du da vielleicht mal ein Beispiel für mich?

Zum letzten: bin gebürtiger Schweriner, hatte eigentlich versucht alle meine Anmerkungen herauszunehmen   

[Diese Nachricht wurde von SchuKingR am 06. Jul. 2017 editiert.]

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

---

STLs_geaendert.zip

Guten Morgen!

Ich habe gestern ein wenig herumprobiert und dann doch ein 1-Netz-Modell erstellt. Allein von dem Aussehen der Ergebnisse im Paraview merkt man schon, dass dies wohl auch besser so ist.
Außerdem fiel mir auf, dass ich eher eine Wasserpumpe als einen Turbolader gebaut habe. Dies habe ich behoben, indem jetzt ein Zylinder mittig, quasi als Halter für die Schaufeln, ist. Somit ist auch weniger Rückströmung vorhanden.
Ich habe dir die geänderten STLs, sowie das TopoSetDict und das MeshDict mit in den Anhang getan.

Die IF2 und IF3 STLs sind nur noch dafür da, eine rotor.stl für das TopoSetDict zu erstellen.

Mit diesem Modell kann ich anscheinend mit höheren Massenströmen rechnen als mit dem AMI-Modell. Erst bei 0,03 scheint es Probleme zu geben. Es rechnet jetzt gerade mit 0,028 und da sieht es noch gut aus.

Meine Anstrengungen Linux auch zu Hause zu installieren sind wieder gescheitert. Entweder ich bin einfach zu dämlich dafür oder mein PC hat damit ein Problem (ich hoffe eher letzteres). Aber da befrag ich demnächst Google und Youtube was die sagen.

Viele Grüße,
Toni

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

---

Hi,

hab mir deine Sachen angeschaut und empfehle dir nochmals, deine STL's um 45° zu drehen, damit dein Inlet mit dem Backgroundmesh ausgerichtet ist. Dann würde ich das AMI nicht auf deine Kanten setzen. Ich würde das anders aufbauen. Unglücklicherweise hab ich kein Salome auf meinem Laptop und die Internetverbindung sagt mir das ich 10h zum Download benötige. Entsprechend kann ich den Case gerade nicht wirklich abändern aber vielleicht morgen Abend/Nacht hab ich noch kurz Zeit dafür.

Bezüglich Linux - persönlich habe ich kein einfacheres Betriebssystem installiert  . Wenn du das Parallel auf einer Windows Maschine betreiben möchtest, solltest du da auch gut Geguided werden. Das einzige was dir vielleicht Probleme bereiten kann ist die Sache mit den Partitionen. Daher hab ich immer Linux/Windows auf zwei separaten Platten (außer beim Laptop). Aber ich denke da wirst du bald fündig werden und es zum Laufen bekommen.

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

---

Hi,

hab am Samstag Nacht noch ein bisschen mit dem Case gespielt und entsprechend ein neues Modell gemacht. Nochmals kurz eine/zwei Fragen an dich:

• Die Geometriegröße passt? Richtig? Das sind nur ca 10cm x 10cm x 10cm
  
• Der Massenstrom ist korrekt? Ich hab keine Ahnung welche Abgasgeschwindigkeiten im Turbolader/Krümmer erreicht werden. Können da mehrere hundert Meter pro Sekunde auftreten? Für mich etwas hoch aber das kann natürlich schon sein (ist nicht mein Themengebiet).
  

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

---

Hi Tobias!

Also zum STL drehen: hab das ja jetzt als 1-Netz-Geometrie und somit auch keine cyclicAMI-Funktion mehr, daher hab ich das Netz auch nicht gedreht.

Ich hab heute morgen gemerkt, dass die Rechnung ab einem bestimmten Massenstrom in Machzahlen über 1 kommt. Das scheint rhoSimpleFoam/rhoSimplecFoam nicht berechnen zu können und stürzt deshalb ab. Ich komme dort bis ca. Mach 0,8.

Ich rechne gerade mit sonicFoam instationär und damit läuft es. Nur halt extremst langsam...

Gibt es da irgendeinen Trick rhoSimpleFoam/rhoSimplecFoam Mach>1 fähig zu machen?

Zu deinen aktuellen Fragen:
-Geometrie passt. Das ist wirklich so klein
-messbare Geschwindigkeiten sind so um die 200-400 m/s wurde mir gesagt. Die sind aber am Eingang bzw. Ausgang, da ja in der Turbine selbst nicht gemessen werden kann. Dort sind wahrscheinlich wesentlich höhere. Gerade im Spalt zwischen Schaufel und Wand entstehen enorme Geschwindigkeiten und somit auch die Machzahlen über 1

Bedingt dadurch, dass die Temperaturen ja recht hoch sind (~600°C), hat man zwar ein gutes Polster was die Schallgeschwindigkeit angeht, aber es scheint trotzdem in den kleinen Spalten sehr schnell zu werden und damit ist rhoSimpleFoam zumindest in der Version 2.4 überlastet.

zum Linux-Problem: Ich habe eine extra Festplatte dafür. Habe es bis jetzt immer mit USB-Stick probiert, werde es heute Nachmittag aber mit einer DVD probieren. Ich bin gespannt ob es damit vielleicht besser geht.

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

---

Hi,

danke für die Info. Es gibt doch das Keyword transonic, damit wird die Druck-Korrekturgleichung anders behandelt. Ich schau es mir später an. Die Drehung um 45° ist numerisch bedingt. Zum einen Tut es dir nicht weh wenn du das drehst und zum anderen ist dir die Simulation dankbar, da du gerade am Einlass immer um ca. 45° dein U-Profil hast. Was das bewirkt, kannst du bei mir auf der Website nachsehen. Da hab ich ne große Analyse bezüglich numerischen Schemen etc.

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

---

Hi,

also ich kann jetzt mit einem Massenstrom von 0.08 rechnen. Nach dem analysieren des Codes ist es auch klar. Wahrscheinlich hast du eine schlecht konditionierte Matrix. Beim transonic Keyword, wird die pEqn relaxiert. Wenn man dann den Equations Relax Faktor auf eins setzt, dann wird zumindest eine Digonal-Gleichwertige Matrix erstellt, bei Unterrelaxation entsprechend eine Diagonal Dominanz. Ich hab auch mal den Druck auf das Inlet gelegt - funktioniert auch - aber da bist du sicher fitter wie ich. Die Diagonal-Sache kann man recht einfach prüfen:

Code:

---

    From function void Foam::fvMatrix<Type>::relax(Foam::scalar) [with Type = double; Foam::scalar = double]
    in file /home/shorty/OpenFOAM/OpenFOAM-dev/src/finiteVolume/lnInclude/fvMatrix.C at line 520
    Relaxing p by 1

    From function void Foam::fvMatrix<Type>::relax(Foam::scalar) [with Type = double; Foam::scalar = double]
    in file /home/shorty/OpenFOAM/OpenFOAM-dev/src/finiteVolume/lnInclude/fvMatrix.C at line 610
    Matrix dominance test for p
    number of non-dominant cells  : 41887
    maximum relative non-dominance : 0.751836
    average relative non-dominance : 0.00440945

---

Die Randbedingungen, wie schon erwähnt musst du natürlich für den Druck dann so setzen, dass es physikalisch korrekt ist. Ob der Druck am Auslass definiert wird weiß ich in diesem Beispiel nicht.

Noch weitere Aspekte von mir:

• Das AMI ist von dir richtig gesetzt worden, ich hab es größer gemacht und damit auch das MRF (bzw. die Zone)
  
• Via Transonic und Relax der pEqn funktionierts
  
• Via snappyHexmesh kann man die MRF ohne AMI erstellen - einfach und solide  - damit entfällt dann das interpolieren.
  

Hoff das hilft dir jetzt weiter.

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

---

Guten Morgen,

das klingt echt top! Hab nur ein kleines Problem... das klingt bei dir alles so einfach, aber ich bin leider wahrscheinlich Lichtjahre von deinem Wissen entfernt.  
Ich versteh nur Bahnhof muss ich ehrlich gestehen.

Also ich hab die STL jetzt gedreht und verstehe noch so grob warum das besser ist  

Aber das mit Equations Relax Faktor versteh ich entweder nicht, oder falsch.

Für mich klingt das ja so, als muss in der fvSolution bei relaxationFactors bei equations bei p eine 1 stehen, oder? Oder alle equations auf 1? Weil p hab ich da vorher nur bei fields gehabt.

Egal was ich von beiden mache, es funktioniert nicht so wirklich, also meinst du irgendwas anderes.

Das mit dem Diagonal-Sache einfach prüfen ist für mich leider komplett unverständlich. Ich weiß leider weder wo, noch wie ich da was eingeben muss, damit ich das sehe was du da stehen hast.

MRF ohne AMI hab ich jetzt mit cfMesh auch   Aber ich lass mir heute vom Kollegen snappy etwas genauer zeigen.

Und noch etwas Gutes zum Schluss: ich hab es gestern geschafft auf meinem Heimrechner Linux zu installieren! Konnte aber nicht mehr großartig damit versuchen zu rechnen da es schon etwas später wurde.

Falls du mir deine Lösung etwas einfacher erklären könntest wäre das top  

Vielen Dank dir auf jeden Fall für deine Hilfe!!  

[Diese Nachricht wurde von SchuKingR am 11. Jul. 2017 editiert.]

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

---

Hi Toni,

also erstmal danke für das Kompliment aber das ist wohl etwas hoch gegriffen das ich dir Lichtjahre voraus bin. Ich bin auch nur n kleines Licht in der OpenFOAM Welt und jeder kann genau das gleich das ich auch mach. Hab mich damit halt einfach etwas länger und intensiver beschäftigt und bin in die Numerik etwas stärker eingetaucht. Nichtsdestotrotz  - wie gesagt - gibts hier im Forum sicherlich wesentlich fähigere Leute als mich. Die haben nur andere Sachen zu tun      , Siehe Thomas (Engys) & Thomas (Tian B. Engineer).

Gut ich wills mals versuchen anders zu formulieren. Für jede numerische Zelle haben wir ein Gleichungssystem zu lösen. Bei 200.000 Zellen sind das 200.000 Gleichungen die man in folgender Form schreiben kann: Ax = b. A ist dabei die Koeffizientenmatrix, x der gesuchte Lösungsvektor und b sind die Quellterme (Source). In der FVM hat man im allgemeinen Bandmatrizen die sehr schwach besetzt sind.  Heißt also man hat sehr sehr sehr sehr sehr viele Nullen drin. Für das iterative Lösen dieser Gleichungen braucht man diese Löser (PCG etc.) die das Matrixsystem lösen. Ein wichtiger Punkt dabei ist aber das man eine Diagonal-Dominante Matrix hat. Das bedeutet, dass die Summe der Off-Diagonal-Elemente kleiner oder gleich dem Diagonalelement ist. Beispiel:

Code:

---

|   .   .   .   .   .   .   .   |
|   .   .   .   .   .   .   .   |
|   .   4   6   7   5   5   .   |
|   .   .   .   .   .   .   .   |
|   .   .   .   .   .   .   .   |

---

Die Matrix sieht natürlich nicht so aus aber egal. Nehmen wir an die 7 ist in der Diagonalen, dann sind die off-diag Elemente 4, 6, 5, 5. Die off-diag Elemente sind quasi die Nachbarzellen zum Diagonalelement. Im vorliegenden Fall ist der Betrag der Summe der Off-Diag gleich 20, hingegen das Diagonalelement 7. Damit wäre diese Zeile nicht Diagonal-Dominant.

Wenn man jetzt eine Matrix baut:

Code:

---

fvScalarMatrix pEqn
(
    // Blub
);

//- Relax equation
pEqn.relax()

---

diese dann Quellcode-technisch relaxiert, passiert erstmal noch gar nichts. Aber wenn man in den fvSolutions bei den relaxationsFactors in den equations für p   1; setzt, dann wird die Matrix manipuliert. Für den Wert von Eins ist bekannt, dass nichts passiert. Das stimmt bei der Feldrelaxation schon, aber nicht bei Equation-Relaxation. Warum? ... die Feldrelaxation wird wie folgt durchgeführt:

Code:

---

newValue = prevIter() + alpha * (*this - prevIter());

---

Alpha ist der Relaxationsfaktor. Wenn er gleich Eins ist, dann folgt das der neue Wert gleich dem neu berechneten ist (*this Pointer). Bei alpha = 0 (kannst gern mal testen), ändert sich das Feld überhaupt nicht. Bei der Equation-Relaxation ist aber der Wert von 1 anders zu bewerten. Die Relaxation macht nichts anderes als die Diagonal-Dominanz zu verbesseren und daher werden alle Diagonal-Elemente durch alpha geteilt. Da alpha im Allgemeinen kleiner Eins ist, werden die Diagonal-Elemente vergrößert, dass dem Löser zugute kommt. Natürlich kann man nicht einfach Zahlen ändern, daher wird das dann im Quellterm b auch mit berücksichtigt. Spielt aber hier keine Rolle. Zur Relaxation einer Matrix ist aber die Voraussetzung, das überall in jeder Zeile zumindest eine Diagonal-Gleichwertigkeit vorhanden ist. Heißt also, zuerst wird eine Diagonal-Gleichwertige Matrix erstellt und dann relaxiert. Da der Relaxfaktor 1 ist, und das Teilen durch 1 nichts ändert, bleibt die Matrix prinzipiell intakt aber da zuvor die Diagonal-Gleichwertigkeit durchgeführt wird, ändert sich die Matrix dennoch. Heißt für alpha = 1 sind nach dem Relaxieren alle Diagonal-Element gleich oder größer der Summe der Off-Diag:

Code:

---

|   .   .   .   .   .   .   .   |
|   .   .   .   .   .   .   .   |
|   .   4   6   20   5   5   .   |
|   .   .   .   .   .   .   .   |
|   .   .   .   .   .   .   .   |

---

Das kann beispielsweise an Schockfronten auftreten. Nehmen wir an, dass wir eine Schockfront in der Domain haben und betrachten zwei numerische Zellen, die sich berühren. In einer der Zellen ist die Schockfront mit einem hohen Druckwert. Die andere hat noch einen kleinen Wert (im nächsten Zeitschritt wird sich die Front dann in diese Zelle ausbreiten). Damit ist aber für diesen Zeitpunkt in der  Zelle mit dem kleinen Wert keine Diagonal-Dominanz gegeben. Durch pEqn.relax(1) wird das aber forsiert und die Zeile in der Matrix wird Diagonal-Gleichwertig.

Hoff das ist jetzt klarer. Mit dem Switch transonic true gehst du in der Druckgleichung in eine andere Berechnungsvariante von p. Hier wird dann entsprechend pEqn.relax() aufgerufen (nicht nur, es wird noch ein anderes Flux-Feld erstellt), dass ohne das Schlüsselwort transonic nicht vorliegt. Damit manipuliert man (sofern p in den equations im fvSolution auf 1 oder <1 gesetzt ist) die Matrix auf eine Art und Weise das eine Diagonal-Dominante Matrix rauskommt. Das fördert oder ermöglicht es erst die Matrixgleichung akkurat mit den Linearen Solvern zu lösen.

Um zu prüfen ob die Matrix Einträge hat die nicht Diag-Domi sind, kann man die Debug-Switches in FOAM verwenden $WM_PROJECT_DIR/etc/controlDict. Habs gestern aber für die fvMatrix Klasse nicht gefunden und dementsprechend hab ich einfach die fvMatrix.C modifiziert, neukompiliert und dann die Ausgabe, welche oben steht, erhalten.

Das war jetzt ein kleiner Ausflug zur Numerik, Matrix-Algebra und Programmierung. Hoff es ist nicht zu konfus geschrieben.

Bezüglich Matrix-Erstellung kannst du vielleicht hier was nachlesen: http://www.holzmann-cfd.de/index.php/de/numerische-methoden-ii auf Seite 18ff.

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

---

Nachtrag:

der DebugSwitch ist in $FOAM_ETC/controlDict mit dem Namen fvScalarMatrix.

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

---

Hi Tobias!

Also die Erklärung war top! Hab das jetzt soweit verstanden wie das funktioniert, denke ich.

Ich habe das auch mal gestartet. Komischerweise ändert sich dabei aber der Druck nicht. Min und Max bleiben die ganze Zeit auf dem selben Wert. Er benötigt auch jedes mal 1000 Iterationen für den Druck, also kann da irgendwas noch nicht passen...

Wenn ich den Relax Faktor vom Druck niedriger setze (was ja nicht Sinn der Sache ist), benötigt er zumindest keine 1000 Iterationen für den Druck, aber die Werte bleiben trotzdem gleich...

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

---

Hi,

du kannst natürlich den Relaxationsfaktor < 1 setzen. Sinn macht das definitiv, da du dadurch die Diagonaldominanz verbesserst und damit das Lösen des Matrixproblems deutlich vereinfachst. Wenn du irgendwo 1000 Iterationen hast ist das normalerweise kein gutes Zeichen. Für den stationären Fall kann es aber durchaus vorkommen, dass man sowas am Anfang hat. 1000 Iterationen bedeutet lediglich, du findest keine Lösung die deinem Konvergenzkriterium der 'linear Solver' genügt.

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

---

16600Iterationen.png

Guten Morgen Tobias!

Ja das Problem ist, dass ich den Relax-Faktor auf 0.001 setzen muss, damit der Druck nicht jedes mal 1000 Iterationen braucht.
Und selbst dann ändert der sich da gar nicht. Hab das jetzt übers Wochenende laufen lassen und es ändert sich halt nix am Druck. Selbst wenn ich den Massenstrom in viel zu hohe Werte ziehe.

Ich versteh nicht ganz warum... ist das vielleicht ein Fehler in der Version 2.4? Bei mir zu Hause läuft seit heute morgen der gleiche Case mit Version 4.0
Vielleicht geht's dort ja.

Hab hier mal ein Foto gemacht vom Geschwindigkeitsverlauf. Da sieht man gut, dass es nur bis an die MRF Zone ran strömt, aber leider anscheinend nicht in die MRF Zone.

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

---

Das kann nicht sein  

MRF ausschalten, und eine einfache Rechnung machen.
Sieht so aus als würde der Rotor nur eine Geschwindgkeit anzeigen weil du die MRF hast und dein AMI (das ja keins mehr ist) nicht passt. CheckMesh -> wie viele Regionen hast du?

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

---

checkMeshtopo.txt

Guten Morgen!

MRF war auch schonmal aus, hatte ich vergessen zu erwähnen. Macht also keinen Unterschied. Das Bild war nur mit MRF an.

Also MRF ist aus und es gibt nur ein Gesamtnetz, welches auch nicht durch mergen entstand, sondern direkt aus cfMesh mit nur einer zusammenhängenden STL.
D.h. die Interfaces gibt es nicht mehr.
Gibt somit nur Inlet, Inletwand, Rotorwand, Ouletwand(dpwand) und Outlet als Boundaries. Inletwand, Rotorwand und Outletwand sind auch nur so aufgeteilt, damit diese mit cfMesh besser/einfacher vernetzt werden können und man diese für MRF (wenn man es denn nutzen möchte) nutzen kann.

Die checkMesh log-Datei hab ich dir mal mit angehängt. Laut der hab ich eine Region.

Hier sonst der Case wie ich ihn nutze. Vielleicht habe ich auch einfach etwas falsch verstanden, da es weder bei Version 2.4 noch bei 4.1 funktioniert.
https://drive.google.com/open?id=0B1_GHmlShv4OeTRNUnAyWE1GMDg

[Diese Nachricht wurde von SchuKingR am 18. Jul. 2017 editiert.]

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

---

4teIteration.png

Hey,

interessant. Zu Beginn frag ich mich wieso das Netz so fein sein muss? Gerade für Testzwecke ist das doch nur hinderlich. Für deine Energiegleichung solltest du als internalField ein Kelvin weniger nehmen wie beim Inlet, ansonsten hast du ein Matrixsystem das einfach sehr bescheiden ist. Übrigens, bei 16 Kernen, kann PCG schon fast wieder schneller für p sein als GAMG. Übrigens hab ich p internal auch um 1 - 2 Pa erhöht.

Da der Case so groß ist hab ich nur 4 Iterationen gerechnet. Outflow vorhanden. Strömt also überall wunderbar.

Der Einfachheit hab ich jetzt noch folgendes geändert:

• Laminar
  
• p auf 0.8
  
• Solver für p auf PBiCGStab + DILU
  
• SIMPLE (nicht SIMPLEC)
  
• pInternal +2 Pa
  
• TInternal +1 K
  

Den Rotor würd ich auch noch um 45° drehen zwecks m Netz. Da wäre es dann interessant ob das Einflüsse auf die Ergebnisse hat. Jetzt sollte der Case aber dann laufen  - außer du bekommst oder zielst auf Probleme ab, die erst nach xy Iterationen kommen. Dafür ist mir das aber zu Groß.

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

---

geandertnachShorty.png geandertnachShorty2.png

Moin,

erstmal nochmal vielen Dank für deine Mühen! 

Warum Netz so fein?: -ehrlich gesagt war das noch so drin vom Vernetzen, kann definitiv weniger Zellen vertragen.
Rotor drehen: -gute Idee, mach ich noch 

Hab deine Änderungen soweit ich weiß alles übernommen.(SIMPLE war doch schon eingestellt?)
Sonst:

-Turbulenz off
-p auf 0.8 im fields sowie equations
-Solver auf PBiCG+DILU (macht das "Stab" da noch irgendwas? also was meintest Du damit?)
-SIMPLE (war schon)
-pInternal +2 Pa
-TInternal -1 K (da meintest in der Liste bei dir bestimmt auch -1, wie du auch im Text darüber hattest)

Wenn ich das bei mir mit rhoSimpleFoam rechne sieht das leider nicht so aus wie bei dir. Hab bei mir jetzt 700 Iterationen durchlaufen lassen und hab trotzdem das Problem, dass zwar irgendwo irgendwas strömt, aber es sieht immernoch so aus, als wenn es einfach gerade vom Inlet gegen die Wand strömt... siehe Bilder...

Außerdem ändert sich bei mir der Druck auch nicht wirklich, pMin = 102070 und pMax = 102072 und das bleibt die ganze Zeit so.

Ich versteh es nicht.

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

---

Ich hab das nur angerechnet und mein Slice ist auch anders gewählt las deiner. PEqn = 1. Da hab ich keine Relaxation, kann aber nicht schaden. Wie gesagt. Ich bin kein Experte in den Kompressiblen Strömungen aber du hast hier Schockwellen Propagation. Heißt also, dass bei dir eigentlich Schallwellen durch die gegend Fliegen. Allerdings sollte aufgrund der Tatsache das ddt = 0, der Charakter der Gleichungen anders sein. Ich nehme mal stark an, dass es ähnlich wie bei mir in der Strukturmechanik ist. Via pEquation Relaxation, ist die Fortpflanzung recht langsam und 700 Iterationen ist nicht wirklich viel. Wenn du das Modell so umbaust, das du maximal 250.000 - 300.000 Zellen hast, schau ichs mir nochmals an. Meinen Case den ich letzte Woche mit deiner STL und Blender umgebaut hab (Inlet gekürzt, outlet extrem gekürzt) hab ich glaub nicht mehr zur Hand; ich lösch alles immer gleich  

Übrigens du hattest consistent true -> SIMPLEC.
Außerdem würde ich mir den Conti-Error anschauen, dann alle 10 oder 20 Iterationen mal rausschreiben lassen und mir die Evolution der Lösung anschauen.

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

---

einzelnetz_aufgeraeumt_v2.tar.gz

Guten Morgen Tobias,

also ich glaub ich bin zu dumm für das Programm^^
Ich habe gedacht, dass PEqn = 1 bedeutet, dass der Relaxationsfaktor für die Druckgleichungen auf 1 gesetzt werden müssen. Dem ist aber anscheinend nicht so. Dann hatte ich das doch falsch verstanden...

Des weiteren hab ich consistent true auch nirgends finden können...

Habe das Ganze jetzt auf knapp 195000 Zellen gekürzt. Also wenn du dir das nochmal anschauen könntest wäre das echt cool 
Rechnet jetzt verdammt schnell.

Und wenn du mir dann noch sagen könntest wo ich das mit PEgn und consistent finde wäre mir auch sehr geholfen. Vielleicht löst das alleine ja schon mein Problem.

Falls es nicht im Case Ordner, sondern im OpenFoam selbst zu finden sein sollte, denn wäre das sehr blöd, da ich dort nichts ändern kann/darf.

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

---

withRotor.png UWithoutRotor.png

Hi,

zuallererst einmal eine erfreuliche Nachricht für dich. Ich hab mir deinen Case angeschaut und hab einen für dich der funktioniert. Allerdings mit einigen Änderungen.

Zuerstmal zum anderen:

• consistent - war mein Fehler, da ich die fvS* + controlDict von einem Case kopiert hatte (hab hier ja die Dev Version laufen und ich bin zu faul die Settings Manuel zu ändern).

  
  Case OpenFOAM-dev (Foundation) sollte auch mit 4.x von der Foundation laufen.
  
  www.holzmann-cfd.de/forumCases/HolzmannATL.tar.gz[/URL]
  

• Seit 3.x oder 4.0 gibt es das Schlüsselwort consistent das man bei den SIMPLE Settings setzten kann. Damit rechnet man dann mit dem SIMPLEC anstelle mit dem SIMPLE und rechnet schneller. Pro Iteration zwar länger aber die Konvergenz ist besser, da ein Druckterm noch berücksichtigt wird
  
• Relaxation: a) Field b) Equation
  

Neuversuch der Erklärung: Field Relaxation

• Baue Matrix
  
• Löse Matrix (Berechne neue Werte)
  
• Relaxiere das Feld
  

Relaxieren bedeutet hier nichts anderes als das man die neuen Werte limitiert. Im Code ist das so (phi ist das Feld das relaxiert wird, wie bspw. p; alpha ist der Relaxfaktor - Wiederholung von oben):

Code:

---

  931     operator==(prevIter() + alpha*(*this - prevIter()));

---

Neuversuch der Erklärung: Equation Relaxation

• Baue Matrix
  
• Relaxiere Matrix
  
• Löse Matrix
  
• FeldRelaxation falls nötig (optional wenn implementiert; habs bislang nur für den Druck gefunden (aber nur für transonische Strömungen))
  

Was passiert beim Relaxieren der Matrix. Prinzipiell ganz einfach. Man nehme die Hauptdiagonale der Matrix und teilt alle durch den Relaxationsfaktor. Was kommt dabei raus? Die Werte der Hauptdiagonalen werden größer das die Linearen Löser toll finden. Wie bereits erwähnt darf man nicht einfach Werte irgendwo ändern (inkonsistent), daher werden die Änderungen in dem Quellvektor b berücksichtigt. Spielt aber hier für uns keine Rolle. Wichtig ist nur das die Hauptdiagonale in allen Zeilen vergrößert wird (der quantitative Wert).

ABER
die Relaxation einer Matrix setzt voraus dass die zu relaxierende Matrix einediagonal dominante oder zumindest diagonal gleichwerte Matrix ist. Ergo muss vor dem Relaxieren sichergestellt werden das die Matrix diesen Charakter hat. Demnach wird vor dem Relax Schritt die Matrix modifiziert (wenn nötig). Das geht wie folgt:

• Starte Matrixrelaxation
  
• Gehe durch alle Matrixzeilen
  
• Wenn Zeile DiagDominant -> geh zur nächsten
  
• Wenn Zeile nicht DiagDominant, mach diese Zeile DiagGleichwertig (oben beschrieben)
  

Nachdem die Matrix DiagDominant oder DiagGleichwertig ist, relaxiere (teile alle DiagElemente durch den Relaxfaktor) und sorge dafür das die Konsistent beibehalten wird.

So nun das spezielle bei Matrix Relaxation = 1. Wird für pEqn.relax(1) verwendet kannst du dir selber ableiten was passiert. Die Relaxation hat gar keinen Einfluss (Teilen durch 1) ABER wenn die Matrix nicht DiagDominant in allen Einträgen ist, dann werden die entsprechenden Einträge DiagGleichwertig, wodurch sich das Matrixsystem ändert und die Löser freuen sich. Für eine Relaxation kleiner Null wird der Funktionsaufruf unterbunden. Für Werte größer 1 erfolgt Überrelaxation. Man nimmt teile von den Sourcen in die Matrix (mehr impliziten Charakter) was aber nie gut geht (zumindest nicht oft).

Jetzt hab ich mich zwar wiederholt aber ich hoff das es jetzt klar ist. Ergo: Schockwellen haben zur Folge das du eine Matrix bekommst die nicht DiagDominant ist/sein kann, daher wird in den Tutorials der Relaxfaktor für pEqn 1; gesetzt. Du kannst dann auch 0.4 verwenden, was die Matrix-Diagonal-Dominanz um einiges verbessert und sich die Löser mit Gin-Tonic bei dir bedanken sollten. Allerdings erhöht man den Quellterm b und somit den expliziten Anteil, sodass wesentlich mehr Iterationen benötigt werden um die Konvergenz zu erhalten... ich könnt jetzt noch mehr darüber sprechen aber ich denke es wird langsam langweilig  

Weitere Infos

• SIMPLE braucht Unterrelaxation für das p Feld und UEqn. Sonst geht das niemals.
  
• In U -> flowRate solltest du vielleicht auch noch das Gamma mitberücksichtigen (nur als Anmerkung)
  
• Einträge mit "p.*" in den Relaxsettings sind nicht nötig, da du Stationär rechnest und hierbei kein Final Flag für das Lösen der Gleichungen gesetzt wird.
  

Analyse deines Cases
Ich versteh jetzt was du meinst. Nach 265 Iterationen ist dein Case konvergiert aber deine Konti macht Probleme. Scheint so als würde das Netz nicht wirklich durchlässig sein. Ich hab mit cfMesh nie gearbeitet des wegen hab ich deinen Case gelöscht, deine STL verkürzt und einen eigenen Case aufgesetzt. Das geht wohl viel schneller als deinen Case zu analysieren (ich geh stark davon aus das diese Interfaces die du da setzt von cfMesh nicht so definiert werden wie es sollte.

• Snappy Netz
  
• kEpsilon
  
• Standard thermophysicals
  
• SIMPLEC
  
• Usage of all dev options
  
• Relax U e k epsilon
  
• Relax p field
  

Es ist sogar so, dass ich nicht mal gezwungen bin die pEqn zu relaxieren. Aus diesen Erkenntnissen schließe ich auf ein Netzproblem. Ich weiß nicht wie du das AMI weg gemacht hast bzw. wie du deine MRF definierst. Muss ja mit cfMesh gemacht sein. Denk ich könnte es rausfinden aber heute schon genug Zeit in das Projekt von dir gesteckt und es ist (auch wenn ich eine Lösung jetzt präsentiere) nicht meine Aufgabe deine Aufgaben zu lösen :P

OpenFOAM Dev (Foundation) ATL Case | Sollte auch mit Foam-4.x (Foundation) laufen.

Was man hier dann noch machen müsste:

• Interface definieren für MRF Zone (geht easy mit snappy)
  
• Thermophysics anpassen
  
• U BC (gamma check)
  
• Mir viel Geld geben  
  

Gutes gelingen derweil.

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

---

Guten Morgen Tobias!!

Erstmal tausend Dank!! Jetzt läuft's, also zumindest der Test-Case, und anscheinend war der Fehler einfacher als gedacht...
Den richtigen Case teste ich jetzt damit. Sollte aber denke ich auch funktionieren.

Ich hab jetzt den Case von dir mit meinem verglichen und immer nach und nach zu meinem geändert.
Dein Case läuft auch mit meinem Netz und auch mit meinem MRF. Das einzige woran es letztendlich scheitert scheint einfach nur die Bedingungen vom k zu sein. Du hast da InletOutlet beim Outlet und ich zeroGradient. Was soll ich sagen, zeroGradient divergiert, während inletOutlet wunderschön durchläuft. Dann braucht es auch kein transonic mehr und alles wird "einfacher".

Selbst mit kOmegaSST läuft es so.

Also anscheinend lag es wirklich nur am k... Was ich aber noch nicht ganz verstehe ist, dass deine Residuen beim e quasi immer die doppelte Iteration haben. Also wenn es bei 100 fertig es, dann ist e bei 200. Ich finde aber nirgends etwas, was anders ist als bei mir... Also falls mir da noch erklären kannst woher das kommt wäre auch meine letzte Frage geklärt 

Und zwecks dem pEqn, ich hatte es anscheinend schon von Grund auf verstanden, nur dachte ich, dass das die Relax-Fields sind, also quasi die Fields und das pEqn durcheinander gehabt in meinen Gedanken. Hab's aber nun komplett verstanden  Vielen Dank auch nochmal für die Erklärung.

Das mit dem viel Geld wird leider schwierig als Student^^ Aber ich werde mein bestes geben, dich und deine Webseite hier in der Firma und auch an meiner FH und sonstwo immer zu erwähnen und anzupreisen  Hab ich ja jetzt eigentlich auch schon die ganze Zeit getan.

Viele Grüße,
Toni

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

---

Guten Morgen,

freut mich das es jetzt geht. Allerdings ist das mit der Turbulenten Kinetischen Energie recht interessant. Normalerweise sollte zeroGradient und inletOutlet nur DANN eine Auswirkung haben, wenn man U nicht beschränkt. Da inletOutlet die Fluxes verwendet und bei Inflow die von uns gesetzte Dirichlet-Bedingung verwendet. Bei Outflow ist es zeroGradient. Wenn man jetzt U am outlet mit inletOutlet definiert, dann gibt es keinen Inflow und daher wundert mich das schon sehr stark das es an k liegt. Hätte ich jetzt wirklich nicht gedacht und ich hab da jetzt ehrlich gesagt ADHOC keine Idee (Analyse unten).

Das mit den Iterationen der Energieerhaltung hab ich jetzt nicht so wirklich verstanden. Residuen und Iterationen sind zwei paar Schuhe aber ich denke du meinst das in meinem Fall die Berechnung von e einfach doppelt so viele Iterationen benötigt, oder? Da wäre jetzt erstmal die Frage ob du die OF-Dev verwendest       Ein Vergleich zwischen unterschiedlichen Versionen kann, muss aber nicht sinnvoll sein. Den einzigen Unterschied sehe ich gerade nur in den Relax für e. Ich hab 0.5 du hast 0.6, dass das ggf erklärt.

Mir fällt gerade auf, dass ich transonic und consistent gar nicht in den fvSolutions hab       War dann doch nicht so konsistent als ich dachte.

Bezüglich k
Ich hab meine Rechnung jetzt (100 Iterationen) laufen lassen mit k auf zeroGradient. Das läuft anstandslos       ... entsprechend sollte ich oben alles richtig analysiert haben und es sollte die U Randbedingung sein, die eben verhindert das du ein Rückströmen hast und dann ist eine zeroGradient Bedingung bei anderen Größen (sagen wir mal so) interessant      

Thema gelöst?
Wenn das Problem jetzt gelöst wurde, dann bitte als gelöst markiert   Entweder auf einen Beitrag von mir diesen grünen Hacken anklicken oder im nächsten Beitrag den grünen Hacken Smiley verwenden.

PS: Wenns dir nichts ausmacht, nehm ich den Case in meine Tutorialsektion auf (wenn ich mir die Arbeit schon gemacht hab).

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

---

Hi,

ja genau, meinte dass die Berechnung von e einfach doppelt so viele Iterationen benötigt. Am fvSolutions bzw. fvSchemes kann es nicht liegen, da die identisch sind/gemacht wurden.

Der "Fehler" bei k = zeroGradient am Outlet trat bei mir auch erst später auf, hatte ich vergessen zu erwähnen. Also bei k = InletOutlet läuft es bis ca. 510 Iterationen und wird dann durch die ResidualControl gestoppt. Bei k = zeroGradient läuft es nur bis ca. 160 Iterationen und divergiert dort. Alle anderen Randbedingungen kann ich genauso einstellen wie ich sie auch schon hatte.

Zwecks inletOutlet und zeroGradient fand ich hier eine sehr schöne Erklärung: http://www.cfdsupport.com/Turbomachinery-CFD-manual/node43.html
Also wahrscheinlich weniger Interessant für dich, aber doch sehr anschaulich für Anfänger wie mich.

Ja klar! Kannst sehr gerne das in deine Tutorials aufnehmen  Und das mit dem Haken ist quasi sogut wie geschehen 

Vielen Dank nochmals! 

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

---

Grüß dich Toni,

das mit der InletOutlet ist eine schöne Illustration. Vielleicht hilft es dem ein oder anderen, wenn er sich durch diesen Thread liest. Hier wäre jetzt natürlich sowas wie StackOverflow besser geeignet, damit die Lösung gleich an zweite Stelle kommt aber so ist das eben hier im Forum - die Lösung steht irgendwo - oder manchmal nirgends 

Gut, dann werde ich mal deinen Case die Tage in die Tutorial-Sektion aufnehmen. Zu der Tatsache mit deinem k fällt mir allerdings immer noch nichts ein. Merkwürdig aber sicher erklärbar, da ich den Case von mir gerade mit zeroGradient bis auf 1000 Iterationen laufen lassen hab und es gibt keine Divergenz (schau mir nur die Kontigleichung an). Übrigens, in meinem Fall brauch ich für die Energiegleichung nur 2 Iterationen. Mein Case + zeroGrad für k konvergiert nach 450 Iterationen:

Code:

---

smoothSolver:  Solving for Ux, Initial residual = 2.95852e-05, Final residual = 2.78864e-06, No Iterations 4
smoothSolver:  Solving for Uy, Initial residual = 2.00896e-05, Final residual = 6.75843e-07, No Iterations 6
smoothSolver:  Solving for Uz, Initial residual = 3.34864e-05, Final residual = 1.08669e-06, No Iterations 6
smoothSolver:  Solving for e, Initial residual = 0.000996532, Final residual = 1.1489e-05, No Iterations 2
GAMG:  Solving for p, Initial residual = 0.000166131, Final residual = 4.4597e-06, No Iterations 3
time step continuity errors : sum local = 0.00604504, global = -2.19489e-05, cumulative = 6.14067
smoothSolver:  Solving for epsilon, Initial residual = 2.40601e-05, Final residual = 1.10498e-06, No Iterations 4
smoothSolver:  Solving for k, Initial residual = 6.01246e-05, Final residual = 4.47413e-06, No Iterations 4
ExecutionTime = 259.9 s  ClockTime = 261 s

SIMPLE solution converged in 450 iterations

---

Grüße Tobi

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

---

Hey Tobias,

ich habe es gerade nochmal gestartet, weil ich dachte ich hätte es vorhin mit meinem Netz geladen und das vielleicht das Ergebnis beeinflusst.

Ja also mit meinem Netz kam ich bis ca. 160 und mit dem Netz von dir bis 60. Hab bei meinem Netz aber auch MRF schon drin gehabt und bei dem anderen nicht. Also das verfälscht natürlich etwas.
Normal läuft dein Case bei mir bis ca. 650 und konvergiert dann.

Liegt denn wahrscheinlich an der Version. Ich probier das gleiche heute Abend zu Hause nochmal mit der Version 4.1. Da sollte das ja denn ähnlich wie bei dir sein denke ich.

Auf jeden Fall seltsame Geschichte.

Zwecks den Energiegleichungen haben wir glaub ich aneinander vorbeigesprochen. Also ich meinte, dass man bei dem Residuenverlauf im Gnuplot sieht, dass e bei 200 Schritten steht, während alle anderen bei 100 Schritten sind. Hoffe du weißt was ich meine 

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

---

Hey,

das mit der Energiegleichung ist jetzt klar  dazu kann ich dir aber nix sagen weil das deine eigenen Skripte sind. Normalerweise hieße das, dass du die Energiegleichung zweimal löst, aber normal macht man das nur beim Druck (aber auch nicht immer). Meine Settings lösen jede Gleichung nur einmal. Zu den anderen Problemen mit "k". Das kann dann ein Code-Problem sein etc. - Bugs sind ja immer enthalten und manchmal nur ganz schwer zu finden. Entweder hat man das schon gemeldet und wurde behoben oder es ist noch niemandem aufgefallen  daher empfehle ich persönlich immer mit der neuesten Version zu arbeiten. Dann hättest du wohl möglich auch schon wesentlich weniger Probleme bekommen 

Grüße Tobi

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

---

Hey Tobias,

wollte mich nochmal zurückmelden.
Also das Problem mit den Residuen im Plot habe ich gelöst. War ein Fehler im Skript bei mir, wie du schon meintest.

Das mit den Versionen hab ich jetzt noch nicht weiter getestet, da ich schon am abstimmen meiner richtigen Turbine bin 

Funktioniert soweit anscheinend echt gut. Hab noch leichte Temperaturprobleme, aber auch das sollte jetzt losbar sein.

Viele Grüße,
Toni

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

---

Hi Toni,

hört sich doch gut an.
Übrigens gibt es seit heute die OpenFOAM Foundation Version 5.0. There are improvements in performance and reliability of numerics, e.g. for multiphase and compressible flows

Viel Erfolg weiterhin.

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

---

Hi,

hab ich schon gesehen  (hab ja deine FB Seite abboniert  )
Da ist mir auch sofort ins Auge gestochen, dass es Verbesserungen bei rhoSimpleFoam gibt und auch, dass man U begrenzen kann. Wäre beides top für meine Arbeit, aber ich glaube das bekomme ich hier nichtmehr durch, dass die hier das installieren auf Arbeit 

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

---

Die Geschwindigkeitslimitierung hab ich mir angeschaut. Bin mir aber immer noch nicht sicher warum das so ist wie es ist. Macht für mich derzeit keinen Sinn und eine kurze Nachrechnung hat auch keinen Sinn ergeben. Egal. Jedenfalls ist die Limiting Sache meines Erachtens nicht die beste Lösung da das U-Feld einfach gekappt wird. Heißt die Hauptdiagonale wird geändert aber nicht die Sourcen.

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