---

Pipe.png

Hallo zusammen,

ich beschäftige mich mit Rohrströhmungen.
Um bei hohen Re Zahlen keine allzu langen Anlaufstrecke zu haben, möchte ich aus einem langen Rohr mit Hilfe des sampleDicts eine ebene extrahieren und dann diese als "inlet bc" für ein kurzeres Rohr nehmen (siehe Bild, blau ist langens Rohr, grau ist kurzes) sodass am Inlet bereits die voll ausgebildete Strömung vorliegt.

Mein Problem liegt darin, dass die Anzahl der Points-Cells der Ebene nicht mit der des Inlets überein stimmt. Das heißt ich kann nicht einfach eine TIME aus dem langen Rohr als 0 im kurzen Rohr verwenden...

Sample funktioniert, bekomme die Daten...
-Habe es mit mapFields versucht aber da mappe ich ja das gesamte Feld.
-groovyBC schneit mit OF 2.3.x nicht zu gehen...

Hatte ihr eventuell schonmal das gleiche Problem und daher eine Lösung parat?

Vielen Dank im Voraus

Grüße

Sibi

[Diese Nachricht wurde von sisetrun am 15. Okt. 2015 editiert.]

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

---

Zitat:

---

Original erstellt von sisetrun:

-groovyBC schneit mit OF 2.3.x nicht zu gehen...
[Diese Nachricht wurde von sisetrun am 15. Okt. 2015 editiert.]

---

Hi Sibi,

wer behauptet den sowas (:
Bernhard wäre darüber sicher nicht erfreut und liese sowas auch nicht auf sich sitzen. Swak4Foam läuft anstandslos mit 2.3.x. Ich weiß zwar nicht wie deine Daten aussehen (vom Sample) aber wie wäre es mit der RB die dir die Daten da rausließt?

Ansonsten fällt mir noch auf die Schnelle ein, dein kurzes Rohr nach hinten verschieben (also im Raum) sodass das Inlet auf dein Outlet trifft, bzw. dein Inlet genau auf dein SLICE. Dann map-Fields mit patches und dann kannst die internalFields auf 0 setzen wenn das gewollt ist und hast dann deine Faces am Inlet mit den Werten die du am Slice hast. Fertig.

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

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

---

Schönen guten Morgen zusammen,

ich bin ebenfalls an einer deratigen Lösung interessiert, da ich eine ähnlich Problemstellung habe.

@ Tobias: Du sagst, es gibt eine Randbedingung die mir die Daten, beispielweise am "outlet", herausließt? Ist das mit Bordmitteln von OF zu realisieren oder benötigt man dazu das Swak4Foam. Dann wäre die anschließende Frage, wie man die Daten dann als Randbedingung am "inlet" vorgeben kann. Ich habe gerade keinen geeigneten "Typ" gefunden. Ich bin aber der Meinung, dass ich das schon mal irgendwo gelesen habe - nur finde ich es nicht mehr 

Kannst du auch die zweite Möglichkeit mit dem Verschieben genauer erläutern? Wenn ich mein Rohr "physikalisch" verschiebe, dann nimmt doch OF die Daten mit, oder bleiben die im Raum stehen und werden dem neuen Face zugeordnet?

Neben dieser Methode wäre für mich auch interessant, ob es ein großer Aufwand wäre, in das OF-Tool "mappedPatch" folgendes zu integrieren:

- Relaxationsfaktor zwischen dem Mappen
- Map Intervall

Dies ist beispielweise bei den kommerziellen Programmen (Fluent und CCM+) implementiert. Nur leider habe ich in OF noch nichts programmiert.

------------------
Viele Grüße
Michael

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

---

Danke Tobias,

ich wollte wirklich niemandem zu nahe treten  
ich hatte mich die Tage damit beschäftigt und meine gelesen zu haben dass mit 2.3 das nicht funzt. Daher hatte ich es auch wieder verworfen...werden mich aber gleich nochmal da und an deine anderen Vorschläge ran machen.
Vielen Dank soweit...

[Diese Nachricht wurde von sisetrun am 16. Okt. 2015 editiert.]

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

---

Morgen zusammen,

also das mit dem Rohr ist mir nach euren Ausführungen noch nicht so ganz klar. Erste Frage an euch, es sind schon zwei Simulationen, oder?
Es kann immer / und wird immer so sein das groovy für diverse Versionen von FOAM nicht standardmäßig funktioniert, allerdings ist Bernhard schon auf zack  Nach ein paar Tagen ist das dann auch immer behoben.

Die Randbedingung heißt glaub timeVariing etc. Das list dir Daten aus einer Datei ein. Über Sample hast du ja die Daten glaub ich dann als File vorliegen (schon lang her das ich damit gearbeitet habe). Dieses könnte man dann wieder verwenden.

Mit Groovy geht das natürlich auch 

• mappen auf Sektionen kann man sicherlich machen, hardcoden oder ggf. mit FaceZones arbeiten
  
• Relaxationsfaktoren sind natürlich auch möglich
  

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

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

---

Ich versuche s nochmal verständlicher...

Mein "großes Ziel" ist es verschiedene Gitterstrukturen in einem Rohr zu simulieren (Promotion, hier mal ein Beispiel http://www.zmp.uni-erlangen.de/forschung/anwenderzentrum-vertec
Daher möchte ich erst mal das leere Rohe für verschiede Re simulieren. Ich erhoffe mir dadurch für die verschiednen GEschwindigkeiten die ausgebildetn Profile zu haben um diese dann als INLET bei der Gitterumströmung vorgeben zu können.

Habe jetzt mit Re 10,50,100 angefangen und da merkt man gleich dass das Rohr immer länger werden muss damit ich auf die analztisch berechnete maximale Geschwindigkeit im rohr komme...

jetzt möchte ich für meinen ersten kleinen Vortrag zeigen, dass es möglich ist die Ausdehnung des Rohr und damit die Rechenzeit klein zu halten wenn ich am INLET nicht einfach eine Geschwindigkeit mit inlet, fixedValue, (x y z) vorgebe sonder ein bereits empirisch oder simuliativ erzeugtes Profil der Strömung vorgebe...

Das ist gerade mein Stand an dem ich am rumprobieren bin das möglichst gut hin zu bekommen.

Langes Rohr: 0,3m erricht U max
kurzes Rohr: 0,2m erreicht es nicht

Ziel: kurzes Rohr möglicht ganz mit voll ausgebildetem Profil ohne großen Anlauf da ich ja später dann noch im Rohr meine Gitter umströmen möchte und sonst einen enorm lamgen Anlauf brauche...

Ich hoffe es ist jetzt deutlicher geworden

[Diese Nachricht wurde von sisetrun am 16. Okt. 2015 editiert.]

[Diese Nachricht wurde von sisetrun am 16. Okt. 2015 editiert.]

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

---

Hallo zusammen,

@ sisetrun: schau dir mal das Tutorial pitzyDailyMapped an. Hier wird kontinuierlich der outlet auf den inlet gemappt. Es gibt aber auch noch andere Randbedingungen in OF dafür.

@ Tobias: Ich habe eine ähnliche Aufgabenstellung wie sisetrun. Hierzu verwende ich aber die Randbedingung "mappedPatch". Nur sieht mein Strömungsbild sehr komisch aus und ich möchte nun prüfen, ob das vom mappen kommt oder nicht.
Wenn es eine Möglichkeit gäbe, dass map-Intervall von "mappedPatch" einzustellen, wäre das eigentlich eine äquivalente Lösung. Da es das aber nicht gibt, muss ich den outlet händisch auf den inlet mappen.

Die Funktion heißt: timeVaryingMappedFixedValue
Auch hierfür gibt es ein Tutorial.

Vielen Dank Tobias 

------------------
Viele Grüße
Michael

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

---

Hallo Micha,

was heißt den "komisch"? Das mit dem Map-Intervall meinst du sicherlich so, dass nur ein gewisses voranschreiten der Werte möglich ist phi_neu = phi_alt*0.x. Mit Groovy kann man sowas ganz schnell realisieren.

Zu sisetrun: Die Erklärung ist genau so wie ich es mir gedacht habe. Entweder verwendest du die bereits erwähnte MappedPatch Sache, damit kannst du rechnen, allerdings sobald einbauten reinkommen wird das nichts mehr oder du simulierst wirklich nur das blanke Rohr; nimmst das END-Ergebnis vom Outlet und mappst das auf das Inlet. Sollte Inlet und Outlet identisch sein (heißt also die Faces sind gleich), sollte es auch möglich sein die vector liste vom Outlet direkt ins Inlet zu kopieren (müsste man testen), ansonsten eben mappen.

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

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

---

Alles klar, ich versuche mal mein Glück!
Besten Dank soweit

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

---

Hallo,

mit Map-Intervall meinte ich, dass nur alle x Iterationen der Wert gemappt wird. Das was du beschreibst, ist wie schon erwähnt, das Relaxieren zwischen dem Mappen. Bei Fluent und CCM+ kann man beides einstellen.

Mit groovy gab es hier schon einen Test mit der 2-Wege Kopplung - Hierzu gibt es Beispieldateien. Das Ergebnis war, dass groovy den Mittelwert des Outlet gebildet hat und diesen auf den Inlet übertragen hat. Somit war dann leider auch das gwünschte Strömungsprofil weg 

Das mit dem "komisch" ist nocht so einfach zu erklären. Die Druckverteilung sieht bei mir eben unrealistisch aus bzw. ich kann es mir so nicht erklären (was nicht heißen soll, dass es grundsätzlich falsch wäre). Deshalb möchte ich überprüfen, ob das Mappen eventuell einen Einfluss ausübt. Eventuell werden so kleine Störungen immer wieder dem Strömungsgebiet zugeführt etc.

------------------
Viele Grüße
Michael

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

---

Zitat:

---

Original erstellt von Micha6982:
Hallo,

mit Map-Intervall meinte ich, dass nur alle x Iterationen der Wert gemappt wird. Das was du beschreibst, ist wie schon erwähnt, das Relaxieren zwischen dem Mappen. Bei Fluent und CCM+ kann man beides einstellen.

---

Jetzt verstehe ich was du meinst. Also quasi eine Aktualisierung der RB alle x Iterationen.
Wäre definitiv möglich, entweder mit codedFixedValue oder aber auch mit groovy. Man müsste halt die Aktualisierung nur alle x Schritte erlauben und zusätzlich müsste man die Inlet values in ein Array speichern. Mein Favorit wäre dann wohl eher die codedFixedValue, da ich keine Zeit hätte das mal zu testen und rumzuspielen. Möglich aber sicherlich auch.

Zitat:

---

Mit groovy gab es hier schon einen Test mit der 2-Wege Kopplung - Hierzu gibt es Beispieldateien. Das Ergebnis war, dass groovy den Mittelwert des Outlet gebildet hat und diesen auf den Inlet übertragen hat. Somit war dann leider auch das gwünschte Strömungsprofil weg    

---

Die Mittelung muss man ja aber nicht machen. Die Beispiele  die du ansprichst sind die auf der Wiki-Seite.

Zitat:

---

Das mit dem "komisch" ist nocht so einfach zu erklären. Die Druckverteilung sieht bei mir eben unrealistisch aus bzw. ich kann es mir so nicht erklären (was nicht heißen soll, dass es grundsätzlich falsch wäre). Deshalb möchte ich überprüfen, ob das Mappen eventuell einen Einfluss ausübt. Eventuell werden so kleine Störungen immer wieder dem Strömungsgebiet zugeführt etc.
[/b]

---

Nur das Geschwindigkeitsfeld ohne Druckaktualisierung zu machen (bezogen auf das Inlet) kann natürlich ein komisches Druckbild erzeugen, da p und U ja gekoppelt sind. Wenn du jetzt nach 10 Iterationen das U-Profil an den Inlet mapst, dann stimmt ja das Druckprofil wieder nicht, somit die Konti nich und das wird dann ja erstmal über deine Druck-Geschwindigkeits-Kopplung (wahrscheinlich PIMPLE oder SIMPLE) dann wieder divergenzfrei "gemacht". Es kann da durchaus vorkommen das die Profile unphysikalisch sind.

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

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