Autor
|
Thema: Freie Konvektion - Randbedingungen (7822 mal gelesen)
|
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 14. Feb. 2014 10:30 <-- editieren / zitieren --> Unities abgeben:
Hallo liebe OpenFOAM Gemeinde, ich habe ein Problem mit den Randbedingungen bei freier Konvektion. Ich habe auch schon im Forum gesucht, aber keine Beiträge gefunden, die mir wirklich weiterhelfen. Mein Problem ist mit Sicherheit für die Erfahren von euch, relativ einfach! Ich möchte gerne einen senkrechte, ebene Platte im Raum mit buoyantBoussinesqSimpleFoam berechnen. Dazu habe ich einen Quader generiert, der an einer Seite eine kleine Fläche besitzt, welche ein dT zum Raum von 40 K besitzt. Alle anderen Flächen sollen die Atmosphäre darstellen. Ich habe mich an dem hotRoom aus dem Tutorial orientiert, aber hier sind die Seiten ja als Wände definiert, von daher komme ich damit auch nicht weiter- p-File: ist als "calculated" definiert. T-File: ist auch klar, die Definition passt. Mein Problem sind die Files p_rgh und u: Im u-File habe ich alle freien Flächen als "zeroGradient" definiert und die beheizte Platte als "fixedValue". Im p_rgh-File habe ich schon alle möglichen Einstellung ausprobiert und komme auf keinen grünen Zweig! Meine Geschwindigkeiten sind viel zu niedrig. Kann mir jemand einen Tipp geben, wie ich die 6 Flächen zur Atmosphäre hin deklarieren muss? Gerne lade ich auch meinen Fall hier hoch - falls es hilft. Viele Grüße Michael
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
badim Mitglied
Beiträge: 12 Registriert: 28.01.2014
|
erstellt am: 14. Feb. 2014 11:13 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Bei mir haben folgende Randbedingungen bisher gut funktioniert. Ob es alternative oder sogar bessere Lösungen gibt, weiß ich nicht. Die Flächen heißen minX, maxX, minY, maxY, minZ und maxZ. Gravitation ist in diesem Beispiel: (0 0 -9.81). Die Deckfläche (hier maxZ) hat andere Eigenschaften als die restlichen Flächen. T:
Code:
minX { type inletOutlet; value uniform 293.15; inletValue uniform 293.15; } maxX { type inletOutlet; value uniform 293.15; inletValue uniform 293.15; } minY { type inletOutlet; value uniform 293.15; inletValue uniform 293.15; } maxY { type inletOutlet; value uniform 293.15; inletValue uniform 293.15; } minZ { type inletOutlet; value uniform 293.15; inletValue uniform 293.15; } maxZ { type inletOutlet; value uniform 293.15; inletValue uniform 293.15; }
U:
Code: minX { type pressureInletOutletVelocity; value uniform ( 0 0 0 ); } maxX { type pressureInletOutletVelocity; value uniform ( 0 0 0 ); } minY { type pressureInletOutletVelocity; value uniform ( 0 0 0 ); } maxY { type pressureInletOutletVelocity; value uniform ( 0 0 0 ); } minZ { type pressureInletOutletVelocity; value uniform ( 0 0 0 ); } maxZ { type inletOutlet; value uniform ( 0 0 0 ); inletValue uniform ( 0 0 0 ); }
p_rgh:
Code: minX { type totalPressure; value uniform 100000; U U; gamma 1; p0 uniform 100000; phi phi; psi none; rho rho; } maxX { type totalPressure; value uniform 100000; U U; gamma 1; p0 uniform 100000; phi phi; psi none; rho rho; } minY { type totalPressure; value uniform 100000; U U; gamma 1; p0 uniform 100000; phi phi; psi none; rho rho; } maxY { type totalPressure; value uniform 100000; U U; gamma 1; p0 uniform 100000; phi phi; psi none; rho rho; } minZ { type totalPressure; value uniform 100000; U U; gamma 1; p0 uniform 100000; phi phi; psi none; rho rho; } maxZ { type fixedFluxPressure; value uniform 100000; }
EDIT: Fehler in p_rgh EDIT: noch ein Fehler in p_rgh
[Diese Nachricht wurde von badim am 14. Feb. 2014 editiert.] [Diese Nachricht wurde von badim am 19. Feb. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 14. Feb. 2014 11:40 <-- editieren / zitieren --> Unities abgeben:
|
badim Mitglied
Beiträge: 12 Registriert: 28.01.2014
|
erstellt am: 14. Feb. 2014 11:47 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Oh, das "Boussinesq" hab ich überlesen. Ich nutze normalerweise chtMultiRegionSimpleFoam. Das wäre die normale buoyantSimpleFoam Variante. Du wirst die Randbedingungen möglicherweise nicht 1-zu-1 übernehmen können, aber probiere es einfach mal aus. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 14. Feb. 2014 12:10 <-- editieren / zitieren --> Unities abgeben:
|
badim Mitglied
Beiträge: 12 Registriert: 28.01.2014
|
erstellt am: 14. Feb. 2014 12:15 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Die Beispiele in den buoyantBoussinesqSimpleFoam Tutorials sollten funktionieren, wobei value hier wohl auch 100000 statt 0 sein sollte. Code: ceiling { type fixedFluxPressure; rho rhok; value uniform 100000; }
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 15. Feb. 2014 14:32 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, gestern bei der Arbeit sahen meine Ergebnisse garnicht so schlecht aus. Heute wollte ich den Case Zuhause nachbauen und auf "buoyantSimpleFoam" ändern und nun sieht das Strömungsbild wieder nicht gut aus. Der Case ist angehängt - wäre schön, wenn sich den mal jemand anschauen könnte. Viele Grüße Michael
[Diese Nachricht wurde von Micha6982 am 15. Feb. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 17. Feb. 2014 19:40 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo, ohne jetzt das ausgetestet zu haben glaube ich das ich dein Problem einschränken kann. Du hast beim buoyantSimpleFoam wahrscheinlich das Problem, dass du kein guten Wärmeübergang hast oder? Das liegt ggf. an der Berechnung des Diffusionsterms. buoyantBoussinesqSimpleFoam
Code:
volScalarField alphaEff("alphaEff", turbulence->nu()/Pr + alphat); - fvm::laplacian(alphaEff, T)
buoyantSimpleFoam Berechnung durch Enthalpie "h" oder Energie "e". Wie alphaEff da berechnet wird müsste man nachschauen. ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 17. Feb. 2014 20:23 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobias, vielen Dank für deine Antwort. Ich stecke in den Solvern noch noch nicht so tief drin, um das zu beurteilen. Aber ich hatte heute mit dem buoyantSimpleFoam die richtigen Ergebnisse, nur habe ich leider den Fehler gemacht, dass ich noch ein paar Einstellungen (Randbedingungen) verändert habe und dann ging es nicht mehr. Leider weiß ich vor lauter herumprobieren auch nicht mehr, mit welchen Einstellungen ich es hin bekommen habe (ich hätte den Case sichern sollen Ich komme noch nicht mit den ganzen Randbedinungen zurecht. Daher wäre es sehr hilfreich, wenn hier mal jemand drüber schauen könnte. Viele Grüße Michael Leck
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 17. Feb. 2014 20:26 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hmmm,... also ist meine Aussage wohl nicht richtig. War auch nur eine Spekulation. Sobald "Eff" verwendet wird ist normalerweise immer laminar + turbulent gegeben. Sofar war meine Aussage also doch falsch. Deine BC habe ich mal angeschaut. Mir fällt jetzt direkt nichts auf was falsch sein könnte. Geht deine Simulation jetzt bzw. wie ist den der Sinne der Simulation? Soweit ich das beurteilen kann hast du eine ebene Platte (T=konst.) im Raum. ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 17. Feb. 2014 20:41 <-- editieren / zitieren --> Unities abgeben:
Der Sinn der Simulation ist es, die richtigen Parameter für die Berechnung von freier Konvektion zu ermitteln und diese dann auf meine richtige Geometrie anzuwenden. Ich möchte gerne den mit OpenFOAM ermittelten Wärmestrom mit Korrelationen und einer, mir an der Arbeit zur Verfügung stehenden kommerziellen Software, vergleichen. Wenn ich diesen Vergleich noch von verschiedenen Geometrien und Randbedingungen (Medium, dT usw.) habe, möchte ich an die Geometrie meiner Abschlussarbeit gehen. Ich habe die Vermutung, dass es irgendwo an der alphat oder mut Datei liegt. Bin mir aber nicht ganz sicher. Bei mir strömt meistens immer etwas von oben ins Rechengebiet ein, oder ich habe das Problem, das nichts ausströmt und sich in dem Gebiet Wirbel bilden. Mit einer Einstellung ging es heute, da lag die Abweichung der maximale Geschwindigkeit und des Wärmestroms bei allen drei Methoden nur ein paar Prozent auseinander. Nur, wie schon erwähnt, war ich ein wenig zu schnell Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
badim Mitglied
Beiträge: 12 Registriert: 28.01.2014
|
erstellt am: 17. Feb. 2014 21:01 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Zitat: Original erstellt von Micha6982: Bei mir strömt meistens immer etwas von oben ins Rechengebiet ein, oder ich habe das Problem, das nichts ausströmt und sich in dem Gebiet Wirbel bilden. [/B]
Bitte lies dir nochmal meinen ersten Post durch. Darin habe ich geschrieben, dass du die Deckfläche als normales inletOutlet definieren musst (T: inletOutlet, U: inletOutlet, p_rgh: fixedFluxPressure). Ansonsten findet der Solver den "Ausgang" nicht. EDIT: Falsche Angabe zu p_rgh. [Diese Nachricht wurde von badim am 17. Feb. 2014 editiert.] [Diese Nachricht wurde von badim am 19. Feb. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 17. Feb. 2014 21:22 <-- editieren / zitieren --> Unities abgeben:
Auch dir badim, danke für deine Antwort. Was genau meinst du mit Deckfläche? Die oberste Fläche zur Atmosphäre? Falls ja, dann gibt es die bei mir nicht, da ich alle Flächen der Atmosphäre zusammengefügt habe. Dadurch habe ich nur die beheizte Platte und die Atmosphäre als Fläche. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
badim Mitglied
Beiträge: 12 Registriert: 28.01.2014
|
erstellt am: 17. Feb. 2014 21:25 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
|
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 17. Feb. 2014 21:37 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Noch nen Hinweis, Turbulenzmodell oder Laminar - so wie ich das beurteile hast du nur laminare Strömungen. mut und alphat kannst du auch löschen. OpenFOAM generiert diese automatisch. Außer du möchtest natürlich andere Wandfunktionen etc. verwenden. ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 18. Feb. 2014 12:26 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, vielen Dank für Euere Rückmeldung. @ Tobias: Ich habe jetzt bemerkt, dass man das alphat in der Boussinesq-Variante nicht weg lassen kann. Dort meckert er, dass er diese Datei nicht findet. Beim normalen buoyant geht es und somit fallen mir da schon ein paar Fehlerquellen weg! @badim: Ich habe meinen Case (Boussinesq-Variante) jetzt so geändert, wie du es empfohlen hast. Leider kommen hier auch keine sinnvollen Ergebnisse zustande :-( Der Case ist im Anhang, vllt. kannst du da nochmal drüber schauen, ob ich noch was falsch gemacht habe? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 18. Feb. 2014 12:44 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo Micha, ich habe gestern Nacht nochmals über deinen Case geschaut und mir ist aufgefallen, dass kein wirklicher Wärmeübergang stattfindet bzw. die Lösung in deinem Gebiet unphysikalisch sind. Heute komm ich nicht mehr dazu deinen Case nochmals zu betrachten aber ggf. morgen. Meines Erachtens benötigst du kein Turbulenzmodell. Bei dir scheint es freie Konvektion unter laminarer Strömung zu sein. ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 18. Feb. 2014 12:59 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobias, schon mal vielen Dank, dass du dir das anschauen möchtest! Ich habe einen Fall, bei dem sieht das Strömungs- und Temperaturbild einigermaßen gut aus und der Wärmeübergang scheint zu funktionieren. Im Anhang zwei Bilder. Mit der Turbulenz wirst du recht haben und ich bin hier laminar. Bei meinem realen Fall kann es dann aber durchaus auf turbulent überschlagen. Daher wollte ich gerne beides testen. Oder siehst du mit der Turbulenz Probleme? P.S.: Bei dem oberen, von mir erwähnten Fall, passt aber der Wärmestrom und die Temperatur nicht ganz richtig. Auch ist der Bereich der Strömung zu groß.
Viele Grüße Michael
[Diese Nachricht wurde von Micha6982 am 18. Feb. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 18. Feb. 2014 13:15 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo Micha, ich hätte eine kurze Frage zu deinem Temperatur/Geschwindigkeitsfeld. Wenn ich annehme, dass eine kleine Platte auf der linken Seite beheizt wird, dann sollte sich meines Erachtens kein solch Strömungsfeld einstellen. Da ich keine Vektoren sehe, kommt es mir so vor als würde die Strömung über die Platte nach oben strömen, dann einen extremen 90° Bogen machen und dann oben hin wegströmen. Vielleicht sehe ich das auch falsch. ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 18. Feb. 2014 14:47 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobias, da hast du vollkommen Recht! Ich wollte mit diesem Case nur zeigen, dass sich hier was tun kann (Wärmeübergang). Physikalisch sinnvoll es ist leider nicht, wie du an dem Vektorplot sehen kannst. Es zeigt genau die Strömung, wie du sie gerade beschrieben hast. Aber leider ist dieser Case mein bestes Ergebnis :-( Ich vermute das die Randbedingungen der Umgebung oder der Platte nicht richtig passen! Daher drückt dann auch die Strömung von links ins Berechnungsfeld. Viele Grüße Michael
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 18. Feb. 2014 16:44 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo Micha, ich würd dir die RB vom Kollegen empfehlen. An der linken Seite ein inletOutlet zu setzen und den inletValue Wert auf (0 0 0) zu setzen. Damit verhinderst du Rückströmung ins Gebiet. ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
badim Mitglied
Beiträge: 12 Registriert: 28.01.2014
|
erstellt am: 19. Feb. 2014 15:06 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Ohoh, mir ist gerade aufgefallen, dass da noch ein Fehler in meinen Angaben zu p_rgh war. Das p_rgh für die Deckfläche muss fixedFluxPressure sein. Ich hatte aus Versehen fixedValue geschrieben. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 21. Feb. 2014 15:12 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, entschuldigt bitte, dass ich mich so lange nicht gemeldet habe. Ich bin aber gesundheitlich ein wenig angeschlagen und konnte daher eure Vorschläg nicht zeitnahe umsetzen. Ich habe heute eure Einstellungen versucht und habe leider auch keine vernünftigen Ergebnisse erzielt. Ich habe dann ein wenig weiter probiert und habe Einstellungen gefundenm die gar nicht so schlecht aussehen. Nur ist die Geschwindigkeit zu hoch und der Wärmestrom zu niedrig. Hat hier vllt. jemand eine Idee? Ausserdem wollte ich jetzt von buoyantBoussinesqSimpleFoam auf buoyantSimpleFoam umsteigen, und hier kommen wieder ganz andere Ergebnisse heraus. Hat hierzu jemand eine Idee? Anbei noch meine Plots, qualitativ sind die Bilder ganz gut. Viele Grüße Michael
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 22. Feb. 2014 15:57 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo zusammen, 1. boussinesq Solver sind durch die Dichte geteilt worden vgl. inkompressilbe Löser. Danach leitet sich auch der Druck ab! Achtung: Die Druckwerte müssen mit der Dichte multipliziert werden um die realen Werte zu erhalten. 2. Im Anhang mal eine kleine Simulation von mir... am Auslass ist noch zu erkennen, dass das nicht so gut aussieht. Nichts desto trotz ist meines Erachtens diese Lösung physikalisch richtig und sinnvoll bzw. plausibel (im Bereich der heißen Wand). Der Case liegt hier: http://www.holzmann-cfd.de/index.php/tutorial Hoffe das hilft weiter. ------------------ Grüße Tobias Holzmann
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 22. Feb. 2014 17:03 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobias, ich habe jetzt mal deinen Case mit der Version 2.2.2 durchgerechnet und meine Plots sehen ganz anders aus, als bei dir! Hier wurde doch nichts zur Version 2.3.0 geändert, oder? Wenn ich das auch richtig sehe, dann strömst du mit einer Geschwindigkeit von 0.00 m/s ein, oder? Welches Programm zur Auswertung nutzt du eigentlich? Viele Grüße Michael
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 22. Feb. 2014 17:18 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo Michael, wenn du den Case in 2.2 ohne Probleme starten kannst, sollte es auch keine Änderung gegeben haben - das ist natürlich ohne Gewähr. Es gab von 2.1 auf 2.2 eine größere Änderung am Code und den Klassen. Ich hab es gerade nochmals berechnet und bei mir kommt das gleiche raus wie im letzten Post von mir angedeutet. a) Ich verwende Paraview für die Auswertung + pyFoam // Bild zeigt Residuen die aber auch nicht wirklich schön sind b) Es kann sein das dein OpenFOAM ggf. kaputt ist. Hast du selber schon programmiert und Dinge verändert? Kompilierst du selber oder nutzt du bestehende debs? c) Hast du mein Skript verwendet oder hast du die Eingaben selber getätigt? d) Ich gebe ein Strömungsfeld von (0 0.001 0) m/s vor. Das hat was mit der Numerik zu tun. Eingeströmt wird nirgends - es sei den du hättest ein fixedValue
e) was mir gerade noch einfällt ... in meinem Case sollte man die Genauigkeit der berechneten Größen erhöhen. Ca. 12 - 15 Nachkommastellen wäre gut. Edit: Ich teste es schnell mit 2.2.x
------------------ Grüße Tobias Holzmann
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 22. Feb. 2014 17:27 <-- editieren / zitieren --> Unities abgeben:
Ich habe noch nichts dran herum programmiert oder ähnliches. Soweit bin ich bei Weitem noch nicht. Gestartet habe ich es mit deinem Skript. Hast du es mal mit der Version 2.2.2 gerechnet? Grüße Michael P.S.: Warst schneller als ich - wegen dem Test!
[Diese Nachricht wurde von Micha6982 am 22. Feb. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 22. Feb. 2014 18:54 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Also es gibt bei der 2.3 eine Erweiterung in der Druck-Korrektur-Gleichung bzw. eine Zusatzkorrektur. Kann definitiv die Ursache daran liegen. Die Implementierung geht aber adhoc nicht so wie ich das will Auf die schnelle schaff ich das simple Problem bei 2.2.x jetzt auch nicht zu beheben. Hilft nur - 2.3. verwenden (vor ab).
------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 22. Feb. 2014 19:51 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Wenn ich die Werte von 2.3 für die Initialisierung von 2.2 verwende funktioniert es auch. Entsprechend ist der Löser einfach nicht sehr stabil für genau diese Berechnung. Wahrscheinlich ist deswegen auch der Zusatzterm bei 2.3 enthalten. Ich teste noch weiter. ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 23. Feb. 2014 06:59 <-- editieren / zitieren --> Unities abgeben:
Guten Morgen, in deinem Beispiel-Case wird doch initialisiert, oder? Zitat: Original erstellt von Shor-ty: Wenn ich die Werte von 2.3 für die Initialisierung von 2.2 verwende funktioniert es auch. Entsprechend ist der Löser einfach nicht sehr stabil für genau diese Berechnung. Wahrscheinlich ist deswegen auch der Zusatzterm bei 2.3 enthalten. Ich teste noch weiter.
Und bei mir kam dann das Ergebnis raus, von dem ich die Bilder online gestellt habe. Oder hast du noch was anderes gemacht? Viele Grüße Michael
EDIT: Kannst du den Case, der unter 2.2.2 läuft mal hochladen? [Diese Nachricht wurde von Micha6982 am 23. Feb. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 23. Feb. 2014 11:16 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hi, nein ich initialisiere keine Lösung bei meinem 2.3er Case. Es gibt bei der OpenFOAM 2.2 Variante Instabilitäten. Diese sind in Version 2.3 behoben worden, in dem die oben genannte Ergänzung in der Druck-Korrektur-Gleichung gemacht wird.
Die Sache in 2.2 läuft nur wenn du eine gute Vorablösung hast. In meinem Fall habe ich die Lösung von 2.3 auf 2.2 gemapped und von dort aus weitergerechnet. Dann passt das alles wunderbar. ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 23. Feb. 2014 11:39 <-- editieren / zitieren --> Unities abgeben:
|
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 23. Feb. 2014 17:27 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, wie angekündigt habe ich heute noch ein wenig herumprobiert. Kann mir jemand erklären, was es eigentlich mit dem p_rgh-File zu tun hat? Auch sind mir die möglichen Einstellungen unklar. Nichts desto trotz habe ich ein paar Bilder angehängt. Die ersten beiden Bilder zeigen Tobias seinen Fall, den ich ein wenig verändert habe (herumprobiert). Die Bilder sehen nicht unbedingt sinnvoll aus. Die Geschwindigkeit beim 2. würde aber sehr genau mit meinen Vorberechnungen passen. Das dritte Bild zeigt meinen 3D-Case. Hier würde ich die Strömung als realistisch einstufen. Nur leider ist die Geschwindigkeit zu hoch und der Wärmestrom zu niedrig. Auch klappt der Umstieg von buoyantBoussinesqSimpleFoam auf buoyantSimpleFoam nicht. Hier kommen bei den gleichen Randbedingungen ganz verschiedene Berechnungen raus bzw. er rechnet garnicht! Hat hierzu jemand noch Ideen?
------------------ --- Viele Grüße Michael Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 23. Feb. 2014 17:40 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo, also ich versteh nicht wieso du es als nicht sinnvoll findest, wenn die Strömung nach oben weg steigt (senkrecht). Wenn ich mir eine laminare Strömung vorstelle, dann kann ich keine so extreme Richtungsänderung verstehen, wie du Sie auf deinem Bildern aufzeigst. Du rechnest wahrscheinlich turbulent in einem laminaren Strömungsraum. D.h. du hast defintiv eine Fehlerquelle mehr drin. Zudem wirst du sicherlich alles nur mit dem Upwind Verfahren rechnen, oder? Wenn du mal eine Variante 2. Ordnung verwendest werden deine Werte schon gleich anders aussehen. Wie berechnest du den Wärmestrom? ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 23. Feb. 2014 18:10 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobias, bei der ersten Variante, bei der die Strömung senkrecht nach oben geht, siehst du auf dem Vektorplot, dass über den kompletten unteren Bereich eingeströmt wird und das ist aus meiner Sicht unphysikalisch. Hier finde ich das Bild der Variante 3 besser. Ob die Strömung direkt senkrecht nach oben geht oder einen leichten Bogen mach, kann ich an dieser Stelle nicht beurteilen. Es könnte sein, dass die Strömung an der Kante abreißt oder eben auch nicht. Die Variante 3 ist laminar gerechnet. Das mit der höheren Ordnung könnte ich mal noch versuchen - das ist ein guter Ansatz! Den Wärmestrom bestimme ich mit dem normal wallHeatFlux-tool. Ist das Falsch?
------------------ --- Viele Grüße Michael Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 23. Feb. 2014 18:39 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hey, also das ist richtig (Vektorplot). Aber das liegt bei mir an meiner Randbedingung (slip). Diese müssen natürlich dann geändert werden Ich meinte wie du den Wärmestrom von Hand berechnet hast (genauso wie die Geschwindigkeit).
------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 23. Feb. 2014 18:52 <-- editieren / zitieren --> Unities abgeben:
Jetzt verstehe ich was du meinst Ich habe dafür eine Nusselt-Korrelation aus dem VDI-Wärmeatlas verwendet. Die Geschwindigkeit habe ich mit einer Umrechnung der Grashof-Zahl zu einer äquivalenten Renoylds-Zahl ermittelt. Parallel habe ich eine identische Berechnung mit Fluent gemacht und meine Ergebnisse stimmen beide (U und Q-punkt) bis auf ein paar Prozent überein. Du hast bei deinem Case die Seiten als "slip" deklariert. Ist das nur eine Vereinfachung (Seiten mit "slip") oder ist das eine richtige Randbedinung? In was muss diese geändert werden?
------------------ --- Viele Grüße Michael Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 23. Feb. 2014 18:56 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
|
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 23. Feb. 2014 19:07 <-- editieren / zitieren --> Unities abgeben:
|
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 23. Feb. 2014 20:16 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Also nochmals im Klartext. Die Slipbedingung habe ich gewählt um einfach ne simple Lösung zu erhalten. Wenn du links und rechts Atmosphere mit inlet/outlet hast, dann muss du das ändern (wie sehen den die Verläufe von ANSYS aus?).
Welche RB du verwenden solltest --> siehe weiter oben. ------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 28. Feb. 2014 17:36 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, ich habe jetzt meinen Case soweit geändert, dass vernünftige Werte herauskommen. Ich konnte aber nicht alle Empfehlungen für die Randbedingungen von hier verwenden. Ich habe mir auch nochmal den Fluent Case genau angeschaut. Hatte mich nur auf die quantitativen Ergebnisse verlassen Die Strömung löst leicht an der Kante ab. Man erkennt, dass vom linken Rand Luft nachströmt. Ob das so richtig ist, sei dahingestellt - bin mir da im Moment auch nicht so sicher. Um auf den richtigen HeatFlux zu kommen, habe ich die Stoffwerte etwas genauer eingegeben, als sie hinterlegt sind. Das Ergebnis war, dass der HeatFlux bis auf ein paar Prozent übereinstimmt! Nun habe ich eine andere Geomtrie und stoße hier wieder auf ähnliche Probleme. Spannend ist, dass die Einstellungen in der p_rgh Datei nicht mit allen Solvern funktionieren. Bekomme ich noch in buoyantBoussinesqSimpleFoam sinnvolle Ergebnisse, stürzt mir der Case mit den gleichen Einstellungen im buoyantSimpleFoam ab. Mit anderen Einstellungen wiederrum geht rechnet er, auch wenn nichts vernünftiges bei raus kommt.
Hat hierzu jemand einen Tipp? ------------------ Viele Grüße Michael Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 28. Feb. 2014 21:52 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo zusammen, ob nach deiner beheizten Fläche etwas einströmt oder nicht, hängt von deinen Parametern bzw. den Randbedingungen ab. Man kann eine Simulation gänzlich verfälschen, indem falsche Bedingungen gewählt, oder das Strömungsfeld an stark beeinflussten Gebieten einfach nicht abbildet wird. So ist beispielsweise bei der Simulation einer COH2N2 Flamme der Brenner (ein Teil davon zumindest) auch mit abzubilden. Wird die Brennerlanze weggeschnitten, so erhält man große Abweichungen zur Messung. In deinem Fall, also der beheizten Fläche, ist natürlich das direkt darauf folgende Strömungsgebiet sehr stark in Interaktion mit der Aufsteigenden Strömung. Nach deiner Heizfläche wird aber direkt das Strömungsfeld (nach links) nicht abgebildet. Wenn du beispielsweise ein andere Geometrie verwendest, sieht dein Ergebnis vielleicht viel besser aus (mit einer nach links erweiterten ńumerischen Domain). Deswegen sollte und muss man sich immer Gedanken machen wie viel abzubilden ist oder was vernachlässigt werden kann. In deinem Fall, wird die Strömung sicherlich eine Interaktion mit einem Teil der Luft eingehen, die nicht abgebildet ist. Das mit RB aufzufangen kann möglich sein, muss aber nicht. Du hast ein Fluent Case aufgesetzt und die Ergebnisse sehen gut aus. Du hast ein OpenFOAM Case aufgesetzt und die Ergebnisse sehen auch gut aus. Demnach kannst du die Vereinfachungen mit großer Wahrscheinlichkeit für diesen Testfall treffen. Aber diese Bedingungen auf ein anderen Fall zu übertragen kann falsch sein. Ist das Problem ähnlich, werden die RB sicherlich auch gleich/ähnlich sein aber es muss nicht. Beispielsweise kann in dem Fall der beheizten Fläche die Interaktion mit dem nicht abgebildeten Strömungsfeld schwächer sein oder dein zu interessierenden Bereich gar nicht beeinflussen, hingegen im anderen Fall dann schon. Dann kurz einige Worte zu den Lösern von buoyant und boussinesq. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Buoyant ist eine dichtebasierter Strömungslöser für kompressible Strömungen. Das heißt die Dichte (rho) wird in den Gleichungen berücksichtigt und dein Druck ist in Pascal [Pa] angegeben: p_rgh von buoyant Code:
dimensions [1 -1 -2 0 0 0 0];
p_rgh von boussinesq Code:
dimensions [0 2 -2 0 0 0 0];
Analog sieht die Impulsgleichung aus (links: boussinesq, rechts: buoyant):
Code:
tmp<fvVectorMatrix> UEqn | tmp<fvVectorMatrix> UEqn ( | ( fvm::Div(phi, U) | fvm::Div(phi, U) + turbulence->divDevReff(U) | + turbulence->divDevRhoReff(U) == | == fvOptions(U) | fvOptions(rho, U) ); | );
Wie man daran schon erkennen kann, ist der boussinesq Löser mit der Dichte dividiert worden (vgl. alle inkompressiblen Strömungen). Aus diesem Grund arbeitet man dort immer mit relativen Drücken. Möchte man den richtigen Druck wissen, muss dieser natürlich mit der Dichte multipliziert werden. Die Gravitation im Boussinesq Solver wird eben durch die von Herrn Joseph Boussinesq vorgeschlagene Approximation berechnet und als Scheingravitation bezeichnet (soweit ich mich noch richtig erinnere). Siehe http://de.wikipedia.org/wiki/Boussinesq-Approximation Im anderen Fall ist die Graviation g konstant und der Auftrieb wird mittels der Dichte berechnet. Daraus lässt sich ableiten, dass p_rgh in buoyant nicht gleich p_rgh im boussinesq Löser ist.
Desweiteren ist natürlich vor allem bei Wärmeübergängen das numerische Netz entscheidend. Zudem kommt noch eine oft diskutierte Thematik der Strömung dazu: laminar oder turbulent. Beim letzteren ist dann auch ganz entscheidend welches Turbulenzmodell verwendet wird. k-Epsilon für solche Strömungen ist kein guter Startansatz, da dieses Modell vor allem für wandferne Strömungen Gültigkeit besitzt und in Wandnähe (ich bin mir nicht mehr sicher) entweder die Dissipation oder kinetische Energie zu hoch/niedrig berechnet wird. Gängige Methoden sind dann - Änderung der Turbulenzmodellparameter - von dem ich persönlich allerdings nicht sehr viel halte.
Diesbezüglich sollte man sich kundig machen welches Modell am Besten für die jeweilige Problematik geeignet ist und die Effekte quantitativ gut wiedergibt. K-Epsilon hat halt den Vorteil, dass es sehr robust ist. D.h. hohe Falscheingaben werden meistens nicht zum Abbruch führen. Damit ist natürlich eine Vorberechnung sinnvoll, um dann auf ein anderes Modell umzuswitchen. Hier eine Liste der Turbulenzmodelle die im boussinesq verwenden könnte (13):
Code:
LRR LamBremhorstKE LaunderGibsonRSTM LaunderSharmaKE LienCubicKE LienCubicKELowRe LienLeschzinerLowRe NonlinearKEShih RNGkEpsilon SpalartAllmaras kEpsilon kOmega kOmegaSST kkLOmega laminar qZeta realizableKE v2f
Hier die Turbulenzmodelle die für buoyant verwenden könnten (10):
Code:
LRR LaunderGibsonRSTM LaunderSharmaKE RNGkEpsilon SpalartAllmaras kEpsilon kOmegaSST laminar realizableKE v2f
Das war jetz etwas mehr als ich eigentlich mitteilen wollte aber ich hoffe das es euch einen größeren Überblick gibt.
Bedenkt: CFD ist nur so Leistungsstark wie die Eingabe ist. Außerdem arbeitet man mit Modellansätze die Gültigkeitsbereiche haben, Schemen die gravierenden Einfluss auf die Ergebnisse haben, Netze die verschiedene Eigenschaften aufweisen und die Schemen (Interpolationen) stark beeinflussen usw. usf.
------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 10. Mrz. 2014 19:41 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, wie kann ich denn den Beitrag als erledigt abhaken? Die Lösung liegt wie vermutet im p_rgh File. Hier ist der Boden als Referenz mit "totalPressure" zu definieren und die anderen Flächen (Atmosphäre) als "inletOutlet". Das U-File bekommt "pressureInletOutletVelocity" und die Temperatur "inletOutlet" --> jeweils für die atmosphärischen Flächen. Der Rest sollte klar sein. Diese Information war in irgend einem alten Beitrag in einem englischen versteckt. Danke für eure Hilfe hier! Ich habe bestimmt in Zukunft noch ein paar weitere Fragen ------------------ Viele Grüße Michael Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
easwood Mitglied
Beiträge: 11 Registriert: 22.01.2014
|
erstellt am: 12. Mrz. 2014 17:12 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo, ich habe im Moment folgendes Problem mit dem buoyantBoussinesqSimpleFoam-Solver: Ich möchte als T-RB eine konstante Wärmestromdichte vorgeben. Dafür verwende ich: type compressible::turbulentHeatFluxTemperature; heatSource flux; // power [W]; flux [W/m2] q uniform 10; // heat power or flux kappa fluidThermo; // calculate kappa=alphaEff*thermo.Cp kappaName kappa; Qr none; // name of the radiative flux value uniform 300; // initial temperature value Ich bekomme damit folgende Fehlermeldung: Kappa defined to employ fluidThermo method, but thermo package not available Wie kann ich diese RB auf den Solver buoyantBoussinesqSimpleFoam anpassen? Danke für eure Hilfe Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 12. Mrz. 2014 20:15 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
wie wäre es ohne compressible:: und anstatt kappa = alpha ? Do not mix up "Density Based Solver and Non Density Based Solver"
Am Besten du gibst einfach nur den Typ ein, startest den Solver und ergänzt die RB bis keine Fehler mehr kommen oder erhasche dir die Funktionsweise im QC (Quellcode).
@micha ich habe dir eine PN geschrieben.
------------------ Grüße Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
easwood Mitglied
Beiträge: 11 Registriert: 22.01.2014
|
erstellt am: 13. Mrz. 2014 10:04 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
|
dodobenq Mitglied Student
Beiträge: 3 Registriert: 04.11.2015 OF 2.4.X Ubuntu 14.04.3 LTS
|
erstellt am: 04. Nov. 2015 09:52 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hey! Auch wenn der Thread schon etwas älter ist, habe ich eine Frage an dich Michael. Waren deine BC letztendlich folgende? p_rgh: hot wall: fixedFluxpressure top: inletOutlet bottom: totalPressure front, sides: inletOutlet ------------ T: hot wall: fixedValue top: inletOutlet bottom: inletOutlet front, sides: inletOutlet ------------ U: hot wall: fixedValue top: pressureInletOutletVelocity bottom: pressureInletOutletVelocity front, sides: pressureInletOutletVelocity Zitat: und die anderen Flächen (Atmosphäre)
das habe ich so gedeutet, dass du "top" (also den Ausgang, outlet) auch zu der Atmosphäre zählst. Oder besitzt der patch "top" doch andere BC als ich oben angegeben habe? _____ Gruß Dominik
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 04. Nov. 2015 13:07 <-- editieren / zitieren --> Unities abgeben:
Hallo Dominik, im Prinzip habe ich ein Rohr simuliert, welches frei im Raum hängt. Somit sind alle "Wände" ringsherum Atmosphäre. Die Einstellungen sind so richtig. ------------------ Viele Grüße Michael Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 05. Nov. 2015 10:47 <-- editieren / zitieren --> Unities abgeben: Nur für Micha6982
Hallo zusammen, Die settings für p_rgh sind sicher physikalisch sinnfrei, auch wenn es in dem Fall, wenn für U ein Backflow verhindert wird, es stimmt. Ansonsten sicher nicht. ------------------ Viele Grüße, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Micha6982 Mitglied Akademischer Mitarbeiter
Beiträge: 130 Registriert: 20.01.2014 ubuntu 16.04 Salome 7.7.1 & 7.8.0 OpenFOAM 3.x & 4.x
|
erstellt am: 05. Nov. 2015 11:09 <-- editieren / zitieren --> Unities abgeben:
Hallo, ob physikalisch sinnvoll oder nicht, aber es funktioniert und die Simulationsergebnisse decken sich sehr gut mit Messergebnissen. Daher können die Einstellungen nicht so flasch sein! Mit anderen Einstellungen lief mein Case nicht. ------------------ Viele Grüße Michael Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |