---

Regions.JPG

Hallo,

Ich möchte gern mein Strömungsgebiet in zwei Gebiete aufteilen. (Bild siehe Anhang)
Jede Region soll eine eigene fvSchemes und fvSolution bekommen.

Mein Gedanke war (da ich sowieso mit chtMulti simuliere) eine Separate Region mittels topoSetDict zu erstellen.

zwischen den beiden Regions soll gemappt werden.

Also im 0-Ordner jeweils

Code:

---

domain0_to_kern
{
type mappedFixedInternalValue;
fieldName      U;
setAverage      no;
average        (0 0 0);
value uniform (0 0 0);
}

---

den Druck am habe ich auf zeroGradient zwischen den Regions.

Wenn ich das so simuliere funktioniert es nicht, die Strömung ,,prallt" an der inneren Region ab, als wäre es eine Wand.

Habe schon andere diverse Kombinationen ausprobiert, ohne erfolg.

Hat jemand eine Iddee was hier die richten Randbedingungen sind?

Bzw. Hat jemand eine Iddee wie ein einfach geht, für einen Bereich eine alternative fvSchemes und fvSolution Datei zu „verwenden"?

Danke schonmal im voraus,
gruß Marcel

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

---

Hallo Marcel,

die Frage die sich mir hier stellt ist, wieso verschiedene Schemen und Löser? Um aber deine Frage zu beantworten, folgendes:

• Du wirst hier entweder mit Groovy was basteln müssen oder
  
• ggf. kann dir die AMI BC weiterhelfen.
  

Letzteres bin ich mir unsicher, da das - soweit ich weiß - nur auf CellZones funktioniert.
Andere Möglichkeit wäre es natürlich mit CellZones zu arbeiten und im Solver dann die Zonen
unterschiedlich lösen; zumindest die fvSolution kannst du dann ändern.

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

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

---

Hallo Tobias,

Danke für die Antwort

Ich möchte zwei unterschiedliche Interpolationsschematas in den Regions. Grund dafür ist die Strukturierung der Geometrie (Netz mit Snappy).

Durch die Strukturierung ist das ziemlich instabil (vor allem der Druck, Wärmestrom konvergiert erstaunlicher weise). Wenn ich mit Upwind oder Minmod limiter rechne läuft es, aber die Ergebnisse sind 30% unterhalb von den Messwerten.

Ich vermute liegt daran, das der Drall der in der Strukturierung entsteht nicht weit genug in die Strömungsmitte transportiert wird. Daher die Idee der Kern mit vanLeer limiter oder ähnlichem zu rechnen.

Evtl. ist das auch nur ein weiterer Irrweg.

Erstaunlicher weis hat CCM+ auch erhebliche Probleme mit der Geometrie.

Mit Groovy habe ich bisher noch keine Erfahrung. Damit müsste ich mich mal in einer ruhigen Woche beschäftigen.

gruß Marcel

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

---

Ist dein Case verfügbar?

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

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

---

Ich habe dir eine PN geschickt bezüglich des Case.

Noch eine Frage wegen den CellZones, wie kann ich da die Zuordnung machen?
Hast du mir da einen Link? bzw. ein Beispiel?

Habe mal etwas geschaut, aber nichts gefunden.

gruß Marcel

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

---

Für die Zonen eignet sich:

• sHM
  
• setSet
  
• setsToZones
  
• etc.
  

Da musst aber dein Quellcode dann ändern und ich weiß nich ob das so klug und sinnvoll ist. Deine PN habe ich zur Kenntnis genommen und bereits zurückgeschrieben.

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

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