---

Hallo,

ich habe folgendes Problem:

Ich hab ein Strömungsgebiet (Form eines Zylinders). Mitten in diesen Gebiet befindet sich ein Rohr, aus dem Luft strömt (u = 20 m/s). Die Rohrströmung an sich ist nicht von Belangen (und verlangsamt meine Rechnung um den Faktor 10). Daher habe ich nur einen Patch definiert, der für den Einlass steht. Die Rechnung läuft soweit auch stabil (keine Auffälligkeiten in der Log-Datei). Wenn ich mir aber die Zwischenergebnisse in Paraview anschaue, entsteht an der Oberseite des Einlass-Patchs ein Geschwindigkeitmaximum von 80 m/s und mehr (welches zudem noch in eine andere Richtung zeigt als die eigentliche Strömung). Ich rechne mit der OpenFoam-Version 2.2.x. Das Gebiet habe ich mit Snappy (Helyx) vernetzt. Solver ist der buoyantPimpleFoam. Die Randbedingungen sind die gleichen wie in der Variante mit Rohrströmung (wo es keine solchen Probleme gab, außer die kleinen Zeitschritte).

Ich kann natürlich gerne noch weitere Infos geben (Log-Datei, genauen Randbedingungen, usw.). Ich wollte den ersten Post nur erstmal klein und übersichtlich halten.

Daher meine Frage: Muss man irgendwas bestimmtes beachten, wenn man einen Einlass mitten im Strömungsgebiet beginnen lässt (also ich denke da hauptsächlich an Randbedingungen)?

Viele Grüße,

DanDan7

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

---

Hallo Dan,

a) Dein Rohr hat definitiv einen Einfluss auf deine Strömung. Wie groß kann ich nich beurteilen, aber da ich aus der Verbrennung öfter Freistrahlflammen simuliert und validiert hab, kann ich dir nur sagen, dass das außer acht lassen großen Einfluss auf die Strömung nimmt. Das musst du aber selber entscheiden in wie weit das bei dir gegeben ist.

b) Hast du mal ein Bild von deinem Netz
c) Ggf. ein Plot mit sauberen Vektoren um zu verdeutlichen was dein Problem ist (bzw. die Profile ersichtlich werden)
d) Bitte poste mal dein Inlet Patch + Umgebungsnetz

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

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

---

Hallo,

danke für die Antwort. Ich hab das Problem jetzt erstmal so gelöst, indem ich hinter (bzw. um) den Inlet einen Körper gesetzt habe. Hiermit scheint das oben genannte Problem nicht aufzutreten. Daher würde ich erstmal so weiterrechnen.

Nun ist aber ein anderes Problem aufgetreten. Vielleicht hatte ja jemand schon mal einen ähnlichen Fall. Ich hab bisher immer mit rel. niedrigen Einlassgeschwindigkeiten gerechnet ( u bis ca. 20 m/s). Nun soll diese erhöht werden auf bis zu 80 m/s. Bis zu 40 m/s läuft der Solver (buoyantPimpleFoam) soweit normal, stabil und mit noch humanen Zeitschritten (ca. 10^-5). Wenn ich die Geschwindigkeit jedoch weiter hochsetze, steigt der Löser nach wenigen Zeitschritten aus. Ich habe schon versucht das Netz im Einlassbereich zu verfeinern, aber auch das bringt anscheinend nicht viel.

Meist kommt dann die Meldung:

Code:

---

--> FOAM FATAL ERROR:
[16] Maximum number of iterations exceeded
[16]     From function thermo<Thermo, Type>::T(scalar f, scalar T0, scalar (thermo<Thermo, Type>::*F)(const scalar) const, scalar (thermo<Thermo, Type>::*dFdT)(const scalar) const, scalar (thermo<Thermo, Type>::*limit)(const scalar) const) const
[16]     in file /app2/OpenFOAM/OpenFOAM-2.2.x/src/thermophysicalModels/specie/lnInclude/thermoI.H at line 76.

---

Zudem sind die Zeitschritte (wohl aufgrund der Verfeinerung) sehr klein (10^-6 und niedriger). Ich rechne mit dem k-Omega-SST-Turbulenzmodell.

Vielleicht kennt ja jemand das Problem.

Viele Grüße,

Dan

Bitte CODE-Tags verwenden

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

---

Hi,

a) 80m/s und dann freie Konvektion; versteh ich nicht
b) Hab vorher nen Kuchen gemacht aber der schmeckt nicht, warum?

Frage b) zielt drauf ab, dass es eine Vielzahl von Fehlermöglichkeiten gibt, die du machen kannst aber ohne Input tappt man im Dunkeln.
Es könnte sein:

• Netz
  
• Boundarys
  
• Solver-Settings
  

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

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

---

Hi,

Mir gehts hauptsächlich um natürliche Konvektion aufgrund von Temperaturunterschieden. Die 80 m/s verdrängen dann einfach die Konvektionsströmung. (Sozusagen ein Anblasen an eine heiße Oberfläche)

Ja da hast du recht, dass es diese Gründe haben kann. Da ich den Fall schon recht häufig gerechnet habe, habe ich mal angenommen, dass es nicht an den Solver-Settings und nicht an den Randbedingnungen liegt. Wobei ich das mit den Randbedingungen noch nicht 100% ausschließen möchte. Sehr viel anders als bisher kann ich die Randbedingungen aber auch nicht wählen (außer für k und Omega vielleicht). Der buoyantPimpleFoam scheint nur generell sehr empfindlich zu sein (sowohl was das Netz angeht als auch die RBD). Daher wollte ich nur fragen, ob das auch von anderen schon beobachtet wurde.

Ich kann die Solver-Settings und die RBD aber natürlich gerne mal hochladen.

Viele Grüße und danke,

Dan

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

---

Grüße Dan,

hab das mit der Boussinesq verwechselt, da ich noch n anderes Thema bearbeite, bei dem diese Approximation vorliegt. Natürlich ist der buoyant Solver mit Auftriebsterm, sodass freie Konvektion auf Grund Dichteunterschiede simuliert werden können. Trotzdem frag ich mich ob du das überhaupt brauchst (also den Term für den Auftrieb).

• 80m/s -> so schnell fährt nich mal mein Auto; also weiß ich nicht was da freie Konvektion sein soll?
  
• FOAM ist immer kritisch und Empfindlich gegenüber Falscheingaben von Boundarys, Mesh, Parameter... ist auch der Grund weshalb man mit FOAM wesentlich mehr Wissen im Bereich der Numerik mitbringen sollte als bspw. in Fluent. Nichts gegen das Programm aber da kann ich einstellen was ich will und es läuft immer 
  

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

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

---

Heyho,

also es geht darum, dass ein sehr heißes geschmolzenes Metall irgendwo ausfließt (T > 1500 °C), anschließend einen relativ langen Fallweg hat und sich aufgrund der Temperaturunterschiede zw. Umgebung und der Schmelze eine Auftriebsströmung ergibt. In bzw. an das heiße Metall sollen Partikel geschossen werden. Damit die Partikel aber den Strahl erreichen, braucht der Luftstrahl (der die Partikel trägt) eine bestimmte Geschwindigkeit. Die 80 m/s kommen mir persönlich auch (viel!) zu hoch vor (bisher waren es immer 10-25 m/s). Die 80er Variante kam nun neu hinzu. Ich hab das ehrlich gesagt selbst schon hinterfragt (weil mir das viel zu hoch vorkommt), aber wurde mir so aufgetragen und deshalb muss ich das nun rechnen bzw. versuchen.

Haha, ja das die Diskussion über FOAM und die anderen Programme kenne ich  Wenn man da so hört mit welchen Courant-Zahlen bei CFX und Co. gerechnet werden kann. Da wird man als OpenFOAM-Nutzer schon bisschen neidisch ^^ Aber hast natürlich Recht, dass man bei FOAM mehr Hintergrundwissen braucht was Numerik usw. angeht.

Ich werde mal noch ein wenig an den RBD für Omega und k spielen und vielleicht noch ein paar Netze probieren. Bisher bricht die 80er-Variante leider immernoch ab.

Viele Grüße,

Dan 

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

---

Grüße dich Dan,

Also freie Konvektion hast du ja nur wenn aufgrund der Dichte oder Konzentrationsunterschiede die Strömung ausgebildet wird. Meiner Meinung ist alles was du berechnest erzwungene Konvektion. Könntest somit auch rhoPimple Verwenden. Mit foam kannst auch mit Co 8 etc rechnen. Viele haben halt definitiv zu wenig Kenntnisse ( mich eingeschlossen ).

PS: Ob es sich um freie Konvektion handelt ist eben auch abhängig, wie stark diese zur Erzwungenen ist.

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

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

---

Cases_Dan_2015.tar.gz

Heyho,

also ich habe jetzt mal noch ein wenig an den Randbedingungen, den Schemes und mit dem Netz gespielt. Leider alles ohne Erfolg. Ich hab auch mal den "rhoPimpleFoam" ausprobiert. Auch bei diesem Löser bricht die Simulation ab (bei hohen Einlassgeschwindigkeiten). Könnte ich den Case (bzw die zwei Cases (bouyantPimpleFoam und rhoPimple)) mal hochladen? Vielleicht hab ich irgendwo den Wald vor lauter Bäumen nicht gesehen. Ich vermute irgendwie, dass es am Netz liegt (wobei selbst "ultrafeine Netze" abbrechen. Mit dem "rhoPimpleFoam" hab ich leider noch nicht so viel Erfahrung, somit könnte es sein, dass ich da vielleicht etwas grobes falsch eingestellt hab.

Ich hänge die beiden Cases mal ran. Falls du mal eine freie Minute hast und drüber gucken kannst. Die Uplaod-Größe scheint begrenzt zu sein, daher muss ich die Netze mal rausnehmen. Falls ich das irgendwie auf einem anderen Weg schicken soll/kann, dann würde das natürlich noch machen. Da das Netz ziemlich groß ist, habe ich mal nur die STL-Datei rangehängt. Falls damit ein eigenes Netz gebaut werden soll, muss man beachten, dass das noch skaliert werden muss mit "transformPoints -scale '(0.001 0.001 0.001)'

Die Simulationen brechen ab sobald der Betrag der Einlassgeschwindigkeit hohe Werte annimmt (60 - 80 m/s).
Die Werte müssten in dem Case noch geändert (kann herumgespielt) werden:

Ux = 56
Uy = -56

für 80 m/s.

Bin langsam am Ende meines Latein. Probiere schon ewig (Monate) dieses Problem zu lösen und bisher konnte mir keiner der Kollegen weiterhelfen.

Viele Grüße,

Dan

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

---

Hey Dan,

a) Netz hast du auch in ICEM erstellt?
b) Mit der STL is mir nich klar was du simulierst bzw. was die Ränder darstellen sollen
c) Dein Netz kannst du iwo uploaden und den Link geben, oder ich kann dir meine FTP Daten geben, dann kannst dus auf meinen Server laden.

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

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

---

Hey Tobias,

Danke für die schnelle Antwort!!!

zu

a) Ich habe die Geometrie in ICEM gebaut und als STL herausgeschrieben. Anschließend mit Helyx-OS vernetzt.

b) Bis auf die PATCHS "UMGEBUNG" und "EINLASS" sind alles feste Wände (mit festen Temperaturen). "UMGEBUNG" ist die Grenze zur Umgebung (klingt irgendwie doof. Ich hoffe du weißt was ich meine). "ABSTICH_STRAHL" ist auch ne Wand, die heiße Metallschmelze darstellt (vereinfacht). Vereinfacht ausgedrückt "fällt" der Abstichstrahl nach unten in einen Auffangbehälter. Und während des Fallvorgangs wird Luft an den "ABSTICH_STRAHL" geblasen.

c) Ich hab die Datei hier hochgeladen: http://workupload.com/file/xK2HHYCs

Viele Grüße,

Dan

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

---

Gibts da auch ne sHMDict Datei, wenn nich auch wurst - würd mich nur interessieren.

a) Hast du mir ein Bild vom Prozess. Das da das Rohr iwo mittendrin aufhört und nen Einlass hat ist mir komisch (vllt von dir einfach ne Vereinfachung. Auch das der Elektroofenboden oben ist und etc. einfach nur n Bild vom Prozess und dann weiß ich um was es geht.

b) maxIter 1000000 ?? Beim Druck? Da hast aber dann ordenltich was falsch. Mehr als 1000 Iterationen ist ein Indiz für falsche RB

c) Du hast ganz schön viel durcheinander gemischt in den fvSolutions

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

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

---

Data_Dan_2015.tar.gz

Ich hab noch ein sHMDict dazu gefunden. Ist im Anhang

a) Bild ist auch im Anhang. Das mit dem "ROHR" hab ich vergessen zu erwähnen. Und zwar wollte ich die Rohrströmung weggelassen (Vereinfachung), weil mir sonst die Zeitschritte in den Keller rutschen (Layers sind da vermutlich die Ursache). Da ein einfacher Patch als EINLASS mitten im Strömungsgebiet zu fehlerhaften Simulationen geführt hat, habe ich einfach einen SPERRKÖRPER an den EINLASS gesetzt und den ROHR genannt. Aufgrund der dadurch eingefügten Wand war die Simulation wieder in Ordnung. Im Bild fehlt nun leider der EINLASS (bzw. der Sperrkörper/ROHR (wäre einfach links neben dem Strahl)). Dass der BODEN_E_OFEN oben ist, hat den Grund, dass die Schmelze aus dem E_OFEN herausfließt und in einen Auffangbehälter hinein (nach unten).

b) Das mit dem MaxIter 10000000 war nur ein Versuch von mir, weil als Fehlermeldung immer kommt: "Maximum number of iterations exceeded". Das habe ich nur vergessen wieder zurückzuändern. Da hast du natürlich vollkommen recht.

c) okay   

Viele Grüße,

Dan

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

---

Wenn Punkt b) bei dir vorkommt, dann liegts zu 80% an den Randbedingungen.
Hast du mir eine korrekte STL mit Rohr auch?

Wenn ich das richtig versteh, dann bedüst du den Schmelzenstrang (der wohl immer noch flüssig sein wird oder?) und kühlst damit die Schmelze.

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

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

---

Ergänzung:

wenn du schon 1500°C hast, dann solltest du die Dichte der Luft auch unter 0,5 fallen lassen. Bei 1000°C hat Luft eine Dichte von 0,2735 kg/m^3 (VDI Wärmeatlas).
Das Netz ist auch nicht wirklich gut. Die Transitionen von verschiedenen Zelldichten ist schon sehr schlecht. Da ändert sich der Gradient extrem innerhalb von zwei Zellen.

Was ist das für eine Schmelze? Liquidus-Temperatur? Wenn die mit 60m/s angestrahlt wird ist das keine natürliche Konvektion mehr. Allerdings alles was drum herum ist wird von den hohen Temperaturen schon stark beeinflusst werden.

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

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

---

_5_grad_dicke_wand.stl

Die Änderung zu maxIter = 10000000 (riesig) hatte ich nur versuchsweise probiert, weil die Rechnung immer ausgstiegen ist, wenn ich die U_Einlass auf 60 bzw 80 m/s gesetzt habe. Bis zu U_Einlass = 40 m/s läuft die Simulation stabil und sauber durch (mit den angegebenen RBD und ohne maxIter = 100000000). Im Normal-Case (der mit U_Einlass = 40 m/s bisher durchläuft) steht dort gar kein maxIter.

Also es wird einfach Luft angeblasen (es kühlt sozusagen, wobei das nicht der Zweck ist). Später werden dann noch Partikel auf den Einlass gesetzt (One-Way-Coupled Partikelsimulation), die zur Oberfläche des Strahls getragen werden.

Im Realfall wäre der Strahl flüssig. Aber dann müsste ich eine VOF-Simulation machen. Hier ists einfach als Wand angenommen.

Ich habe noch eine STL mit (durchströmten) Rohr von einem alten Modell (wenn dir das hilft).

Viele Grüße,

Dan :-)

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

---

open.png

Servus Dan,

du hast kein Geometriemodell oder, da:

Code:

---

Surface is not closed since not all edges connected to two faces:
    connected to one face : 2848
    connected to >2 faces : 0
Conflicting face labels:2848
Dumping conflicting face labels to "problemFaces"
Paste this into the input for surfaceSubset

---

Mit solchen STL Files arbeite ich ganz ungern.
Du hast sicher bzw. kannst sicher eine STEP Datei erzeugen oder?
Das wäre mir am liebsten, da ich gerade sehr faul bin  

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

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

---

Heyho,

in ICEM geht das irgendwie nicht. Da kann man die Geometrie nur in folgendes exportieren: IGES (wobei da ne Fehlermeldung kommt ), Parasolid, DDN, STL, Rhino 3DM

Ich kann da höchstens morgen mal die Kollegen fragen. Nur sind die heute irgendwie schon alle weg 

Ich könnte dir noch den ICEM-Projektordner geben.

Viele Grüße,

Dan

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

---

IGES kann ich auch lesen aber gut. Passt schon. Dann erstell ich deine Geometrie erneut (Muss eh warten bis eine HDD mit nullen beschrieben ist).

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

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

---

Mesh.png Velocity.png

Grüße dich Dan,

also bei mir läuft alles einwandfrei. Hab deine Geometrie neu nachgebaut (aber nicht exakt) und ein neues (auf Grund meiner Erfahrungen) Netz erstellt (und selbst hier sinds grad mal 350.000 Zellen). Zudem hab ich natürlich den Pimple Algorithmus richtig verwendet (in wie weit man Unterrelaxation benötigt kann ich jetzt grad nich sagen, da mir die Zeit dazu fehlt). Ich lasse den Case noch bis morgen rechnen aber hab in den letzten 3 Std 0.0012 s gerechnet. Das Ergebnis ist im Anhang zu sehen. Wie du siehst, habe ich derzeit eine maximale Geschwindigkeit von mehr als 90 m/s.

Was mir sonst noch aufgefallen ist:

• Wie gesagt, schlechtes Netz
  
• Deine RB waren nicht alle richtig
  
• fvSolution sah interessant aus
  

PS: Wenn es dir nix ausmacht, würde ich diesen Fall gerne bei meinen Tutorials dazunehmen...

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

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

---

Heyho Tobias,

vielen vielen Dank, dass du dich damit etwas beschäftigt hast. In Sachen "Netz bauen" habe ich wirklich noch nicht so viel Snappy-Erfahrung. Da muss ich noch einiges aufholen. Ich hoffe es rechnet auch weiter (steigt oftmals ohne wirkliche Anzeichen einfach aus). Könntest du mir deinen Case zur Verfügung stellen, damit ich mal sehe was ich so falsch gemacht habe bzw. mache?

Viele Grüße,

Dan

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

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

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

---

Velocity2.png VolumeMagU.png

Hallo Dan,

ich habe den Case bis jetzt durchrechnen lassen und es gibt keine Probleme. Simulationszeit sind 0.0161s (was für mich okay ist).

• Das Netz ist natürlich auch noch nicht optimal
  
• Das Rohr wie ich es gemacht habe ist natürlich nicht Pflicht
  
• Allerdings hat das Rohr schon einen Einfluss auf die Strömung (Randschichten etc. ; wenn du dein Patch direkt am Austritt definierst, kanns sein das falsche Ergebnisse rauskommen. Ist bei mir vor allem bei Freistrahlflammen gewesen)
  
• Wie du siehst hab ich über 160m/s (liegt an dem Rohr und der Ablösung der Strömung im Rohr)
  
• Nachdem ich dein Case nun kenne; buoyant sollte verwendet werden  
  
• Die Randbedingungen müssten ggf. auch noch überprüft werden (da Residuen nich so schön sind)
  

• dT war bei 1.47e-6
  
• Pimple converged in 6 iteration
  
• Ab und zu bounding von k und omega
  

Ich frage nochmals:
Da du bereits das Beispiel hier hochgeladen hast, würde ich es gerne als Tutorial auf meine Homepage setzten. Spricht hier was dagegen?

Bezüglich PIMPLE Algorithmus:

• Schau auf mein Profil in CFD-Online.com, da hab ich mal was ausführliches bezüglich PIMPLE gemacht
  
• Auf Anfragen hab ich das auch ins openfoamwiki übernommen, findest also auch dort
  

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

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

---

Heyho Tobias,

sehr cool, dass der Case scheinbar funktioniert. Ich denke auch, dass buoyantPimpleFoam der richtige sein müsste.

Du kannst den Case gerne hochladen (ist ja sowieso nicht der Original-Case sondern dein eigener, von daher sollte das kein Problem sein).

Die PIMPLE-Sachen schau ich mir mal an :-)

Kannst du mir den Case mal schicken, oder soll ich mir dann von deiner Seite runterladen?

Viele Grüße,

Dan

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

---

Hi Dan,

es folgt am Sonntag noch ein Eintrag auf meiner Seite aber bis dato (Link ändert sich natürlich nicht):

MeltingPotAndAirCooling.tar.gz

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

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

---

Heyho Tobias,

danke für den Case. Ich hab jetzt mal schnell einen Blick drüber geworfen und da sind mir ein paar Fragen gekommen:

1. Du sagtest der "buoyant" sei die richtige Wahl, der Case hier scheint aber eher rhoPimple zu sein. (kein "p_rgh" sowohl in den fvSolution als auch in den RBD)

2. Kein polymesh-file

3. Sowohl die Anzahl der Patches als auch deren Bezeichnung ändert sich (mal 3 patches, mal 4, mal 7) im "Null-Ordner" (RBD)

Viele Grüße,

Dan

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

---

Hallo,

ich habe mit dem rhoPimpleFoam den Case gestern aufgesetzt, deswegen habe ich nur hingeschrieben das der buoyant eigentlich verwendet werden sollte, da sonst keine natürliche Konvektion berechnet wird und das ja dann dein Strömungsbild extrem verändert.

• Kein polyMesh-Ordner auf Grund der Tatsache das es ein Tutorial ist und im run Skript alle Schritte drin sind
  
• In den Boundarys verwende ich einemal die explizite Methode, heißt ich spreche die RB direkt an, und beim anderen verwende ich die implizite Methode bei der ich die RB mit den inGroups anspreche. Damit spart man sich Arbeit (bin ja ein vim-Mensch). Falls dir das nichts sagt: Ich verwende den Editior vim + mein eigenes FOAM-Plugin (auf Bitbucket verfügbar). Mag keine GUI's, da diese oftmals mühseelig sind. Außerdem bin ich in der Konsole wesentlich schneller als mit ner GUI. Bin der Meinung das man sowieso das Terminal verwenden sollte, da man dann direkt den Bezug zum Programm/zurSprache bekommt. Aber das ist jedem selber überlassen. Meine Erfahrungen sind folgende, jeder der im Terminal vertraut ist würde diese nie mit ner GUI wechseln, da schneller, vertrauter, übersichtlicher etc. (Aber eben meine Erfahrung und meine Meinung). Ein GUI Programmierer wird das natürlich abstreiten. Eine GUI hat natürlich Vorteile (man sieht direkt wie das Hintergrundnetz ist etc.) wobei das mit 2 Screens auch möglich ist 
  

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

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