---

Submesh.jpg zwei_Solids_vernetzt.jpg

Hallo, ich habe an dieser Stelle wieder Fragen zu meinem chtMultiRegion-Modell.

Der Trick mit den vernetzten Edges um verbundene Flächen und geschlossene STLs zu bekommen ist mir bisher nicht gelungen, aus diesem Grund hatte ich Salome zum Vernetzen weiter verwendet. Da ich in meinem chtMultiRegion-Modell boundary layers einsetzen möchte, hatte ich viscous layers in Salome verwendet.

Um meinem Fluidnetz die viscous layer Hypothese zuweisen zu können, habe ich das Fluidnetz als SubMesh angelegt. Die Vernetzung läuft ohne Fehlermeldung durch, allerdings werden dabei keine layers erstellt wie es funktionieren sollte. In den angehängten Bildern ist einmal das Submesh, das keine layer enthält markiert dargestellt und einmal ist eine Darstellung aus zwei getrennten Meshes zu sehen, wo das Fluidnetz layer enthält. Das Netz im zweiten Bild bringt mir nichts, da die Regionen hier als unterschiedliche und nicht zusammen passende Netze erstellt wurden.

Wie kann ich dafür sorgen, dass im SubMesh die viscous layers richtig erstellt werden? Ich kann die Datei nicht mit hochladen da gepackt 1,7 MB.

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

---

Hallo,

könntest du deine STEP Datei zur Verfügung stellen?
Übrigens sind deine Layer, die du generiert hast nicht wirklich sehr nützlich.

Suchfunktionen sind nützlich!
http://forum.cad.de/foren/ubb/Forum527/HTML/000383.shtml

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

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

---

Study1.zip

Das hochladen hat ja doch geklappt. Das Forum akzeptiert nur ZIP nicht RAR 

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

---

ich habe eine mögliche Antwort im Salome-Forum entdeckt.

http://www.salome-platform.org/forum/forum_14/64297494#295229772

Interne Flächen können keine viscous layers bekommen. Es soll aber einen Trick geben das hinzubekommen. Den werde ich jetzt mal ausprobieren.

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

---

test.png

Welche Formate akzeptiert werden steht unten bei der Upload-Make. Siehe auch hier: File Formate

Bezüglich deinem Netz. Ich wollte das gar nicht mit Salome machen sondern schau eher in Richtung sHM. Ich mag nämlich Tetnetze nicht sonderlich auf Grund der numerischen Eigenschaften.

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

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

---

Wegen snappy: Du hattest in einem anderen Thread mal vorgeschlagen die Kanten zwischen den Regionen vernetzen zu lassen, um sicherzustellen dass die Regionen zusammen eine geschlossene Shell bilden bevor sie als STL für sHM exportiert werden. Die Shells müsste ich doch dann ebenfalls mit den gleichen Parametern vernetzen um sie als STL exportieren zu können. War das so gemeint?

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

---

Mit dem Trick der im Salome-Forum beschrieben ist bekomme ich beim Versuch zu vernetzen die Meldung

"Invalid input mesh. Source elements don't cover totally the geometrical face"

Ich werds auch dort mal posten

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

---

Nachdem ich die neue Version Salome 7.4 installiert hab, hat es geklappt viscous layers bei internen Flächen anzuwenden.

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

---

Zitat:

---

Original erstellt von bacengeugn:
Wegen snappy: Du hattest in einem anderen Thread mal vorgeschlagen die Kanten zwischen den Regionen vernetzen zu lassen, um sicherzustellen dass die Regionen zusammen eine geschlossene Shell bilden bevor sie als STL für sHM exportiert werden.

---

Das bezog sich auf eine STL, die mehrere Regionen aufweist. Ist aber was anderes wenn du mehrere Regionen als "Fluid/Solid" hast.

Wenn ich darf, würde ich dein Beispiel gerne als SnappyHexMesh Tutorial auf meine Homepage/OpenFOAM Wiki setzen.

Wird dann quasi ein Multi-Region Tutorial

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

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

---

Ja wenn ich dann sehe, wie ich es zustande bringen kann. Ich konnte nicht mal geschlossene STLs erzeugen wenn ich die STLs aus einer einzelnen Volumengruppe zusammen gebaut hab.

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

---

Tutorials

Ist jetzt nur mal ein grobes Beispiel, da ich nicht alle Zeit der Welt hab.

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

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

---

Ich hab mal versucht den Arbeitsablauf Salome -> sHM anhand des Tutorials zu rekonstruieren

• Import einer STP-Datei mit den erforderlichen Körpern
  
• Volume Groups der Regionen erstellen
  
• Shell oder Face für Randbedingungen erstellen (Volume Groups in Faces "explodieren" und Shell aus den Faces bilden)
  
• Edge Groups innerhalb der Shells/Faces erstellen für Verbindungskanten
  
• Shells bzw. Compounds für die Regionen aus den Shells/Faces bzw. Shells/Solids erstellen
  
• Face Groups für die Randbedingungen erstellen, evtl auch für Flächen, die genauer approximiert werden müssen
  
• 2D-Meshes für die Regionen erstellen, Face Groups aus den Randbedingungen übernehmen
  
• evtl. Submeshes für genauere Approximation von Flächen
  
• Face Groups im Mesh als STL einzeln exportieren
  
• für alle Regionen Terminal: cat stlRegion/* > constant/triSurface/Region.stl
  
• Hintergrundnetz erstellen mit Hexahedron (i,j,k)
  
• Export Hintergrundnetz zu UNV
  
• Terminal im case directory: ideasUnvToFoam backgroundMesh.unv
  

Passt das so?

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

---

Zitat:

---

für alle Regionen Terminal: cat stlRegion/* > constant/triSurface/Region.stl

---

Ich empfehle dir das in einer bash Funktion zu machen, die dir noch die Namen der STL in deine STL schreibt. Damit hast du dann am Ende in jeder STL in der ersten Zeile sowas:

Code:

---

name nameDerStl

---

und danach erst mit cat * > .. alle zusammenfügen. Damit hast du dann eine REGION STL erstellt. Jede Region kannst du mit sHM dann separat ansprechen. Wenn du bspw. nur eine einzelne STL Datei hast, kannst dort gleich deine BC erstellen. Sehr praktisch! Betrachten kannst du das dann auch direkt in Paraview. Dort werden deine einzelnen Regionen der Stereolithdatei verschiedenfarbig dargestellt.

• In Salome gibt es so viele Wege die zum gleichen Ergebnis führen, d.h. du musst dir selber den komfortabelsten Weg suchen. Ob du jetzt etwas "expodest", "groups" erstellst, etc. ist dir überlassen
  
• Backgroundmesh muss man nicht zwingend in Salome machen. Kann man auch automatisieren und mit einem bash Skript + surfaceCheck erstelle (:
  

Was ich aber eindeutig erkenne ist, dass du aus dem Tutorial wohl ziemlich viel Input erhalten hast (:

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

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

---

Salome hat mir jetzt beim exportieren der STLs "outer lo" statt "outer loop" in die Datei geschrieben. Ich werds wohl mit sed reparieren können, aber wieso nur?! 

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

---

Bei mir funktioniert das einwandfrei.
Hatte da noch nie Probleme mit. Ist das im Geometry Modul als auch im Mesh Modul?
Hast du dein Salome selber kompiliert oder von den Binaries aus installiert...

Sollte normal ohne Probleme funktionieren!
Immerhin hast du das ja bereits gemacht (:

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

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

---

Ich habe kürlich Salome 7.4 (für Windows) installiert (binaries extrahiert) weil hier die viscous layers auf internen Flächen funktionieren. Es war heute das erste mal dass ich STLs mit der neuen Version exportiert habe

Ich muss in der Datei den String "outer lo" komplett ersetzen. Wenn ich nur "lo" ersetze wird aus "endloop" "endloopop". Keine Ahnung wie ich das mit sed umsetze,

Code:

---

sed s/end\ lo/end\ loop/g $F > $F"_2"

---

funktioniert nicht

daher werd ich das im Editor bei jeder Datei mit suchen und ersetzen manuell machen müssen.
Oder kann ich explizit Wörter ersetzen statt eines substrings? Das würde dann ja auch funktionieren.

[Diese Nachricht wurde von bacengeugn am 27. Nov. 2014 editiert.]

[Diese Nachricht wurde von bacengeugn am 27. Nov. 2014 editiert.]

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

---

Hi,

wusste nicht das du Windows User bist. In Linux ist das mit vim ganz einfach.
sed

Code:

---

sed 's/ lo/ loop/g' -i file.stl

---

Bin mir aber nicht sicher ob die Syntax in Windows genau so ist.

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

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

---

Naja ich muss mit Windows arbeiten, da es unser CAD nur für Windows gibt. Wenn OpenFOAM Windows vollständig unterstützen würde wäre ich auch glücklich. Ich hab zwar Ubuntu auf einer VM laufen, aber Salome konnte ich dort immer noch nicht installieren. Zu Hause hats geklappt, im Büro aber nicht. Das Script hab ich in der VM laufen.

Am schönsten ist es wenn man nur ein System braucht und pflegen muss bzw. sich nur in einem OS zurecht finden muss.

Ich könnte Salome auf Ubuntu kompilieren aber was das wieder für ein Aufwand ist und wenn ich dann plötzlich noch Bibliotheken zusammen suchen muss, kann ich den Aufwand nicht mal abschätzen.

Das Script hat jetzt wunderbar funktioniert und die STL die ich erstellt habe ist auch geschlossen. Toll!

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

---

Sehr schön, freut mich das alles geklappt hat.

Hmmm ... für CFD und OpenFOAM empfehle ich Linux, da man hier einfach wesentlich mehr Möglichkeiten ausschöpfen kann. Ist natürlich jedem seine Sache. Ich mag bspw. auch GUI's nicht sonderlich und kann jedem nur vim empfehlen der sich in Linux bewegt (:

Wenn du eine Virtual Box hast, müsste es auch möglich sein die Pre-Compiled Binaries von Salome zu verwenden, d.h. du musst die nur starten ohne zu kompilieren.

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

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

---

Doch noch ein Fehler

also surfaceCheck sagt zwar die stl seien geschlossen aber paraview kann sie nicht öffnen. Es schließt einfach mit einem Fehler. Auch wenn ich die STLs aus deiner salomeCAD.hdf exportiere. Ich kann aber die STLs öffnen, die du online gestellt hast. Ich muss doch die Flächengruppen im Meshmodul exportieren?

sHM hab ich noch nicht auf die STLs getestet

Code:

---

estang@ubuntu:~/OpenFOAM/estang-2.3.0/run/snappyMultiRegionLayerMeshing$ paraview

Warning: In /home/opencfd/OpenFOAM/ParaView-4.1.0/ParaViewCore/ServerManager/Rendering/vtkSMPVRepresentationProxy.cxx, line 279
vtkSMPVRepresentationProxy (0x105dbd88): Could not determine array range.

Warning: In /home/opencfd/OpenFOAM/ParaView-4.1.0/ParaViewCore/ServerManager/Rendering/vtkSMPVRepresentationProxy.cxx, line 279
vtkSMPVRepresentationProxy (0x105dbd88): Could not determine array range.

estang@ubuntu:~/OpenFOAM/estang-2.3.0/run/snappyMultiRegionLayerMeshing$ paraview
ERROR: In /home/opencfd/OpenFOAM/ParaView-4.1.0/VTK/IO/Geometry/vtkSTLReader.cxx, line 378
vtkSTLReader (0xb270c40): STLReader error reading file: /home/estang/OpenFOAM/estang-2.3.0/run/HP50bar_2/cad/stlFluid/inlet.stl Premature EOF while reading point.

*** Error in `/opt/paraviewopenfoam410/lib/paraview-4.1/paraview': double free or corruption (!prev): 0x0b263a68 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x767c2)[0xb5e9b7c2]
/lib/i386-linux-gnu/libc.so.6(+0x77510)[0xb5e9c510]
/lib/i386-linux-gnu/libc.so.6(fclose+0x14c)[0xb5e8ad1c]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkIOGeometry-pv4.1.so.1(_ZN12vtkSTLReader11RequestDataEP14vtkInformationPP20vtkInformationVectorS3_+0x2b4)[0xaf32b854]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN20vtkPolyDataAlgorithm14ProcessRequestEP14vtkInformationPP20vtkInformationVectorS3_+0xc7)[0xb4b63 e47]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVVTKExtensionsDefault-pv4.1.so.1(_ZN19vtkFileSeriesReader11RequestDataEP14vtkInformationPP20vtkInformationVectorS3_+0x64)[0xb4ff741 4]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVVTKExtensionsDefault-pv4.1.so.1(_ZN19vtkFileSeriesReader14ProcessRequestEP14vtkInformationPP20vtkInformationVectorS3_+0xd0)[0xb4ff 7520]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN12vtkExecutive13CallAlgorithmEP14vtkInformationiPP20vtkInformationVectorS3_+0x63)[0xb4b54f63]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN23vtkDemandDrivenPipeline11ExecuteDataEP14vtkInformationPP20vtkInformationVectorS3_+0x4d)[0xb4b4f 72d]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN24vtkCompositeDataPipeline11ExecuteDataEP14vtkInformationPP20vtkInformationVectorS3_+0x94)[0xb4b4 c9e4]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN23vtkDemandDrivenPipeline14ProcessRequestEP14vtkInformationPP20vtkInformationVectorS3_+0x223)[0xb 4b524e3]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN32vtkStreamingDemandDrivenPipeline14ProcessRequestEP14vtkInformationPP20vtkInformationVectorS3_+0 x1b5)[0xb4b675b5]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN24vtkCompositeDataPipeline15ForwardUpstreamEP14vtkInformation+0x15e)[0xb4b4be4e]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN23vtkDemandDrivenPipeline14ProcessRequestEP14vtkInformationPP20vtkInformationVectorS3_+0x1b4)[0xb 4b52474]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN32vtkStreamingDemandDrivenPipeline14ProcessRequestEP14vtkInformationPP20vtkInformationVectorS3_+0 x1b5)[0xb4b675b5]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN23vtkDemandDrivenPipeline10UpdateDataEi+0x9e)[0xb4b50e9e]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkCommonExecutionModel-pv4.1.so.1(_ZN32vtkStreamingDemandDrivenPipeline6UpdateEi+0xab)[0xb4b6825b]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerImplementationCore-pv4.1.so.1(_ZN16vtkSISourceProxy14UpdatePipelineEidb+0x13f)[0xb5a6563f]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerManagerApplication-pv4.1.so.1(_Z23vtkSISourceProxyCommandP26vtkClientServerInterpreterP13vtkObjectBasePKcRK21vtkClientServer StreamRS5_Pv+0xa32)[0xb414a042]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkClientServer-pv4.1.so.1(_ZN26vtkClientServerInterpreter19CallCommandFunctionEPKcP13vtkObjectBaseS1_RK21vtkClientServerStreamRS4_+0x1 3c)[0xb39cbe5c]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerManagerApplication-pv4.1.so.1(_Z33vtkSIFileSeriesReaderProxyCommandP26vtkClientServerInterpreterP13vtkObjectBasePKcRK21vtkCl ientServerStreamRS5_Pv+0x4d4)[0xb4144b84]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkClientServer-pv4.1.so.1(_ZN26vtkClientServerInterpreter19CallCommandFunctionEPKcP13vtkObjectBaseS1_RK21vtkClientServerStreamRS4_+0x1 3c)[0xb39cbe5c]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkClientServer-pv4.1.so.1(_ZN26vtkClientServerInterpreter20ProcessCommandInvokeERK21vtkClientServerStreami+0x1ae)[0xb39cc1ee]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkClientServer-pv4.1.so.1(_ZN26vtkClientServerInterpreter17ProcessOneMessageERK21vtkClientServerStreami+0x547)[0xb39ccd87]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkClientServer-pv4.1.so.1(_ZN26vtkClientServerInterpreter13ProcessStreamERK21vtkClientServerStream+0x30)[0xb39cd080]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerImplementationCore-pv4.1.so.1(_ZN16vtkPVSessionCore21ExecuteStreamInternalERK21vtkClientServerStreamb+0x12e)[0xb5a2f22e]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerImplementationCore-pv4.1.so.1(_ZN16vtkPVSessionCore13ExecuteStreamEjRK21vtkClientServerStreamb+0x49)[0xb5a2f009]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerImplementationCore-pv4.1.so.1(_ZN16vtkPVSessionBase13ExecuteStreamEjRK21vtkClientServerStreamb+0x39)[0xb5a2dae9]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerManagerCore-pv4.1.so.1(_ZN10vtkSMProxy13ExecuteStreamERK21vtkClientServerStreambj+0x66)[0xb5b413c6]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerManagerCore-pv4.1.so.1(_ZN15vtkSMOutputPort22UpdatePipelineInternalEdb+0x158)[0xb5b2d838]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerManagerCore-pv4.1.so.1(_ZN15vtkSMOutputPort14UpdatePipelineEd+0x22)[0xb5b2daa2]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkPVServerManagerCore-pv4.1.so.1(_ZN16vtkSMSourceProxy14UpdatePipelineEd+0x62)[0xb5b86af2]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkpqCore-pv4.1.so.1(_ZN16pqPipelineSource14updatePipelineEv+0x67)[0xb703e457]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkpqCore-pv4.1.so.1(_ZNK15pqDisplayPolicy20getPreferredViewTypeEP12pqOutputPortb+0x2f0)[0xb6ff2670]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkpqCore-pv4.1.so.1(_ZNK15pqDisplayPolicy16getPreferredViewEP12pqOutputPortP6pqView+0xf2)[0xb6ff20e2]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkpqCore-pv4.1.so.1(_ZNK15pqDisplayPolicy29createPreferredRepresentationEP12pqOutputPortP6pqViewb+0x5c)[0xb6ff1cfc]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkpqComponents-pv4.1.so.1(_ZN17pqPropertiesPanel5applyEv+0x482)[0xb73d7e42]
/opt/paraviewopenfoam410/lib/paraview-4.1/libvtkpqComponents-pv4.1.so.1(+0x3159d4)[0xb74ba9d4]
/usr/lib/i386-linux-gnu/libQtCore.so.4(_ZN11QMetaObject8activateEP7QObjectPKS_iPPv+0x247)[0xb626afc7]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN15QAbstractButton7clickedEb+0x4d)[0xb6bf858d]
/usr/lib/i386-linux-gnu/libQtGui.so.4(+0x54f381)[0xb6913381]
/usr/lib/i386-linux-gnu/libQtGui.so.4(+0x550707)[0xb6914707]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent+0x8e)[0xb691480e]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN7QWidget5eventEP6QEvent+0xd4a)[0xb65571aa]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN15QAbstractButton5eventEP6QEvent+0x62)[0xb6915812]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN11QPushButton5eventEP6QEvent+0x3c)[0xb69affdc]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0xa4)[0xb64fd744]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x1dd8)[0xb6505df8]
/usr/lib/i386-linux-gnu/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x7a)[0xb6255eda]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb+0x103)[0xb6503aa3]
/usr/lib/i386-linux-gnu/libQtGui.so.4(+0x1c34e8)[0xb65874e8]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN12QApplication15x11ProcessEventEP7_XEvent+0x18c5)[0xb6586c05]
/usr/lib/i386-linux-gnu/libQtGui.so.4(+0x1ee274)[0xb65b2274]
/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x13e)[0xb363a83e]
/lib/i386-linux-gnu/libglib-2.0.so.0(+0x46be8)[0xb363abe8]
/lib/i386-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x38)[0xb363aca8]
/usr/lib/i386-linux-gnu/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5f)[0xb62858bf]
/usr/lib/i386-linux-gnu/libQtGui.so.4(+0x1ee32e)[0xb65b232e]
/usr/lib/i386-linux-gnu/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x43)[0xb62549f3]
/usr/lib/i386-linux-gnu/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x179)[0xb6254d19]
/usr/lib/i386-linux-gnu/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x8e)[0xb625a89e]
/usr/lib/i386-linux-gnu/libQtGui.so.4(_ZN12QApplication4execEv+0x24)[0xb64fb974]
/opt/paraviewopenfoam410/lib/paraview-4.1/paraview(main+0x184)[0x804d3a4]
======= Memory map: ========
08048000-08502000 r-xp 00000000 08:01 1102110    /opt/paraviewopenfoam410/lib/paraview-4.1/paraview
08502000-08503000 r--p 004b9000 08:01 1102110    /opt/paraviewopenfoam410/lib/paraview-4.1/paraview
08503000-08504000 rw-p 004ba000 08:01 1102110    /opt/paraviewopenfoam410/lib/paraview-4.1/paraview
0a2a3000-0b72b000 rw-p 00000000 00:00 0          [heap]
a582a000-a58aa000 rwxp 00000000 00:00 0
a58aa000-a5e50000 rw-s 00000000 00:04 5799938    /SYSV00000000 (deleted)
a5e50000-a6021000 rw-p 00000000 00:00 0
a6021000-a6053000 r-xp 00000000 08:01 398328    /usr/lib/i386-linux-gnu/libtxc_dxtn_s2tc.so.0.0.0
a6053000-a6054000 r--p 00031000 08:01 398328    /usr/lib/i386-linux-gnu/libtxc_dxtn_s2tc.so.0.0.0
a6054000-a6055000 rw-p 00032000 08:01 398328    /usr/lib/i386-linux-gnu/libtxc_dxtn_s2tc.so.0.0.0
a6055000-a7055000 rw-s 105538000 00:05 8357      /dev/dri/card0
a7055000-a8661000 r-xp 00000000 08:01 397493    /usr/lib/i386-linux-gnu/libLLVM-3.3.so.1
a8661000-a871c000 r--p 0160b000 08:01 397493    /usr/lib/i386-linux-gnu/libLLVM-3.3.so.1
a871c000-a871e000 rw-p 016c6000 08:01 397493    /usr/lib/i386-linux-gnu/libLLVM-3.3.so.1
a871e000-a8729000 rw-p 00000000 00:00 0
a8729000-a895d000 r-xp 00000000 08:01 397781    /usr/lib/i386-linux-gnu/libgallium.so.0.0.0
a895d000-a8967000 r--p 00233000 08:01 397781    /usr/lib/i386-linux-gnu/libgallium.so.0.0.0
a8967000-a8969000 rw-p 0023d000 08:01 397781    /usr/lib/i386-linux-gnu/libgallium.so.0.0.0
a8969000-a8b31000 rw-p 00000000 00:00 0
a8b31000-a8ef6000 r-xp 00000000 08:01 397708    /usr/lib/i386-linux-gnu/libdricore9.2.1.so.1.0.0
a8ef6000-a8efe000 r--p 003c5000 08:01 397708    /usr/lib/i386-linux-gnu/libdricore9.2.1.so.1.0.0
a8efe000-a8f04000 rw-p 003cd000 08:01 397708    /usr/lib/i386-linux-gnu/libdricore9.2.1.so.1.0.0
a8f04000-a8f19000 rw-p 00000000 00:00 0
a8f19000-a8f68000 r-xp 00000000 08:01 398679    /usr/lib/i386-linux-gnu/dri/vmwgfx_dri.so
a8f68000-a8f69000 r--p 0004e000 08:01 398679    /usr/lib/i386-linux-gnu/dri/vmwgfx_dri.so
a8f69000-a8f6a000 rw-p 0004f000 08:01 398679    /usr/lib/i386-linux-gnu/dri/vmwgfx_dri.so
a8f6a000-a8f6c000 rw-p 00000000 00:00 0
a8f6c000-a8f77000 r-xp 00000000 08:01 132099    /lib/i386-linux-gnu/libnss_files-2.17.so
a8f77000-a8f78000 r--p 0000a000 08:01 132099    /lib/i386-linux-gnu/libnss_files-2.17.so
a8f78000-a8f79000 rw-p 0000b000 08:01 132099    /lib/i386-linux-gnu/libnss_files-2.17.so
a8f79000-a8f83000 r-xp 00000000 08:01 132104    /lib/i386-linux-gnu/libnss_nis-2.17.so
a8f83000-a8f84000 r--p 00009000 08:01 132104    /lib/i386-linux-gnu/libnss_nis-2.17.so
a8f84000-a8f85000 rw-p 0000a000 08:01 132104    /lib/i386-linux-gnu/libnss_nis-2.17.so
a8f85000-a8f8c000 r-xp 00000000 08:01 132095    /lib/i386-linux-gnu/libnss_compat-2.17.so
a8f8c000-a8f8d000 r--p 00006000 08:01 132095    /lib/i386-linux-gnu/libnss_compat-2.17.so
a8f8d000-a8f8e000 rw-p 00007000 08:01 132095    /lib/i386-linux-gnu/libnss_compat-2.17.so
a8f8e000-a9037000 r--p 00000000 08:01 920941    /usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
a9037000-a9042000 r-xp 00000000 08:01 420352    /usr/lib/i386-linux-gnu/libjbig.so.0.0.0
a9042000-a9043000 r--p 0000a000 08:01 420352    /usr/lib/i386-linux-gnu/libjbig.so.0.0.0
a9043000-a9046000 rw-p 0000b000 08:01 420352    /usr/lib/i386-linux-gnu/libjbig.so.0.0.0
a9046000-a90b4000 r-xp 00000000 08:01 398044    /usr/lib/i386-linux-gnu/libtiff.so.5.1.0
a90b4000-a90b5000 r--p 0006e000 08:01 398044    /usr/lib/i386-linux-gnu/libtiff.so.5.1.0
a90b5000-a90b7000 rw-p 0006f000 08:01 398044    /usr/lib/i386-linux-gnu/libtiff.so.5.1.0
a90b7000-a9108000 r-xp 00000000 08:01 402967    /usr/lib/i386-linux-gnu/libQtSvg.so.4.8.4
a9108000-a9109000 r--p 00050000 08:01 402967    /usr/lib/i386-linux-gnu/libQtSvg.so.4.8.4
a9109000-a910a000 rw-p 00051000 08:01 402967    /usr/lib/i386-linux-gnu/libQtSvg.so.4.8.4
a910a000-a9120000 r--p 00000000 08:01 791391    /usr/share/fonts/type1/gsfonts/n022024l.pfb
a9120000-a9155000 r-xp 00000000 08:01 398061    /usr/lib/i386-linux-gnu/liblcms.so.1.0.19
a9155000-a9156000 r--p 00034000 08:01 398061    /usr/lib/i386-linux-gnu/liblcms.so.1.0.19
a9156000-a9157000 rw-p 00035000 08:01 398061    /usr/lib/i386-linux-gnu/liblcms.so.1.0.19
a9157000-a9159000 rw-p 00000000 00:00 0
a9159000-a91d9000 r-xp 00000000 08:01 420349    /usr/lib/i386-linux-gnu/libmng.so.1.1.0.10
a91d9000-a91db000 r--p 0007f000 08:01 420349    /usr/lib/i386-linux-gnu/libmng.so.1.1.0.10
a91db000-a91dc000 rw-p 00081000 08:01 420349    /usr/lib/i386-linux-gnu/libmng.so.1.1.0.10
a91e2000-a91e9000 r-xp 00000000 08:01 420428    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqtiff.so
a91e9000-a91ea000 r--p 00006000 08:01 420428    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqtiff.so
a91ea000-a91eb000 rw-p 00007000 08:01 420428    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqtiff.so
a91eb000-a91ef000 r-xp 00000000 08:01 402960    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqsvg.so
a91ef000-a91f0000 ---p 00004000 08:01 402960    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqsvg.so
a91f0000-a91f1000 r--p 00004000 08:01 402960    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqsvg.so
a91f1000-a91f2000 rw-p 00005000 08:01 402960    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqsvg.so
a91f2000-a91f7000 r-xp 00000000 08:01 420436    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqmng.so
a91f7000-a91f8000 r--p 00004000 08:01 420436    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqmng.so
a91f8000-a91f9000 rw-p 00005000 08:01 420436    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqmng.so
a91f9000-a9200000 r-xp 00000000 08:01 420421    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqjpeg.so
a9200000-a9201000 r--p 00006000 08:01 420421    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqjpeg.so
a9201000-a9202000 rw-p 00007000 08:01 420421    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqjpeg.so
a9202000-a9209000 r-xp 00000000 08:01 420420    /usr/lib/i386-linux-gnu/qt4/plugins/imageformats/libqico.soAbgebrochen (Speicherabzug geschrieben)

---

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

---

Hi,

Code:

---

estang@ubuntu:~/OpenFOAM/estang-2.3.0/run/snappyMultiRegionLayerMeshing$ paraview
ERROR: In /home/opencfd/OpenFOAM/ParaView-4.1.0/VTK/IO/Geometry/vtkSTLReader.cxx, line 378
vtkSTLReader (0xb270c40): STLReader error reading file: /home/estang/OpenFOAM/estang-2.3.0/run/HP50bar_2/cad/stlFluid/inlet.stl Premature EOF while reading point.

---

Scheint der gleiche Fehler zu sein wie hier: sHM und kanten

Kannst du deine STL mal posten? Bzw. die HDF von mir (Tutorial) öffnen, eine Fläche exportieren und schauen ob du diese öffnen kannst? Wenn nicht bitte ich dich diese STL hier zu posten.

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

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

---

Ich konnte inzwischen Salome auf Ubuntu installieren und hier hatte ich das Problem nicht mehr. Es liegt also an der Windows-Version

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

---

Hallo,

könntest du mal solch eine nicht funktionierende Windows STL hier hochladen?

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

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

---

connect.zip

Natürlich, viel Spaß damit.

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

---

Danke,

kurze Frage:

• Musstest du nur die lo -> loop ändern oder
  
• war es auch nötig die Punkte neu anzuordnen? Die sind ja hier alle in einer Reihe. Sehr interessant das man mit Windows solch einen Output bekommt.
  

Danke für die Einstellung!

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

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

---

Dateien.zip

Das Problem mit lo statt loop kam erst mit 7.4. Unter 7.3 hatte ich dieses nicht. Die Punkte habe ich nicht neugeordnet. Der Absturz von Paraview ist aber auch mit STLs aus der Version 7.3 passiert.

Klappt bei dir die Vernetzung der angehängten STLs?

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

---

Ich wollte nur schauen was die Unterschiede der STL's sind.
Vernetzt hab ich damit gar nichts, werde ich auch nicht » Zeit.

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

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

---

Ich hab hier ja schon einiges gelernt aber mit snappyHexMesh und splitMeshRegion hab ich noch ein Problem.

Ich habe meine boundary patches einzeln exportiert und zusammengefügt innerhalb einer stl in der Form

solid boundary
...
endsolid
solid secondboundary
...
endsolid
...

nach dem Vernetzen stehen alle boundary patches in der Datei boundary und entsprechend stehen sie mir in paraview zur Auswahl...allerdings wird nach Auswahl nichts dargestellt. In der Datei steht zu den patches auch jeweils nFaces 0;

z.B.

Code:

---

    solid_coolant
    {
        type            wall;
        inGroups        1(wall);
        nFaces          0;
        startFace      1098581;
    }
    solid_coolant_slave
    {
        type            wall;
        inGroups        1(wall);
        nFaces          0;
        startFace      1098581;
    }

---

Nach Anwendung von splitMeshRegions -cellZones -overwrite gibt es nur noch mappedWalls zu domain0 und domain2, welche in paraview nicht anwählbar erscheinen. Anscheinend soll es auch so arbeiten, nur wie behalte ich meine Randbedingungen? Anscheinend hab ich dafür eine falsche Option im snappyHexMeshDict?

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

---

Hey,

alle RB werden dir von sHM überschrieben sofern es sich um Interfaceflächen handeln. Und das sind im normal Fall alle außer die Begrenzung des Hintergrundnetzes. Vielleicht zum Verständnis noch für dich. Nach splitMeshRegions -cellZones, bekommst du einen neuen Zeitordner mit den einzelnen Regionen. Diese musst du dann alle in constant schieben (natürlich nur die die du benötigst). Danach const*/polyMesh/ sowie alle Zeitordner löschen.

Jetzt kannst du mit paraFoam --touchAll deine Dateien erstellen, die du mit paraview laden kannst. Alternativ geht es natürlich auch mit einer standard *.foam Datei.

Die Flächennamen der Interfaces (die du in deiner STL hast), sind zwar nach dem Vernetzen verfügbar aber mit nFaces 0 nicht wirklich da. Es ist nur ein leerer Eintrag. Nach dem Splitten werden dir die Interfacefaces erstellt, d.h. die Boundarynamen erstellt. Die haben dann immer einen Namen der wie folgt aussieht:

Code:

---

cellZoneX_to_cellZoneY

---

Interessant hierzu ist auch dieser Thread, der neulich diskutiert wurde: bekomme chtMultiRegionFoam Case nicht lauffähig

Hoff das hilft dir weiter, andernfalls nochmals fragen.

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

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

---

Ok danke dir für den Hinweis auf den Thread, scheint wirklich noch für einige ein offenes Problem zu sein.
Bei dzi ist aber der Unterschied, dass er die Verbindungsfläche zerteilen will. Ich kann die gemapten Verbindungsflächen auch weiter verwenden. Den Rand zum Hintergrundnetz will ich aber unterteilen. Im flange-Tutorial scheint das zu klappen. Bei mir wird aber für das übrige Hintergrundnetz einfach eine neue domain erstellt, wahrscheinlich weil sHM bei mehreren domains nicht weiß was das Hintergrundnetz sein soll.

Die Boundaries vom Hintergrundnetz werden anscheinend nicht überschrieben. Was ist wenn ich eine Hülle aus der Solid und Fluid Region als eine einzelne domain Vernetze und das dann als Hintergrundnetz für einen weiteren Durchlauf verwende, in dem dann anschließend die Verbindungsflächen gesnapped werden? Wenn ich dann -blockedFace für meine bestehenden Randbedingungen beim splitten verwende kann ich damit meine boundaries behalten und meine beiden Regionen erhalten?

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

---

Hast mal n Bild was du machen willst?
Es kann gut sein das du mit createPatch auch mehrere STL's verwenden kannst um deine Patches zu definieren.
Musst mal schauen.

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

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

---

randbedingungen.jpg

Also die rote Fläche und die Fläche des Hohlraumes sollen feste Temperaturen bekommen und alle anderen Flächen außen die sozusagen die Luft berühren, sollen entsprechend einen festen Wert für den Wärmeübergang bekommen. Ansonsten dann noch Einlass und Auslass für das Fluid innerhalb des Rohres und Wall für die Verbindungsfläche.

Und mein Lösungsweg wäre:

• Solid und Fluid zu vereinen
  
• die Vereinigung bekommt die äußeren Randbedingungen verpasst
  
• STLs der Außenflächen exportieren zusammenfassen und als eine Domain snappen
  
• Das entstandene Mesh als Hintergrundnetz verwenden um die Verbindungsfläche zu snappen

EDIT:
mir fällt gerade ein, die Hohlraumflächen stehen als Verbindungsflächen zur domain0 oder domain2 sowieso zur Verfügung. Es geht also um die rote Fläche und der Rest würde wohl als defaultPatch ansprechbar sein

[Diese Nachricht wurde von bacengeugn am 04. Dez. 2014 editiert.]

[Diese Nachricht wurde von bacengeugn am 04. Dez. 2014 editiert.]

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

---

Das zweite snappen funktioniert nicht.

Code:

---

--> FOAM FATAL ERROR:
[2] cell 65 of level 0 does not seem to have 8 points of equal or lower level
cellPoints:8(262 265 532 41 351 352 494 495)

---

beim Shell refinement tritt das Problem auf. Ich komme mit meinem Ansatz nicht weiter.

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

---

Hallo,

das ist klar das das nicht funktioniert.
sHM arbeitet mit Quadern (Sonderform wäre hier der Würfel, das am idealsten ist). Nach deinem Snappen erzeugst du aber jede Menge anderer Zellen, die du natürlich nicht wieder in einem zweiten sHM verwenden kannst. Fragen wären:

• castellated im zweiten Schritt auch aktiv?
  
• So wie ich das jetzt verstehe möchtest du aus dem Netz (Gesamtgeometrie aus Fluid + Solid) anschließend dann nochmals sHM laufen lassen um die Regionen zu erhalten?
  
• Hast du beim zweiten mal wieder mit cellZones und faceZones gearbeitet?
  

Ist ein interessanter Ansatz und werde das mal überprüfen.
Ich werde aber erst mal meinen Ansatz mit createPatch prüfen, habe jedoch hier einiges zu tun.

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

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

---

Genau so hatte ich mir das gedacht und es hat jetzt funktioniert 

castellatedMesh hatte ich zuerst aktiv gelassen, dadurch wurde aber der Fehler verursacht wie du bereits sagtest. Ich hätte selbst gar nicht daran gedacht dass das Probleme verursacht. Zum Test hab ich das mal ausgeschaltet aber dadurch ließen sich ja keine faceZones erstellen also hab ich im ersten Durchlauf auch die FluidDomain.stl mit reingeladen und die fluidZone und fluidFaces gleich miterstellt, aber mit deM Eintrag:

multiRegionFeatureSnap false;

Die snappyHexMeshDict für den zweiten Durchlauf hat als Einträge dann

Code:

---

castellatedMesh  false;
snap              true;
addLayers        false;

geometry
{
    fluidZone
    {
        type cellZone;
        name fluid;
    }
};

snapControls
{
  ...
  multiRegionFeatureSnap true;
}

---

nach dem splitten hatte ich die beiden Regionen und meine gewünschten Randbedingungen

ich werde jetzt noch versuchen die Layer aufzubringen

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

---

Hey,

wunderbarer Ansatz! Dazu aber jetzt noch eine Frage:

• Was ist fluidZone in deiner geometry entry. Ist das die cellZone die du vorher erstellt hast?
  
• Welchen Namen trägt dein Solidbody nach dem Splitten?
  

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

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

---

Ja genau, die fluidZone ist die cellZone die ich im ersten Durchgang im refinementSurfaces-Subdictionary für die FluidDomain.stl erstellt habe.
Nach dem splitten heißt der Solidbody domain0.

[Diese Nachricht wurde von bacengeugn am 05. Dez. 2014 editiert.]

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

---

So letzte Frage die ich an dich habe:

• Du hast dein Fluid.stl und Solid.stl ohne inneren Zwischenwänden in eine STL eingefügt
  
• Du hast in dieser Domain eine CellZone erstellt (fluidZone); ergo du hast 2 STL's im ersten Schritt geladen » einmal die Gesamtgeometrie » einmal die Fluidgeometrie zur cellZone Erstellung
  
• und Ausgangspunkt war der Case den ich von dir erhalten habe, oder?
  

Sollte Punkt 1 und 2 zutreffen, könnte man direkt die CellZone für dein Solid erstellen. Hintergrund ist der, dass im Falle von drei Regionen, nur eine CellZone definiert wäre und der Rest in domain0 landen würde (d.h. zwei Regionen sind in domain0).

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

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

---

Alle drei Punkte treffen zu.

Was du vorschlägst muss möglich sein, aber wie man da dann genau vorgehen sollte weiß ich noch nicht.

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

---

Kannst du mal das sHMDict vom ersten Schritt posten?
Ich bin entweder gerade neben der Kappe oder zu müde es zu realisieren.

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

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

---

system.zip

Guten Morgen.
Ja natürlich. Ich hab mich am Wochenende nicht weiter mit dem Thema beschäftigt, darum antworte ich erst jetzt.

Ich hab beide Schritte angefügt.
Schritt 1 snappyHexMeshDict_Hull
Schritt 2 snappyHexMeshDict_Fluid

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

---

Hey,

endlich mal in Österreich n Feiertag...
Danke für die Rückmeldung. Hab gestern die faceZone vergessen, dass war alles!

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

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

---

Ist es bei dir ohne Fehler durchgelaufen? Ich habs mit anderer Geometrie erneut versucht und bekomme beim zweiten Schritt die Meldung

Unknown searchableSurface type cellZone

auch wenn ich den alten Case nochmals durchlaufen lasse

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

---

Ja es läuft durch.
Das einzige was mir auf die Schnelle einfällt wäre, dass du nicht mit "overwrite" arbeitest und du wieder das Hintergrundnetz (ohne die zuvor erstellte CellZone) verwendest.

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

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

---

Ne das wars nicht. Ich wundere mich echt was jetzt anders nicht.

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

---

Ach klar... (:
Deine Definition ist natürlich falsch

Code:

---

searchableSurface type cellZone

---

sowas gibt es nicht.
Entweder:

Code:

---

type searchableSurface;
oder
type cellZone

---

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

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