---

quader.png

Hallo Zusammen,

Ich habe ein Problem mit der Utility StitchMesh:

Ich habe einen kleinen Quader mit mergeMeshes in einen großen Quader gemerged. Beide wurden davor mit snappyHexMesh vernetzt. In dem großen Quader habe ich ein Volumen in Form des kleinen Quaders ausgespart, um den kleinen dann in das leere Volumen des großen Quaders zu überführen. So wie es aussieht passt der kleine Quader auch genau in die Aushöhlung. Dieser soll im Solving als poröse Zone dienen. Da die beiden Netze von großem und kleinen Quader jedoch nach mergeMeshes getrennt sind, habe ich versucht mit stitchMesh die patches (siehe Bild) zusammenzuführen.

Jedoch erhalte ich folgende Fehlermeldung:

--> FOAM FATAL ERROR:

Points on patch sides do not match to within tolerance 2.74073e-07

Ich habe bereits ein edge refinement meiner Geometrien vorgenommen und versucht mit einem toleranceDict meine Toleranzen zu erhöhen:

pointMergeTol            0.3;

edgeMergeTol            0.0201;

nFacesPerSlaveEdge      5;

edgeFaceEscapeLimit      10;

integralAdjTol          0.8;

edgeMasterCatchFraction  0.4;

edgeCoPlanarTol          0.8;

edgeEndCutoffTol        0.0001;

Ich weiß einfach nicht, was ich noch ausprobieren könnte!
Danke schonmal!

------------------
Viele Grüße,
Lisa

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

---

Hallo Lisa,

habe selbst nur wenig Erfahrung mit stitchMeshes, aber generell die Frage wieso du die Quader in Quader Geometrie nicht über ein SHM laufen lässt und dir die Zonen direkt hier generierst?

Spart die mergeMeshes und stitchMeshes.

Nutze das immer wenn ich bei multiPhaseSolvern bestimmte Bereiche mit unterschiedlichen Phasen belegen muss und keine einfache Geometrie dahinterliegt (Quader Zylinder etc)
Sollte ja auch auf die porösen Zonen übertragbar sein?!

Grüße

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

---

Vielen Dank für die schnelle Antwort!

Daran habe ich auch schon gedacht,aber das wird für komplexe "Aushöhlungen" doch schwierig oder wie machst du das dann?
Weil ich muss ja das Volumen meiner Zone, wie du mir in einem anderen Post bereits erklärt hast, zuvor aus der umliegenden Geometrie entfernen =/

------------------
Viele Grüße,
Lisa

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

---

cubeInCube.tar.gz

Hallo Lisa,

hoffe ich habe dein Problem richtig verstanden.
Habe dir auf die schnelle einen Case für nen porousSimpleFoam gebastelt.

Müsste auch laufen.
Quader in Quader über ein snappy.

Falls das so ausschaut wie du dir das gedacht hast, bietet die Art auch die Möglichkeit kompliziertere innenliegende Geometrien abzubilden.

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

---

Vielen Dank für deine Mühe Tobi!
Das funktioniert echt prima und ich bin total erleichtert!!

Eine Frage habe ich jedoch noch: Ich habe diesen Weg nie ausprobiert, weil ich immer dachte, dass wenn der locationInMesh nicht in meinem porösen Medium liegt, dieses gar nicht mit berücksichtigt wird (sondern nur der Teil des Quaders vernetzt wird). Wird das Mesh für den porösen Quader also nur durch das Erstellen einer cellZone erzeugt? Und warum ist diese cellZonInside outside;? müsste diese nicht "inside" sein (Nur zum Verständnis...)

Danke!

------------------
Viele Grüße,
Lisa

[Diese Nachricht wurde von namali92 am 09. Feb. 2016 editiert.]

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

---

Hallo Lisa,
ich muss ehrlich gestehen, dass ich hier auch auf Vermutungen zurückgreifen muss.
Habe hier etwas hin und her testen müssen bis ich damals die richtigen Zonen erwischt hatte.

Der "andere Tobi" kann hier eventuell besser helfen?

Meine Vermutungen:
Die Gittererzeugung erfolgt ja in Abhängigkeit der gesetzten Koordinaten bei locationInMesh ()
Der gewählte Punkt sitzt aktuell im äußeren Bereich und bei "normaler Ausführung" von sHM wird auch nur dieser Bereich vernetzt und die Mitte ausgespart.

Durch die Definition der inneren STL als cellZone und der Angabe "cellZoneInside outside" wird die Zone in den Bereich des Gitters gelegt, der sich außerhalb der eigentlichen Zellen befindet, also komplementär und somit wird die Mitte ausgefüllt.
Setzt du cellZoneInside inside wird das Innere nicht vernetzt und das entstehende umliegende Gitter wird als cellZone "xy" benannt.

Hoffe ich liege mit dieser Erklärung nicht ganz daneben.
Hat bisher für mich so immer funktioniert

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

---

cubeInCube_Ux_1e10.png zylinder_case.png

Danke, das verstehe ich!

Ich habe jetzt jedoch versucht deinen Case auf meine Geometrien anzuwenden. Dazu habe ich für mein Testmodell lediglich statt dem inneren Würfel einen Zylinder genommen. Das Mesh mit der cellZone sieht auch gut aus.
Mein Problem liegt im solving mit porousSimpleFoam.
Ich habe die Widerstandswerte bereits variiert, jedoch treten sehr seltsame Geschwindigkeits- und Druckwerte auf. Bei deinem case war das nicht so...
Ich habe an den Randbedingungen auch nichts verändert. Im Anhang mal ein Vergleich..

Ist es vielleicht besser eine Geschwindigkeit über einen gegebenen Druck am inlet zu induzieren?

------------------
Viele Grüße,
Lisa

[Diese Nachricht wurde von namali92 am 11. Feb. 2016 editiert.]

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

---

Hallo Lisa,
hast du dein Netz mal überprüft?

Habe eben den gleichen case mit innenliegendem Zylinder gerechnet und bei mir läuft der case durch (mit sinnvollen Werten)

Wurde deine Zone richtig erstellt?

Kannst deinen case ja mal hochladen, dann kann ich bei Gelegenheit mal reinschauen
Grüße

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

---

Nur zur Info (:
Solche Simulationen müssen ohne Probleme funktionieren, ansonsten sinds Settingfehler oder Netzfehler. Bedenkt bitte immer das andere mit OpenFOAM viel komplexere Sachen rechnen und das geht auch ohne Probleme (;

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

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

---

Ja das ist schon bewusst, dass deutlich größere, komplexere Dinge gerechnet werden.

Und, dass es sich um Settingsfehler, Gitterfehler handelt auch, daher ja die Frage nach der Gittersituation für die neue Anwendung...

Ich habe mit porösen Rechnungen nichts am Hut, interessiere mich eher für die Gittererzeugungsproblematiken, weil ich von shm noch immer nicht alle Funktionen zu genüge kenne.

Bin jetzt erst wieder auf ein interessantes "Problem" gestoßen bei der Zonenerzeugung.

Ausgangssituation für beide cases identisch was Zellzahl und locationInMesh (im äußeren Bereich) etc. angeht.

Beim case cubeInCube verwende ich cellZoneInside outside um den inneren Bereich als poröse Zone zu deklarieren.

Beim case cylinderInCube muss ich cellZoneInside inside setzen.

Wo liegt hier der Denkfehler/Handlingfehler?
Beide Gitter werden mit ihren Einstellungen sauber vernetzt, allerdings widerspricht sich das ja?

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

---

Bezüglich snappyHexMesh,...

es gibt ne neue OpenFOAM Version, die sich da wie folgt schimpft: OpenFOAM-3.0+, bei dem in sHM einige updates erfolgten. Schau mal rein, da ist nämlich auch was mit Regionen etc.

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

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

---

testCase_quader_mit_zylinder.zip

Hallo,

Ich habe mal meinen Case angehängt, weil ich den Fehler für meinen cylinderInCube nicht beheben kann..
checkmesh sagt, dass das Mesh OK sei, aber in polyMesh/sets sind jede Menge wrongFaces aufgeführt.
Es wäre cool, wenn einer von euch mal drüberschauen könnte =)

------------------
Viele Grüße,
Lisa

[Diese Nachricht wurde von namali92 am 24. Feb. 2016 editiert.]

[Diese Nachricht wurde von namali92 am 24. Feb. 2016 editiert.]

[Diese Nachricht wurde von namali92 am 24. Feb. 2016 editiert.]

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

---

Shorty, ich habe eine Frage bezüglich der wrongFaces nach der Ausführung von sHM, da du dich mit snappy ja sehr gut auskennst =):

Ich habe bereits deinen Post: http://forum.cad.de/foren/ubb/Forum527/HTML/000703.shtml durchgearbeitet und die STL-Geometrie des Cases in meinem vorherigen Post auch verfeinert. Außerdem habe ich das mit blockMesh erstellte Grundnetz für snappy groß genug gemacht.
Ich weiß einfach nicht, was ich noch verändern soll. Vll. könntest du dir meinen Case ja mal anschauen?
Ich möchte anschließend nämlich für meine Abschlussarbeit an einem komplizierteren Case arbeiten.

Danke und Grüße,
Lisa

------------------
Viele Grüße,
Lisa

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

---

lisaZylinder.tar.gz

Hey Lisa,

nur für dich (:

Code:

---

tar xzf lisaZylinder.tar.gz
cd lisaZylinder
./run.sh
checkMesh

---

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

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

---

Vielen Dank dir für die schnelle Antwort und den Case!

Wie ich gerade gesehen habe, hast du den Quader mit blockMesh erzeugt und nur für den Zylinder die stl-Geometrie verwendet. Für meinen komplexeren Case kann ich die umgebende Kavität jedoch nicht mit blockMesh erstellen, weil die Geometrie komplizierter ist :/..
Gibt es denn keine Möglichkeit, auch die umgebende Kavität (hier noch der Quader) als stl mit snappy mit zu vernetzen, so wie ich es vorhatte?

Danke =)

------------------
Viele Grüße,
Lisa

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

---

lisaZylinder_2.tar.gz

Na klar ist das möglich Lisa,...

Ist nur quick & dirty aber das  sollte schon mal in deine Richtung gehen (:

Prinzipiel machst du nur die Vernetzung deiner Kavität und wenn das passt, legst du dein Poröses Medium rein. Ist dein Poröses Medium ein Sieb vor dem Anschnitt?

Ansonsten macht die Wortnennung "Kavität" keinen Sinn für mich. Bist du Metallurgin oder arbeitest im Bereich der Metallurgie? Wenn ja, wo?

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

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

---

Okay aber dann verstehe ich nicht was ich in meinem Case anders gemacht habe als du 

Liegt es vll an dem featureEdgeRefinement oder den gewählten Verfeinerungslevel von dir?
Ansonsten kann ich keine Unterschiede erkennen..

Nein ich führe Füllsimulationen zur Herstellung von Faserverbundwerkstoffen durch =). Die Kavität ist meine Form in der später die Fasern liegen sollen...
Der Case mit dem Zylinder ist nur ein testcase um zu sehen wie ich poröse Medien durchströmen kann

------------------
Viele Grüße,
Lisa

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

---

Unterschiede sind:

• Skalierung (sollte aber nichts ändern
  
• patches bei blockMesh (bei dir empty, bei mir wall)
  
• Benutzung von features
  
• nCellsInBetween (1 ist immer recht schlecht; bedenke die Numerik)
  

Ich bin mir relativ sicher das es an Punkt #2 liegt. Habs selber aber nicht getested.

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

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

---

Auf diese ganzen Einstellungen wäre ich nie gekommen, vielen Dank dir =).

Abschließend habe ich noch eine Frage: Wie skaliere ich das Hintergrundnetz zurück?

------------------
Viele Grüße,
Lisa

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

---

Also das Hintergrundnetz skalierst du nicht (:

Das wurde hier von mir schon sehr oft erwähnt. Wenn du ne kleine Geometrie hast, dann skalier die um Faktor 1000 und auch dein Hintergrundnetz:

Code:

---

transformPoints -scale "(1000 1000 1000)"    
surfaceTransformPoints -scale "(1000 1000 1000)"  myStl.stl scaled.stl

---

Danach verwendest du sHM + overwrite und skalierst dein Netz der Geometrie wieder zurück (erster Befehl oben mit 0.001). Übrigens liebt sHM es wenn du ne ordentliche Triangulation der STL's hast. Du hast hier lediglich ein Export als STL aus der CAD-Software gemacht.

  

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

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

---

Okay alles klar =)

Ich habe das Mesh von dem von dir erstellten Case jetzt zurück skaliert( das hatte ich bisher nicht gemacht). Im Solving erhalte ich jedoch wieder total unrealistische Werte, wie in meinem alten Case. So langsam weiß ich nicht mehr was das Problem sein könnte  ((
Für die Boundary (U und p) für den porousSimpleFoam habe ich mich an dem angleDuctImplizitTutorial orientiert.

P
boundaryField
{
    walls
    {
        type            zeroGradient;
    }
    inlet
    {
        type            zeroGradient;
    }
    outlet
    {
        type            fixedValue;
        value          $internalField;
    }
    porous
    {
        type            zeroGradient;
    }
    porous_slave
    {
        type            zeroGradient;
    }
}

U
boundaryField
{
    walls
    {
        type            fixedValue;
        value          uniform (0 0 0);
    }
    inlet
    {
        type            flowRateInletVelocity;
        volumetricFlowRate  constant 0.1;
    }
    outlet
    {
        type            inletOutlet;
        value          uniform (0 0 0);
        inletValue      uniform (0 0 0);
    }
    porous
    {
        type            zeroGradient;
    }
    porous_slave
    {
        type            zeroGradient;
    }
}

------------------
Viele Grüße,
Lisa

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

---

Hey Lisa,

zuerstmal würde ich mich um dein Inlet kümmern. Das ist nämlich beim Vernetzen noch gar nicht das was es sein soll (schon mal nachgeschaut wie deine Patches aussehen?). Zur Frage und den Porösen BC. Das ist nicht mehr Teil des "stiches Mesh" Problem.

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

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

---

ich hab doch Inlet und Outlet als patch definiert. Ist das nicht richtig?

Sorry stimmt! Sollte sich mein Problem nicht lösen werde ich weitere Fragen natürlich in einem neuen threat stellen =)

------------------
Viele Grüße,
Lisa

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

---

Ich meine nicht die Typen der patches sondern die patchea selber. Da sind auch faces von der wand dabei

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

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

---

jetzt sehe ich es! und diese faces fehlen wiederum bei den "walls". Wie bekomme ich das in den Griff?

Vll. kannst du ja im Nachhinein einfach die Posts zu diesem Thema verschieben oder löschen?=)
Danke!

------------------
Viele Grüße,
Lisa

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

---

Leider ist das Forum nicht so aufgebaut das ich posts verschieben kann. Bin auch seit über 4 Monaten dabei anzufragen ob es möglich ist eine Art LATEX für Formel n einzubauen. Bislang keine Rückmeldung.

Zur Frage. AutopAtch kann man da verwenden oder d triangulation richtig macheb. Ggf hilft auch schon eine Verschiebung des Hintergrund netztes um ein paar milimeter

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

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

---

Bild1.PNG Triangulation_quader.PNG

Ich habe mich jetzt mal mehr mit der Triangulation von STL's beschäftigt und versucht das Problem mit einer geeigneten Triangulation zu beheben.
Das Problem: An meinem Inlet hängen immer noch faces von den walls (Bild 1)
Woran könnte das liegen?
Ich habe bereits die Anzahl der Dreiecke meiner STL variiert.
Ein Bild von meiner STL ist außerdem im Anhang.

------------------
Viele Grüße,
Lisa

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