---

Hallo werte Forengemeinde,

ich bin momentan dabei die Strömungssituation in einem Gärbehälter einer Biogasanlage zu simulieren. Da die Anlage kein Rührwerk hat trennen sich innerhalb zwei Phasen ab: eine hochviskose Schwimmschicht und eine wässrige, schwerere Phase. Dazu kommt noch der Gasraum darüber.
Nun hab ich ein stark vereinfachtes Modell in Salome konstruiert und wollte dies jetzt so vernetzen, dass es für eine multiphaseInterFoam-Berechnung herhalten kann. Bin mir aber nicht wirklich schlüssig, wie das am geschicktesten funktionieren könnte.

Mein Versuch sah bisher so aus, dass ich die Geometrie aus drei Teilen, also den drei Schichten, erstelle, diese dann "compounde", das Ganze dann vernetze und über die Gruppierung dann inlet/outlet/wall sowie die 3 Regionen zu definieren. Soweit so gut. Das ganze als .unv exportiert und jetzt steht die Konvertierung mittels "ideasUnvToFoam" an. Diese läuft auch mithilfe der vorher definierten Dateien wie der "controlDict" durch.
Dabei gibt es u.A. auch die korrekte Zuordnung der Gruppen aus:

Code:

---

Sorting boundary faces according to group (patch)
0: wall is patch
1: inlet is patch
2: outlet is patch
3: air is cellZone
4: mittlereSchicht is cellZone
5: untereSchicht is cellZone

---

Nun möchte ich den einzelnen Regionen ja die entsprechenden Parameter zuordnen, also in der setFieldsDict die fieldValues definieren.
Dazu müssten doch die oben gezeigten "cellZones" genutzt werden können, oder?
Also zum Beispiel mit der Funktion regiontocell.
Allerdings finde ich darüber keine Dokumentation, wie diese anzuwenden ist. Ist das jemandem von euch bekannt?

Vielen Dank schonmal
Beste Grüße
Ronny

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

---

Hi,

dürfte gehen. Einfach ausprobieren und eingeben. OF gibt dir dann schon die Fehler bzw. fehlenden Parameter.
Die Frage die ich mir gerade stelle ist, wieso verwendest du "Zoneen"? In setFieldsDict würd ich persönlich mit einem BLock/Rohr/Zylinder/STL (letzteres geht glaub auch) deine Werte zuweisen. Zumindest mach ich es mimer so.

------------------
Grüße Tobias Holzmann

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

---

fermenter_schichtung.png

Hallo Tobias,

danke für deine schnelle Antwort. Der Grund, warum ich die Zonen nutzen würde ist, dass ich die Geometrien in Salome einfachst konstruieren kann, egal welche Geometrie sie haben. Dadurch, dass sie ja auch als Zonen exportiert werden, wäre das doch die einfachste Möglichkeit mehrere Phasen zu definieren, oder? Ich weiß es leider noch nicht genau, da ich noch nie ein komplexeres Modell für OF erstellt habe.  

Ich hab jetzt in der entsprechenden Quelldatei regionToCell.C zumindest die prinzipielle Funktionsweise ergründen können. Man gibt einfach einen Punkt an, der in der gewünschten Region/Zone liegt. Somit sind alle Zellen in dieser Region selektiert. Allerdings bin ich mit der Syntax noch am hadern. Ich hab mir das laut dem Sourcefile so gedacht:

Code:

---

regions
(
    regionToCell
    {
        subCellSet (0 0 0.5);
        fieldValues
        (
            volScalarFieldValue alphawater 1
            volScalarFieldValue alphaoil 0
            volScalarFieldValue alphaair 0
        );
    }
    regionToCell
    {
        subCellSet (0 0 3);
        fieldValues
        (
            volScalarFieldValue alphawater 0
            volScalarFieldValue alphaoil 1
            volScalarFieldValue alphaair 0
        );
    }

usw.

---

denn in der regionToCell.C steht:

Code:

---

regionToCell::typeName,
    "\n    Usage: regionToCell subCellSet (x y z)\n\n"
    "    Select all cells in the connected region containing point.\n"
    "    If started inside the subCellSet keeps to it;\n"
    "    if started outside stays outside.\n"

---

aber bei setFields kommt:

Code:

---

--> FOAM FATAL IO ERROR:
keyword set is undefined in dictionary "::regionToCell"

file: ::regionToCell from line 29 to line 35.

    From function dictionary::lookupEntry(const word&, bool, bool) const
    in file db/dictionary/dictionary.C at line 400.

---

als würde da noch ein "set" fehlen, aber ich weiß nicht wo.. hab schon vieles ausprobiert. Wie heißt es denn hier richtig?

Tobias, wie würdest du das denn angehen, wenn du diese Vorgehensweise ablehnst?

Beste Grüße
Ronny

Edit: Okay, ich hab gerade die Funktion zoneToCell gefunden. Damit kann man direkt den Namen der cellZone angeben. Klappt auch ala:

Code:

---

zoneToCell
    {
        name "air";
        fieldValues
        (
            volScalarFieldValue alphawater 0
            volScalarFieldValue alphaoil 0
            volScalarFieldValue alphaair 1
        );
    }

---

[Diese Nachricht wurde von RonZ am 07. Mrz. 2013 editiert.]

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

---

Na also 

Bei deinem anderen fehlt dem Tool noch dein "set"
Gib einfach mal folgendes ein:

Code:

---

regions
(
    regionToCell
    {
        subCellSet (0 0 0.5);
        set ;
        fieldValues
        (
            volScalarFieldValue alphawater 1
            volScalarFieldValue alphaoil 0
            volScalarFieldValue alphaair 0
        );
    }

---

Dann kommt ne weitere Meldung und die gibt dir dann den Hinweis was man jhinter set stehen haben sollte. Vielleicht setCellZones oder sowas?

Hab damit noch nicht so viel gespielt aber in der Source Datei findest du die Antwort bzw. in der Header

------------------
Grüße Tobias Holzmann

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

---

Zitat:

---

Bei deinem anderen fehlt dem Tool noch dein "set"
Gib einfach mal folgendes ein[...]

---

Mit dem einfachen "set;" fragt er anschließend nach einem "insidePoint". Das noch eingefügt ala "insidePoint(x y z), brauch er anschließend noch eine Datei "sets" 
Ich hab's gut sein lassen - "zoneToCell" tuts auch. Und das wesentlich einfacher.

Jetzt allerdings noch ein Problem. Die drei Regionen sind scheinbar nicht von Haus aus miteinander verbunden, obwohl der ganze Fermenter aus einem einzigen Netz besteht..
checkMesh sagt:

Code:

---

Checking topology...
    Boundary definition OK.
***Total number of faces on empty patches is not divisible by the number of cells in the mesh. Hence this mesh is not 1D or 2D.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
  *Number of regions: 3
    The mesh has multiple regions which are not connected by any face.
  <<Writing region information to "0/cellToRegion"

Checking patch topology for multiply connected surfaces ...
    Patch              Faces    Points  Surface topology                 
    wall                5356    2709    ok (non-closed singly connected) 
    inlet              164      102      ok (non-closed singly connected) 
    outlet              78      52      ok (non-closed singly connected) 
    defaultFaces        5842    2923    ok (closed singly connected)     

Checking geometry...
    Overall domain bounding box (-11.5 -11 0) (11 10.9993 6)
    Mesh (non-empty, non-wedge) directions (1 1 0)
    Mesh (non-empty) directions (1 1 0)
***Number of edges not aligned with or perpendicular to non-empty directions: 63389
  <<Writing 12689 points on non-aligned edges to set nonAlignedEdges
    Boundary openness (1.21737e-18 7.04885e-18 2.33694e-16) OK.
    Max cell openness = 2.47175e-16 OK.
    Max aspect ratio = 4.9771 OK.
    Minumum face area = 0.00147533. Maximum face area = 1.83937.  Face area magnitudes OK.
    Min volume = 2.8545e-05. Max volume = 0.765738.  Total volume = 2269.89.  Cell volumes OK.
    Mesh non-orthogonality Max: 52.7848 average: 15.8767
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.647067 OK.
    Coupled point location match (average 0) OK.

Failed 1 mesh checks.

End

---

Er stellt also fest, dass es kein 1D oder 2D Mesh ist. Das ist hoffentlich trotz der drei Sterne legitim, oder? 
Außerdem zählt er die Kanten, die nicht mit oder senkrecht der empty-directions stehen. Was hat das für eine Bewandtnis?

Wie sind jetzt die Regionen miteinander zu koppeln? In Salome ist das scheinbar nicht mgl. Gibt es dafür ein pre-processing-Tool?

Nochmals besten Dank und freundlichst gegrüßt
Ronny

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

---

Servus nochmal,

ich stecke immernoch bei der Problematik mit den 3 Regionen, die sich nicht verbinden lassen fest.. 
Man könnte zwar auch 3 Netz separat erzeugen und dann verbinden, aber das tut der Netzhomogenität auch nicht gerade gut. (unstrukturiertes Netz)

Hier nochmal die Ausgabe von checkMesh

Code:

---

  *Number of regions: 3
    The mesh has multiple regions which are not connected by any face.
  <<Writing region information to "0/cellToRegion"

---

Salome hat leider auch kein mergePatchPairs bei der Netzerzeugung, das muss doch trotzdem irgendwie nachträglich mgl. sein, oder?
Toll, wenn ihr mir helfen könntet.

Grüße
Ronny

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

---

Hi,

ich könnte es mir mal anschauen, wenn du mir dein Case oder die Salome Datei zur Verfügung stellen kannst.
Komm aber voraussichtlich erst nächste Woche dazu.

------------------
Grüße Tobias Holzmann

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

---

Fermenter.tar.gz

Hey,

freilich, anbei also der case und die .hdf für Salome. Ich wollte es gerade mal mit einem work-around mittels der boundary-condition "type cyclic" versuchen, auf die beiden direkt übernanderliegenden inneren Flächen angewendet auf die jeweils andere verweisend. Aber die zwei Flächen haben, trotz dass sie exakt aufeinander liegen, eine unterschiedliche Anzahl an faces. Könnte man den Mesher zwingen identische Scnittflächen zu erzeugen? Dann könnte man den oben genannten cyclic-typ anwenden, der zwangsläufig die gleiche facenumber bei beiden verknüpften Flächen benötigt..

Also nochmal die Frage: Wie bekommt man zwei Regionen miteinander verknüpft?

Beste Grüße
Ronny

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

---

Hallo,

also um nochmals alles festzuhalten:

- der Fermenter besteht aus einer Domain / Region
- die Regionen die du eingefügt hast, dienen lediglich der Initialisierung

Prinzipiell ist deine Vorgehensweise in Ordnung aber aus meiner Sicht sehr sehr umständlich oder sind die unterschiedlichen Regionen mit anderen Definitionen behaftet. Soll heißen "poröses Material etc." ?

------------------
Grüße Tobias Holzmann

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

---

Servus Tobias,

Zitat:

---

- der Fermenter besteht aus einer Domain / Region
- die Regionen die du eingefügt hast, dienen lediglich der Initialisierung

---

Genau so ist es. Prinzipiell besteht der Fermenter aus 3 Regionen, die zusammengenommen physikalisch ein durchgängiges Volumen ergeben (Gärraum). Nur sind darin 3 verschiedene Medien durch ihre Dichteunterschiede geschichtet. Keine solid-Körper vorhanden. Der Input soll irgendwann mal das Gemisch wieder einbringen, das am output abgesaugt wird. Aber das ist erst der nächste Schritt. Grüße!

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

---

Und wieso baust du dir dann drei verschiedene Geometrien, wie es auch in der Wirklichkeit der Fall wäre ? Du erhältst nämlich immer diese "internalFaces".

Ich setz dir mal was auf

------------------
Grüße Tobias Holzmann

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

---

Gibts bei dir irgendwo nen Inlet und Outlet? Das wir aus deiner Konstruktion nicht wirklich klar, da komplette Regionen als "inlet/outlet" definiert wurden.

------------------
Grüße Tobias Holzmann

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

---

Ja, das kleine Rohr ist der outlet, das Rechteck am Ende des eingelassenen Kanals ist der inlet.

Hm, na weil sonst die Phasen nicht genau dem Volumen zugewiesen werden können, oder? Am besten wäre natürlich ein komplett ungestörtes Netz ohne Grenzflächen, aber wie dann die Regionen genau zuweisen?
Wenn im Salome drei Teile mittels compound zusammengestetz werden, baut der beim Vernetzen des kopletten Raumes immernoch Grenzflächen ein .. Man könntes es nur mal andersrum probieren. Erst komplett konstruieren und dann die Regionen hinzufügen und daraus dann die Zellgruppen erzeugen.. aber wahrscheinlich sind die dann daraus erzeugten OpenFOAM-Regionen wieder nicht miteinander verbunden .. hm, ich weiß es leider nicht, sonst würdes ja schon laufen  
Danke für deine Hilfe

[Diese Nachricht wurde von RonZ am 29. Mrz. 2013 editiert.]

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

---

Weiß nicht ob ich heut noch dazu komme aber das ist ein sehr einfach zu lösendes Problem 

------------------
Grüße Tobias Holzmann

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

---

Bildschirmfotovom2013-03-29181627.png

Siehe Anhang + Bilder.

www.holzmann-cfd.de/tutorials/fermenter.tar.gz

Den Rest überlass ich dir  

------------------
Grüße Tobias Holzmann

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

---

Oh man .. ich mein, ich hab keine Ahnung, aber das ist schon krass. So auf die Schnelle.. Ich sollte mich doch mal mit sHM auseinandersetzen. 
Jetzt hab ich nur noch ein paar wenige hundert Fragen zur Schrittkette. Du hast also die Fermenter-Geometrie in Salome hergenommen, hast einen Quader drumgezogen, sodass sie komplett umhaust ist. Hast diesen Quader vernetzt und als blockmesh.unv exportiert, richtig? Hast dann die einzelnen Grenzflächen, also input, output und wall abgeleitet, die einzeln (Netgen-)vernetzt und daraus ein 3D-Netz erstellt, welches diese dann als vorgelagerten 2D-Alg. herangezogen hat, oder? Das mit dem Submesh hab ich ausnahmsweise verstanden. Dieses 3D-Netzt hast du nun als "fermenter.stl" in constant/triSurface exportiert, aber nicht im .hdf-file gespeichert, was du mitgegeben hast, oder hab ich da was übersehen? Was hat es mit dem Ordner "triSurface" auf sich? Ich hab darüber grad nix gefunden?! Jedenfalls weiß sHM, dass es dort zu suchen hat, da du in der entsprechenden sHMDict nur den Namen angeben musstest. Jetzt hast du vermutlich mittels "ideasUnvToFoam" die blockMesh.unv konvertiert. Jetzt in der sHMDict ein paar Parameter zur Netzfeinheit der Oberflächen input, output, wall ergänzt. Hier noch die Frage, hast du diese mit der fermenter.stl exportiert? Ich wüsste sonst nicht, woher snappy die kennen könnte. Ich kann selbst nicht in der Datei nachschauen, weil gedit beim durchsuchen einer 60MB großen Datei die Fräcke macht.. ^^ Und nun hast du snappy in Gang gesetzt (was für Parameter waren da noch mitzuteilen?) Der hat jetzt dem Netz des Quaders diese Fermenter-Form aufgesetzt, irgendwie, oder? Anschließend haste setFields die Stoffferteilung einfach mittels "boxToCell" mitgeteilt. checkMesh mosert nicht, also kann das Resultat nicht falsch sein  Ich bekomms zwar nicht berechnet, weil der in der p_rgh noch einen "adjoint" vermisst (was ist das in dem Zusammenhang und wo und wie wird die definiert?), aber im großen und ganzen bin ich so sehr sehr zufrieden.
Kannst du über die dringensten Fragen nochmal was ausführen?

Ich danke dir erstmal wie verrückt, endlich gehts mal vorran. 

Viele Grüße
Ronny

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

---

Abend Ronny,

zu deinen Fragen:

- in Salome habe ich deine Geometrie herangezogen, da ich mir keine Arbeit machen wollte; soll heißen:

1. Deine *hdf geöffnet und den Fermenter als *.brep gespeichert (wär auch jedes beliebige Format gegangen).
2. Neue Salomedatei erstellt und deine Geometrie eingeladen.
3. Definition von Inlet/Outlet/Wall
4. Meshing von Inlet und Outlet mit einem 2D - Algorithmus um einfach die Oberfläche feiner zu bekommen.

-> prinzipiell könntest du auch im Geometriemodul deine Flächen als STL exportieren, was aber oft zu Löchern in der Geometrie führt.
-> Deswegen wird zuerst ein besseres trianguliertes Netz erstellt (das hat gar nix mit deinem Numerischen Netz zu tun sondern ist nur zur guten Geometrieapproximation nötig)

5. Wall nochmals als Shell ausgegeben und die Linien für den Inlet und Outlet Kontakt als Gruppe extrahiert.

-> Das bringt den Vorteil, dass ich die Haupflächen einfach grob vernetzen kann und an den Verbindungsstellen den gleichen 1D Algorithmus verwenden kann. Entsprechend erhältst du von Inlet auf Wall genau so viele Punkte. Es entstehen keine Löcher in der Geometrie (das ist ein sehr guter Trick)

/-> Prinzipiell könntest du die Wall genauso mit dem 1D Algo behandeln, dafür würde aber deine STL explodieren (100 - 400 MB sind da nicht unüblich)

6. sHM benötigt ein Hintergrundnetz, deswegen eine Boundingbox um den Fermenter gezogen und HEXAEDRISCH vernetzt. Das ist die Basis deines numerischen Netzes.

7. Exportiere Inlet/Outlet/Wall als STL ASCII
8. Ändere die Inhalte von diesen drei Dateien

-> solid inlet
-> solid outlet
-> solid wall

(ist immer die erste Zeile).

9. Füge alle einzel STL 's zu einer zusammen (Stereolith.stl).

-> das ist jetzt deine Geometrie als STL mit verschiedenen Regionen (drei an der Zahl)

10. Diese Stereolith.stl muss in constant/triSurface, weil sHM immer in diesem Ordner nach der Geometrie sucht
11. Update sHMDict
12. Exportiere dein Hintergrundnetz als UNV
13. mittels ideasUnvToFoam das Hintergrundnetz erstellen

14. snappyHexMesh starten
15. setFields starten

16. fertig.

Noch ein Hinweis:

- ein Mehrphasensolver arbeitet wesentlich besser mit Hexaederzellen.

An deinem Zeitornder hab ich etwas gepfuscht aber nichts wirklich sinnvolles oder lauffähiges eingegeben.
Ich weiß ja nicht wie deine RB sind und zudem verwende ich OpenFOAM-2.2 und ich empfehle es jedem, wenn er mit sHM arbeitet 

------------------
Grüße Tobias Holzmann

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

---

Hallo Tobias,

vielen allerbesten Dank für diese Beschreibung und die enthaltenen Tipps! Die Simulation klappt damit tadellos. Ich denke damit werde ich bis auf weiteres vorran kommen   Jetzt wird das Konstrukt weiter ausgebaut.

Eine Frage quält mich noch: Wie kann man über den inlet ein Stoffgemisch einbringen? Dazu konnte ich nichts in Erfahrung bringen. So wie ich das bis jetzt beobachtet habe, kommt im Normalfall immer das Alpha in das System, in dem sich auch das face des inlets befindet. Jetzt soll da aber zu 0,8 Teilen das eine und zu 0,2 Teilen das andere Medium einströmen. Habe ich da was übersehen?

Danke nochmal und viele Grüße,
Ronny

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

---

Hallo,

wenn du ein Stoffgemisch am Inlet haben willst machst du das über das Alpha 

-> alpha1 = 0.8
-> alpha2 = 0.2

------------------
Grüße Tobias Holzmann

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

---

Hallo Ron, Hallo Shor-ty,

ich will ebenfalls einen Fermenter simulieren,
mir fehlt allerdings der Ansatzpunkt in OpenFOAM.

Der link auf den Testfall von Shor-ty funktioniert leider nicht mehr.
Könntest Du den updaten oder mir ev. den Fall per pn oder mail zukommen lassen?

Beste Grüße

Michael

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

---

Hallo und Willkommen im Forum,

der Fermenter sollte noch in meinen Backups sein. Da Ron den Case öffentlich zur Verfügung gestellt hat, glaub ich nicht das es ein Problem ist diesen dir zur Verfügung zu stellen. Werde heute Abend oder um 15:00 Uhr nach dem Case kucken - sofern ich kurz nach Hause komme.

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

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

---

Hallo stoertebeker 

Ich kann dir meine Thesis dazu schicken, wenn du möchtest?! Da hab ich einen großen Teil zur Erzeugung des Modells drin. Ich weiß zwar nicht was du vor hast - aber das weiß man ja am Anfang meist noch gar nicht so richtig 

Dazu müsstest du mir mal deine Mail-Adresse per PM schicken.

Beste Grüße

P.S. Danke nochmal, Tobias, für deine Unterstützung. Ich und mein Prof waren mit der Arbeit letztendlich recht zufrieden.

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

---

Hi,

kein Problem. Helfe gerne und find es immer sehr interessant was andere Kollegen mit OpenFOAM alles machen - leider ist wegen Geheimhaltung der direkte Zugriff nicht immer erlaubt. Wenn ich darf, würde ich mir deine Arbeit heute Abend gerne durchlesen.
E-Mail ist ja aus meinem Profil ersichtlich.

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

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

---

Hier der Case:

Fermenter.tar.gz

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

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

---

Hallo Tobias, hallo RonZ

super - tausend Dank!

Das hilft mir schon mal sehr weiter.

Viele Grüße

Michael

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