Autor
|
Thema: bekomme chtMultiRegionFoam Case nicht lauffähig (3565 mal gelesen)
|
Andi M Mitglied Maschinenbau Student
Beiträge: 10 Registriert: 11.03.2014
|
erstellt am: 19. Mai. 2014 12:47 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, ich habe aus Eigeninitiative angefangen, mich in OpenFoam einzuarbeiten, genauer: in "chtMultiRegionFoam". Das "MultiRegionHeater" Tutorials habe ich soweit durchblickt, und darauf aufbauend versucht, einen eigenen Case zu starten. Dabei handelt es sich um ein simples 3D- Solid, dem ein Wärmestrom zugeführt wird. Das Solid wird umströmt von Luft. Ein Einlass, ein Auslass, Seitenwände sind Symmetrieebenen. Die Geometrie modelliert mit Salome. Über "ideasUnvToFoam" habe ich die Geometrie eingelesen. Dabei entstehen aber nur Mesh-Dateien im Constant Ordner, nicht in den Solid bzw. Fluid Ordnern. In Anlehnung an das Tutorial habe ich mit "splitMeshRegions -cellZones -overwrite" entsprechende Einträge generieren können. Sobald ich aber den Solver starten will, kommt folgende Fehlermeldung: " Selecting thermodynamics package { type heRhoThermo; mixture pureMixture; transport const; thermo hConst; equationOfState perfectGas; specie specie; energy sensibleEnthalpy; }
#0 Foam::error: rintStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 in "/lib64/libc.so.6" #3 Foam::heRhoThermo<Foam::rhoThermo, Foam: ureMixture<Foam::constTransport<Foam::species::thermo<Foam::hConstThermo<Foam: erfectGas<Foam::specie> >, Foam::sensibleEnthalpy> > > >::calculate() at ??:? #4 Foam::rhoThermo::addfvMeshConstructorToTable<Foam::heRhoThermo<Foam::rhoThermo, Foam: ureMixture<Foam::constTransport<Foam::species::thermo<Foam::hConstThermo<Foam: erfectGas<Foam::specie> >, Foam::sensibleEnthalpy> > > > >::New(Foam::fvMesh const&, Foam::word const&) at ??:? #5 Foam::autoPtr<Foam::rhoThermo> Foam::basicThermo::New<Foam::rhoThermo>(Foam::fvMesh const&, Foam::word const&) at ??:? #6 Foam::rhoThermo::New(Foam::fvMesh const&, Foam::word const&) at ??:? #7 at ??:? #8 __libc_start_main in "/lib64/libc.so.6" #9 " Die therm.phy.Prop. sind aber nach mehrmaligem Prüfen i.O.. Ich vermute daher das es eher am Mesh, bzw. an der Erstellung der einzelnen Regionen liegt. Komme aber alleine nicht mehr weiter . Wäre für jede Hilfe dankbar! Gruß Andi Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 19. Mai. 2014 14:17 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hallo Andi, ich arbeite auch sehr viel mit Salome aber hab da noch nie eine Multiregion zusammengebaut. Geht das denn überhaupt, oder wie machst du das denn? Das du mittels ideasUnvToFoam nur ein Mesh erhältst ist plausibel, weil das Tool nicht für Multiregionen gedacht ist sondern nur für eine Netztransformation. Hast du dir dein Netz denn überhaupt schon mal in Paraview angeschaut - inklusive deiner Regionen? Meines Erachtens machst du da etwas falsch. Vor allem mit splitMeshRegions -cellZones. Dazu musst du erstmal Zonen erstellen - könntest bspw. mit setSets machen. Aber die einfachste Möglichkeit wäre:
Code:
Fluid vernetzen und export als fluid.unv Solid vernetzen und export als solid.unvideasUnvToFoam fluid.unv cp -r constant/polyMesh constant/fluid ideasUnvToFoam solid.unv cp -r constant/polyMesh constant/solid rm -r constant/polyMesh
PS: was sagt dir checkMesh denn bzw. (in deinem Fall müsste es ja dann) checkMesh -region fluid heißen (entsprechend solid für dein Festkörper). PPS: Dieser Fehler kommt bei der Initialisierung deines Cases (Programmierung: Konstruktoraufruf). Das heißt für mich, dass entwieder was am Netz oder an den Boundary-Conditions falsch ist. Allerdings müsste ich auch nochmals in die Thermodynamische Datenbank schauen, um genau zu sagen an welcher Stelle dein Problem auftritt (:
------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Andi M Mitglied Maschinenbau Student
Beiträge: 10 Registriert: 11.03.2014
|
erstellt am: 20. Mai. 2014 11:45 <-- editieren / zitieren --> Unities abgeben:
Danke für die schnelle Antwort Shor-ty! ich hatte es mir ursprünglich so gedacht: In Salome erstelle ich alle Regionen, unterteile diese in Volumen-Gruppen, kriege daraus CellZone Dateien, die ich mit dem SplitMeshRegion Befehl zu Region zusammensetze... Wie ich mir dachte, klappt das so nicht xD. ( CheckMesh gab keine Fehler, in paraFoam konnte ich mir die einzelnen CellZones anzeigen lassen. ) Jetzt bin ich dabei, so wie du vorgeschlagen hast, die Regionen einzeln zu modellieren, einzulesen und die entstehenden PolyMesh-Ordner in die constant/Fluid .. Ordner zu schieben. In den dortigen boundarys habe ich die Faces mit Kontakt zu der anderen Region als mappedWall definiert: type mappedWall; nFaces 116; startFace 1932; sampleMode nearestPatchFace; sampleRegion Fluid; samplePatch Kontaktface_1; offsetMode uniform; offset (0 0 0); In den ../0/Fluid & ../0/Solid - Boundaryfields habe ich die Temperaturen an den Kontaktfaces gekoppelt: type compressible::turbulentTemperatureCoupledBaffleMixed; value uniform 600; Tnbr T; neighbourFieldName T; kappa solidThermo; kappaName none; Ist meine vorgehensweise soweit korrekt? Belasse ich nun in den anderen Feldern die Kontakt-faces auf "calculated" ? (U, p usw.) Und schließlich: was würde mir noch fehlen? (z.B. die cellToRegion - Datei im ../0 -Ordner muss doch noch generiert werden?) Gruß Andi Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 20. Mai. 2014 13:41 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hallo Andi, die "cellToRegion" Datei ist nicht für die Simulation erforderlich. Diese wird normalerweise von sHM oder von splitMeshRegions -cellZones erstellt. Kannst du denn mit Salome ein multi-cell Domain anlegen? Muss ja gehen, wenn du sagst, dass du in Paraview deine einzelnen Zonen auswählen kannst. Ansonsten ist deine Vorgehensweise richtig. Die Interfaces in den Boundarys über mappedWall koppeln und die T-Kopplung via der von dir bereits genannten Randbedingung verknüpfen. ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Andi M Mitglied Maschinenbau Student
Beiträge: 10 Registriert: 11.03.2014
|
erstellt am: 23. Mai. 2014 11:58 <-- editieren / zitieren --> Unities abgeben:
Ahoy, multiCell Domains konnte ich nicht anlegen, ich glaube was ich da versucht hab war völliger Unfug. Jedenfalls hab ich alles so ausgeführt wie du sagtest, hat gut geklappt! Vielen Dank dafür schonmal!! Ich wollte jetzt noch versuchen mit Salome ein ordentliches Hexaeder-Mesh zu erzeugen... trotz Tutorials klappt das absolut garnicht. Ich krieg auf meine Faces mappedMesh hin, aber 3D - Elemente nicht. Gibts da eine Vorgehensweise für? Gruß Andi
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 23. Mai. 2014 13:12 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hallo Andi, ein Hexaedermesh für das Hintergrundnetz oder für deine einzelnen Regionen? Wenn du das für die Regionen machen willst kommt es immer auf deine Geometrie drauf an, in wie weit du das machen kannst. Simple Geometrien gehen schon aber komplexe Geometrien wirst du mit sehr viel Aufwand (Partitionieren) etc. erstellen müssen. Beim Hexaedermesh musst du eigentlich immer nur eine Sache im Hinterkopf behalten. Du brauchst immer 8 Seiten. Normalerweise mache ich in Salome nur die Hintergrundnetze weil das so schön einfach ist (mit einem Skript via OpenFOAM auch sehr simple möglich, noch einfacher wie in Salome) aber joa, da ich meine CAD Daten in Salome manipuliere und die STL´s dort meshe und verwende, mach ich das auch hier. Es müsste sogar gehen alles zu automatisieren via python. Zitat:
Ich krieg auf meine Faces mappedMesh hin, aber 3D - Elemente nicht
Verstehe ich nicht ganz, außer du meinst die Eingabemaske in SALOME zur Erstellung bzw. Vorgabe der Parameter. Hier noch was altes von mir: Link im Forum
Vielleicht auch noch Interessant bezüglich Hexnetz und Salome: Link im Forum PS: Kannst den Beitrag ja dann als gelöst markieren (: ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 03. Jul. 2014 14:03 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hallo Andi und Tobi, ich greife diesen Thread hier auf, weil ich glaube dass ihr mir vielleicht weiterhelfen koennt. Es geht um das Meshing für einen Multiregion Case mit SnappyHexMesh. Mein Problem ist, wie die in den .stl Dateien aus constant/trisurface definierten (Sub)Regionen so in einen Case übertragen werden, so dass die Zonen (regionen und subregionen) für die Rechnungen und im Postprocessing wieder als Boundaries auftauchen. Ich vermute, es hat etwas mit der korrekten Verwendung von splitMeshRegions zu tun. Das Problem habe ich auch ins cfd-online forum gepostet (leider bisher ohne Antwort) snappyhexmesh-multiregion-get-regions bzw auch: splitmeshregion Dort sind auch alle Mesh Dateien und der case zu finden (link:case). Fällt euch (oder jemand anderem) eine Möglichkeit ein, das zu lösen? @Tobi: ich habe auch versucht, etwas aus deinen Wärmetauschercase zu lernen: waermetauscher-thread . Könntest du mir den Case zur Verfügung stellen (der Link geht leider nicht mehr) ? Vielen Dank schom mal im Voraus fürs lesen und die Hilfe, Gruss Dirk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 04. Jul. 2014 11:11 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hallo Dirk, ich bin gerade dabei meine Homepage mehrsprachig zu gestalten und auch andere Dinge umzubauen. Das Problem ist dann immer die "Linkkonsistenz" beizubehalten, was nicht immer funktioniert. Der Wärmetauscher den du ansprichst sollte ich noch auf meiner Externen Festplatte haben, bin mir aber nicht ganz sicher. Ich schau mal ob ich den noch habe. Deine Frage hab ich nicht ganz verstanden aber wahrscheinlich hast du ein Problem die einzelnen Zonen zu generieren oder? Grüße ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 04. Jul. 2014 12:55 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hi Tobi, ja so ähnlich. Die einzelnen Regionen werden richtig erzeugt von splitmeshregion, in meinem Fall ein cyl1, cyl2 und ein domain0. Domain0 ist die Kiste, die durch outbox.unv vorgegeben wird. Ausserdem die werden "standartpatches" zwischen den Regionen cyl1_to_cyl2, domain0_to_cyl1 und domain0_to_cyl2 erzeugt. Ich habe aber in den stl Dateien ja einzelne Regionen (=Teilflächen) definiert, zb cyl2_bot_outer. Das ist ein Teilbereich (Zone?) von domain0_to_cyl2, und den würde ich gerne nach dem SHM als patch wiederfinden, wenn ich nach paraFoam -touchAll die snappyMRFEasy{cylinder2}.OpenFOAM öffne. Ich hoffe man kann verstehen was ich meine Dank und Gruss dirk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 07. Jul. 2014 17:17 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hi, ich glaub ich habs verstanden. SplitMeshRegions wird dir aber immer deine "interfaces" in "domain0_to_domain1" zerlegen. Wenn du da auf den Interfaces irgendeinen anderen Patch definiert hast, sollte der überschrieben werden. Zumindest nach meiner Auffassung was du genau machen möchtest Ein Bild erklärt natürlich immer mehr als 1000 Worte
------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 08. Jul. 2014 19:06 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
|
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 09. Jul. 2014 16:38 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hallo Tobi, danke für den case. Wahrscheinlich geht es wirklich nicht, die interfaces aus den STL files zu übernehmen. Ich hätte es so verstanden, dass die Subregionen in diesen Dateien definiert werden können, im snappyHexMeshDict kann man dann für die Bereiche cellZones (oder FaceZones?) erstellen, und am Ende werden dann via splitMeshRegions diese Bereiche herausgeschrieben und ich finde sie als Patches wieder. Es funktioniert, wenn sich die Teilkörper nicht berühren. Viellecht muss ich die Körper weiter aufsplitten, damit sich die gewünschten Flächen auf diesem Weg ergeben. Ich habs nochmal skizziert, siehe Bilder (hoffe der upload klappt). Und viellecht hilft mir irgendwie auch dieses Salome script weiter. Wenn das klappen sollte, melde ich mich hier nochmal. Schöne Gruesse dirk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 09. Jul. 2014 16:55 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Wenn sich die zwei Fluide an deiner blauen Linie wirklich treffen, dann sollte aber die verwendete RB (mappedWall) definitiv verwendet werden. Möchtest du da eine andere RB setzen oder was ist deine Absicht oder die Idee diesen Teil extra zu haben? ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 10. Jul. 2014 15:15 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Genau, es dreht sich um ein Fluid-Solid Problem mit Heattransfer und Radiation. Auf der Oberfläche hätte ich gerne unterschiedliche RB auf Teilen derselben Interface-Fläche untergebracht (und ausserdem hätte ich mittlerweile einfach gerne gewusst, wie/ob solche Probleme überhaupt per snappyHM und splitMeshRegions behandelbar sind,die Frage taucht immer wieder auf und ich hab noch keine richtig passende Antwort dazu gefunden). Ich stöber mal weiter, vielleicht finde ich ja noch etwas. Schöne Grüsse und danke nochmals, dirk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 10. Jul. 2014 15:38 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hi, soweit ich weiß nicht möglich. Wieso möchtest du denn andere Randbedingungen definieren? Die Bedingungen sind doch physikalisch klar definiert? ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 15. Jul. 2014 10:32 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hi Tobi, sorry fuer die verspätete Antwort. Ich würde gerne etwas mit den Temperaturen spielen, dh nicht auf der gesamten Grenzfläche zwischen 2 Regionen dieselbe verwenden sondern schauen was bei Inhomogenitäten passiert. Ausserdem wollte ich schauen, ob/wie sich der Einfluss von unterschiedlichen Emissivitäten für die Strahlung bemerkbar macht (ist zwar etwas "Zukunftsmusik", aber ich dachte dazu ist so ein Split der Grenzöberfläche nötig). viele Grüsse dirk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 15. Jul. 2014 10:37 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hey, also das mit den Emissionsfaktoren macht "sinn" für mich. Muss aber gehen. Werde da ggf heute Abend einen kleinen Fall aufsetzen. Verschiedene Temperaturen ergeben derzeit noch keinen Sinn für mich (:
- Wenn du dein Case so aufbaust wie in deinem letzten Bild, dann funktioniert alles und du hast zwei verschiedene Patches
- Alternativ ist es sicherlich möglich das später noch zu generieren mit bspw. setSet
- Mittels groovyBC kannst du sicherlich auch verschiedene Emissionsfaktoren für diverse Bereiche definieren
Grüße Tobi ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 15. Jul. 2014 12:16 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Dankeschön- es gibt noch mehr Ideen dahinter, verschiedene heat-transfer Koeffizienten bzw. Wärmefluesse. Oder die Temperatur lokal auf einer Oberfläche konstant halten (=Heizung). Mit setSet bin ich noch nicht so richtig warm geworden, aber wenn es damit gehen sollte, beschäftige ich mich damit mal tiefer. Mit dem Konzept vom letzen Bild habe ich für den einfachen Case auch schon 4 Regionen, und wenn die Köerper eine etwas komplizierte Form haben oder nicht nur 2 Teilflächen, wird ziemlich unübersichtlich. Groovy geht sicherlich auch irgendwie-ist aber auch wieder ein Kunstgriff. Wär klasse, wenn Dir etwas "einfaches" einfällt Gruesse dirk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 15. Jul. 2014 14:39 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hallo Dirk, es gibt sicherlich andere Lösungen, da bist du sehr frei und musst einfach mal deinen Ideen freien lauf lassen (: Groovy ist sicherlich nicht all zu schwer - man muss damit nur mal anfangen zu arbeiten. Prinzipiell macht man für unterschiedliche Werte eigentlich immer verschiedene Simulationen, weil wenn du bei dem einen einen anderen Koeffizient verwendest, dann beeinflusst du natürlich die Strömung, welche dann wieder auf das andere Gebiet Rückwirkungen hat (je nach dem wie stark die Wechselwirkung ist, ist natürlich die Verfälschung). An deiner Stelle würde ich deinen Case so belassen und dann via Copy-Paste einen neuen erstellen, die Parameter ändern die du möchtest und wieder rechnen lassen. Das kann man alles gemütlich mit einem Bash-Skript abhandeln und kann dann hunderte Simulationen mit einem Shell-Skript ausführen. Sehr simpel und easy. Sollte mir noch irgendwas einfallen, dann werde ich dir das natürlich mitteilen.
------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 30. Jul. 2014 12:05 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
|
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 30. Jul. 2014 14:16 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hallo Dirk, danke für deinen Hinweis... habs grad mal überflogen und den Testcase betrachtet. Leider funktioniert der Testcase bei mir nicht! Datei ist bei mir aktuell... PS: Nach git push und recompilierung - funktioniert der Testcase. PPS: Fabian hat wieder geantwortet mit wohl vielversprechenden Anregungen. ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 30. Jul. 2014 14:49 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hi, welcher case geht nicht, meiner mit den 2 boxen oder der aus dem bug-report? Ich habe meinen case gerade nochmal heruntergeladen und ausprobiert mit ./makeMesh und splitMeshRegions -cellZones -overwrite. Aber ich hab auch noch die 222 Version, vielleicht hat sich da wieder etwas geändert... Gruss Dirk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 30. Jul. 2014 16:25 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hallo Dirk, so trivial wie dein Problem scheint ist es nicht. Hab jetzt sehr viel probiert allerdings funktioniert es nicht da folgendes Problem:
- Wenn du eine Domain mittels mehreren STL Dateien erzeugst (Regionen), dann kannst du jeder Domain nur einen faceName geben. Nach snappyHexMesh sind deine Faces dann unter constant/polyMesh/faceZones drin. Diese werden bei splitMeshRegion -useFaceZones verwendet.
Code:
regionSTL.stl { level ( 0 0 ); faceZone nameDerFaces; cellZones regionSTL; cellZoneInside true; regions { . . . } }
- Einfügen von faceZones in die Subtags "regions" hat keinen Einfluss. Heißt snappyHexMesh beachtet das nicht. Das heißt, dass du so oder so nur eine faceZone pro Region erhältst (in diesem Fall). Die Eingabe ist sinnfrei und zudem kann dann splitMeshRegions -cellZonesOnly nicht mehr angewendet werden (checkMesh muss immer mehrere Regionen aufweisen):
Code:
regionSTL.stl { level ( 0 0 ); cellZones regionSTL; cellZoneInside true; regions { wall_1 { level (0 0); faceZone wall_1; wall_2 { level (0 0); faceZone wall_2; . . } }
- Ergo: man musst eine FaceZone + CellZone erstellen, damit man nachher den Befehl splitCellZones -cellZonesOnly -useFaceZones verwenden kann
- Wenn du das wie oben erwähnt durchführst (erstes Beispiel) dann klappt das auch (wie du weißt), nur der gewünschte Effekt bleibt aus, da jede Seite in deiner Domain dann den Namen der zuvor angegebenen "faceZone" erhält. Der einzige Unterschied zwischen den zwei Befehlen ist folgender:
Code:
// splitMeshRegions -cellZonesOnly -useFaceZones nameDerFaces_nameDerFaces_nameDerFaces2// splitMeshRegions -cellZonesOnly nameDerFaces_nameDerFaces2
- Wenn du alle STL's einzeln einliest (also keine Regionen), dann kannst du für jede STL ein eigenes Face erstellen, das klappt sehr gut aber dann hast du das Problem, dass die STL`s nicht geschlossen sind und damit keine cellZones erstellt wreden können (in SnappyHexMesh)
Ich hoffe das das nicht all zu umständlich formuliert ist, da es etwas verwirrend. Deswegen nochmals in kurz: - Problem bei Multiregionen ist, dass die Regionen (so meine ich) nur ein Facename aufweißen können und zwar genau der, den du in faceZone bei snappyHexMesh einstellst. Die STL-Regionen werden dabei einfach nicht beachtet und ich weiß nicht wie man snappyHexMesh mitteilen kann, dass es nicht die faceZone xxx für die ganze cellZone_x erstellt sondern die einzelnen STL Oberflächen jeweils für die Erstellung einer faceZone verwendet. - Alternative: FaceZones über snappyHexMesh erstellen und via setSet ggf. die Zonen definieren. Dann solltest du mit splitMeshRegions -cellZonesOnly -useFaceZones ans Ziel kommen. - Sollte ich eine konkrete Lösung finden, teile ich sie gerne mit. ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 31. Jul. 2014 12:34 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hi Tobi, vielen Dank für deine Mühe! Ich glaube, dass splitMeshRegions -cellZonesOnly -useFaceZones das richtige ist. Code: splitMeshRegions -cellZonesOnly -useFaceZones
ergibt: Code: Using current faceZones to divide inter-region interfaces into multiple patches.Using current cellZones to split mesh into regions. This requires all cells to be in one and only one cellZone. --> FOAM FATAL ERROR: For the cellZonesOnly option all cells have to be in a cellZone. Cell 0 at(-4.6246 -4.41818 -9.50169) is not in a cellZone. There might be more unzoned cells
Alle cells müssen also in ein und derselben cellZone sein. Ich habe versucht, das per setSet zu machen, komme aber nicht an diese "unzoned cells" heran. Weisst du wie man diese erfassen kann?
Und: Die Ausgabe von checkMesh ergibt (nach splitMeshRegions -cellZones -overwrite): Code: Checking patch topology for multiply connected surfaces... Patch Faces Points Surface topology min_z 600 651 ok (non-closed singly connected) max_z 900 1010 ok (non-closed singly connected) min_y 800 861 ok (non-closed singly connected) max_y 800 861 ok (non-closed singly connected) min_x 1200 1271 ok (non-closed singly connected) max_x 2964 3085 ok (non-closed singly connected) box1_interface_large 0 0 ok (empty) box1_interface_large_slave 0 0 ok (empty) box1_interface_small 0 0 ok (empty) box1_interface_small_slave 0 0 ok (empty) box1.stl_box1_walls 0 0 ok (empty) box1.stl_box1_walls_slave 0 0 ok (empty) box2_bot 0 0 ok (empty) box2_bot_slave 0 0 ok (empty) box2_interface_large 0 0 ok (empty) box2_interface_large_slave 0 0 ok (empty) box2_interface_small 0 0 ok (empty) box2_interface_small_slave 0 0 ok (empty) box2_box2_wall 0 0 ok (empty) box2_box2_wall_slave 0 0 ok (empty)
Alle meine Patches sind also schon noch irgendwie vorhanden, aber sie sind leer. Ich werde auch nochmal versuchen, die Regions aus den stl-Dateien zu vereinzeln und dann einzulesen. Falls sich damit was ergibt, werd ichs hier posten. Viele Gruesse, danke nochmals dirk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 01. Aug. 2014 10:40 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hi Dirk, kannst gern versuchen aber hab das alles schon getestet. Weiteres findest du im cfd-online Forum. Das Problem ist, dass es nicht mit snappyHexMesh alleine gehen wird. Grüße Tobi ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
Beiträge: 2463 Registriert: 27.08.2010 OpenFOAM-dev (Foundation) OpenFOAM-xxxx (ESI)
|
erstellt am: 01. Aug. 2014 13:42 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
Hi Dirk, kannst gern versuchen aber hab das alles schon getestet. Weiteres findest du im cfd-online Forum. Das Problem ist, dass es nicht mit snappyHexMesh alleine gehen wird. Grüße Tobi ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 22. Aug. 2014 11:35 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
|
dzi Mitglied
Beiträge: 20 Registriert: 02.11.2012 OF 2.2.2 , Salome 7.2.0
|
erstellt am: 04. Sep. 2014 15:58 <-- editieren / zitieren --> Unities abgeben: Nur für Andi M
|