---

Bildschirmfotovom2014-11-21203257.png Bildschirmfotovom2014-11-21211029.png Bildschirmfotovom2014-11-21211059.png

Hallo Zusammen,

das Thema wurde zwar schon mehrfach besprochen, ich raff es aber einfach nicht bzw. ich krieg die grundlegenden Einstellungen nicht hin ich schaff zwar nach Stundenlagem probieren mal ein vernünftiges Netz aber mir fehlt der rote faden.Wie bekomme ich scharfe Kanten hin? Ich hab mal ein paar Bilder angefügt. Liegt es einFach an zu wenigen Zellen oder an den Einstellungen?

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

---

sHMSolid.png test.png test2.png

• Netz ist schon grob aber daran darf es nicht scheitern
  
• Einstellungen sind nFeatureSnapIter
  
• implicitFeatureSnap
  
• explicitFeatureSnap
  
• oder und je nach dem was du verwendest, features
  

Anbei mal das was ich gestern gemacht hab. Kommt von diesem Thread: chtMultiRegion mit boundary Layer

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

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

---

Mal wieder vielen Dank: hiermal meine Einstellungen:

features
    (
        {
            file "DK1.extendedFeatureEdgeMesh";
            level 2;
        }
        {
            file "D1.extendedFeatureEdgeMesh";
            level 2;
        }
        {
            file "Inlet.extendedFeatureEdgeMesh";
            level 2;
        }
        {
            file "RohrK.extendedFeatureEdgeMesh";
            level 2;
        }

und

        //- Number of feature edge snapping iterations.
        //  Leave out altogether to disable.
        nFeatureSnapIter 10;

        //- Detect (geometric) features by sampling the surface
        implicitFeatureSnap true;

        //- Use castellatedMeshControls::features
        explicitFeatureSnap false;

        //- Detect features between multiple surfaces
        //  (only for explicitFeatureSnap, default = false)
        multiRegionFeatureSnap true;

Ich habe innerhalb der surfaceFeatrueExDic immer Winkel 180 eingegeben, anch dem Motto viel hilft viel, eine gute Idee oder sollte amn das doch selektiver behandeln?

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

---

Hi,

ich muss etwas schmunzeln. Zum ersten:

Code:

---

        //- Detect (geometric) features by sampling the surface
        implicitFeatureSnap true;

        //- Use castellatedMeshControls::features
        explicitFeatureSnap false;

        //- Detect features between multiple surfaces
        //  (only for explicitFeatureSnap, default = false)
        multiRegionFeatureSnap true;

---

Fällt dir selber was auf?

• Viel unwissen bringt auch überhaupt nichts
  
• 180 ist (je nach dem wie deine STL ist) einfach nur Katastrophe (:
  
• Schau dir deine featureEdges mal an (kannst auch das eMesh nehmen) STichwort: surfaceFeatureConvert
  
• Ich weiß zwar nicht wie dein Hintergrundnetz aussieht aber nach einem Refinement level 2 sieht das bei deinen Features nicht aus (habe das aber selber noch nie probiert)
  

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

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

---

Hallo,

ein bisschen schmunzeln muss ja auch mal sein, wenn of so oft frustiert (mich zumindest). SurfaceFeatrueConvert sag mir nichts, höre ich das erste mal. Hab aber im UserGuid was gefunden was mich nich unbedingt schlauer macht. Gibt aber bestimmt viele Einträge oder ähnlich zu dem Thema. Hast du vielleicht eine Tip bzw. Link oder ne kurze Erklärung wie und was dieses Tool macht

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

---

Hi,

na klar hab ich Tipps und Infos 

Code:

---

shorty@laptop:~$ cd OpenFOAM/OpenFOAM-2.3.x/
shorty@laptop:~/OpenFOAM/OpenFOAM-2.3.x$ find -name "surfaceFeatureConvert"
./applications/utilities/surface/surfaceFeatureConvert
./platforms/linux64GccDPOpt/bin/surfaceFeatureConvert
shorty@laptop:~/OpenFOAM/OpenFOAM-2.3.x$ cd applications/utilities/surface/surfaceFeatureConvert/
shorty@laptop:~/OpenFOAM/OpenFOAM-2.3.x/applications/utilities/surface/surfaceFeatureConvert$ tree
.
|-- Make
|  |-- files
|  |-- linux64GccDPOpt
|  |  |-- dependencies
|  |  |-- dependencyFiles
|  |  |-- dontIncludeDeps
|  |  |-- files
|  |  |-- filesMacros
|  |  |-- includeDeps
|  |  |-- localObjectFiles
|  |  |-- objectFiles
|  |  |-- options
|  |  |-- sourceFiles
|  |  `-- surfaceFeatureConvert.o
|  `-- options
|-- surfaceFeatureConvert.C
`-- surfaceFeatureConvert.dep

2 directories, 15 files
shorty@laptop:~/OpenFOAM/OpenFOAM-2.3.x/applications/utilities/surface/surfaceFeatureConvert$ vim surfaceFeatureConvert.C

---

Da steht gleich am Anfang:

Code:

---

Application
    surfaceFeatureConvert

Description
    Convert between edgeMesh formats.

---

Das heißt auf gut deutsch, dass dieses Applikation edgeMesh konvertieren kann. Damit ist das scho mal geklärt. Danach einfach mal schaun was das Programm den so macht:

Code:

---

shorty@laptop:~$ surfaceFeatureConvert

Usage: surfaceFeatureConvert [OPTIONS] <inputFile> <outputFile>
options:
  -case <dir>      specify alternate case directory, default is the cwd
  -noFunctionObjects
                    do not execute functionObjects
  -scale <factor>  geometry scaling factor - default is 1
  -srcDoc          display source code in browser
  -doc              display application documentation in browser
  -help            print the usage

Convert between edgeMesh formats

Using: OpenFOAM-2.3.x (see www.OpenFOAM.org)
Build: 2.3.x-a026250b4163

--> FOAM FATAL ERROR:
Wrong number of arguments, expected 2 found 0

FOAM exiting

---

Wie man erkennen kann ist die Syntax ganz leicht:

Code:

---

Usage: surfaceFeatureConvert [OPTIONS] <inputFile> <outputFile>

---

Ergo du musst sowas machen:

Code:

---

surfaceFeatureConvert pfad/zur/eMesh.datei eMesh.obj
surfaceFeatureConvert constant/triSurface/meineSTL.eMesh eMesh.obj

---

Danach kannst du dir das mal in Paraview anschauen.

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

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

---

man kann in der surfaceFeatureExtractDict auch

Code:

---

writeObj  yes;

---

setzen.

Ich denke mal man sollte sich als erstes Datei_edgeMesh.obj angucken?

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

---

Man kann in der Datei auch noch ganz andere interessante Sachen setzen:

Code:

---

OpenFOAM-2.3.x$ vim applications/utilities/surface/surfaceFeatureExtract/

---

Ich bevorzuge den ovn mir genannten Weg, weil ich nich so viele *.obj Files erzeugen will. Aber das ist jedem selbst überlassen (:

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

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

---

Vielen Dank für die Antworten, konnte am WE leider nicht an den Computer, werde das ganze mal austesten und mich dann wieder mit unqualifitierten Fragen melden. Nochmals Danke

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

---

Hallo und nochmals danke für die Antworten, bin leider noch kein Stück weiter, mir ist aber auch nicht so ganz klar was mir das alles bringen soll. Hier noch ein paar Fragen:

1. Shor ty, wenn ich das nach deinem Schema mache, müssten dann alle meine Oberflächen in einer eMesh Datei zusammen gefügt sein?

2. Wenn ich mir jetzt extra die .obj-Dateien ausschreiben lassen, ändert dies zunächst mal nichts an meinem Ergebnisse, ich sehe nun nur die verschiedenen Edges, die Verwendung finden, oder?

3. Bedeutet das vielleicht meine Zellenzahl einfach zu gering ist?

4. Haben dies .obj Dateien einen "Zweck" oder dienen Sie "nur" zur Visualisierung, falls ihr versteht was ich meine. Oder ändern die obj Dateien was am Ergebnis oder helfen Sie nur dem Verständis durch Visualisierung?

5. Also ich hab nun mehrfach meinen Winkel innerhalb der surfaceFeatureExtract-Datei verändert, mein Ergebnis hat sich jedoch nicht geändert.

Überseh ich noch was, habe ich noch was grundlegendes Falsch gemacht, oder raff ich es einfach wieder nicht? Schönen Abend noch an alle.

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

---

Hi,

• die obj Dateien sind nur für die Visualisierung, kannst auch als VTK ausschreiben
  
• die eMesh Datei beinhaltet in deinem Fall nur drei kreise
  
• lad doch dein case mal schnell hoch
  

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

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

---

Duese.zip

Hallo, hier mal mein Case

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

---

inlet.png triangulation.png triangulation2.png

Hallo,
hätte nicht gedacht, dass so viele Dinge anzumerken sind aber:

• einen rießen Fehler (den fast alle machen und kaum jemand beachtet) ist das deine Oberflächen nicht geschlossen sind. Auf den Bildern erkennst du die Triangulation und den Zoom zu den Schnittstellen
  
• erkennbar sind die Löcher die du bekommst
  
• Mit so einem Oberflächennetz fang ich gar nicht an zu vernetzen weil das Endresultat nicht vorhersehbar ist
  
• Verfeinerst du bspw. das Netz so stark, dass sHM die Lücken erkennt, dann wirst du dich noch in 3 Monaten fragen, wieso sHM das nicht ordentlich vernetzt
  

Tipp: Immer nur die Fluidwände einbeziehen und dann alle einzelnen STL's in eine Datei setzen

Code:

---

cat * > regionSTL.stl
surfaceCheck regionSTL.stl

---

Letztes Programm checkt deine STL und gibt dir ne Message aus, ob diese geschlossen ist oder nicht. Sollte diese nicht geschlossen sein würde ich mich sehr stark um die Triangulation der Oberfläche kümmern. Siehe auch die Tutorials auf meiner Homepage.

Zu deinen featureEdges:

• Duese.eMesh beinhaltet gar keine Linien
  

  Code:

  ---

  
  Read edgeMesh "Duese.eMesh"
  points      : 0
  edges       : 0
  boundingBox : (0 0 0) (0 0 0)

  
  writing "../../duese.obj" without scaling
  points      : 0
  edges       : 0
  boundingBox : (0 0 0) (0 0 0)

  
  End
  

  ---

  
  
• keine Ahnung ob das beabsichtigt ist
  
• Deine Features vom INLET sind bereits im ROHR enthalten, allerdings sind beide FeatureEdge meshes auf Grund deiner Triangulation unterschiedlich. Was soll der Algorithmus denn jetzt tun, und auf welche Linie soll er jetzt snappen?
  
• Alle Kanten/Edges am Austritt deiner Düse liegen nicht vor, da Duese.eMesh leer ist
  
• nCellsBetweenLevels 1 === gibts nen Grund dafür?
  
• LocalCells 100000 === gibts nen Grund dafür? (ist jetzt nichts wildes aber trotzdem)
  
• resolveFeatureAngle 180 ?
  
• wieso den so viele surfaceRegions?
  
• nSmoothPatch 25?
  

Mein erster Tipp. Ändere deine Oberflächen und du wirst sehen wie glücklich man dann ist.

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

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

---

Mal wieder vielen Dank, vor allem für die investierte Zeit. Werde das ganze heute Abned mal probieren.

Das mit den verschiedenen STL`s machte ich eigentlich immer aus dem Grund, da ich dann verschiedene Regionen mit unterschiedlichen Verfeinerungsstufen versehen kann, sprich ich dachte ich bin flexibler.

Das mit Löchern ist gut zu Wissen, aber mein vorwiegendes Problem liegt am Düsenaustritt.

Das in meiner eMesh keine Angaben sind ist nich beabsichtigt, das war auch mal anders, da ich sehr viel probiert habe.

nCellsBetweenLevels 1 === gibts nen Grund dafür?
Nein ist glaube ich Standard, was hällst du hier für am besten?

LocalCells 100000 === gibts nen Grund dafür? (ist jetzt nichts wildes aber trotzdem)
Auch Standard glaube ich, was wäre dein Vorschlag?

resolveFeatureAngle 180 ?
Mein Altes Motto, viel hilft viel  .

wieso den so viele surfaceRegions?
Aus der Not heraus wollte ein wenig was probieren bzw. nur die Zonen in denen ich hohe Geschwindigkeiten erwarte wollte ich verfeinern.

nSmoothPatch 25?
Hab einfach mal was probiert, wenn ich ehrlich bin weiß ich auch nicht was das soll, bzw. habe ich auch keine Veränderungen gesehen, wenn ich diesen Wert änderte.

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

---

Hey,

die verschiedenen Flächen zu definieren ist schon gut. Wie du schon sagst, kannst du damit flexibler arbeiten ABER es gibt auch regionale STL Dateien (: Das heißt du hast die Möglichkeit in einer STL verschiedenen Regionen zu definieren und diese dann separat in sHM anzusprechen (ist meine standard Vorgehensweise). Wie du schon erwähnt hast, kann man in verschiedenen Oberflächen verschiedene Refinementstufen anwählen. Du kannst das natürlich alles mit einzelnen STL's machen aber dann hast du eben nicht die Möglichkeit es mit

Code:

---

surfaceCheck meine.stl

---

zu prüfen. Es ist also dir überlassen aber wichtig ist, dass die Übergänge von einer STL zur nächsten sitzen. D.h. eine Wire Diskretisation ist hier eine sehr gute Wahl. Soll heißen, wenn du auf der einen Kante 20 Punkte hast, sollte das bei der gegenüberliegenden STL auch der Fall sein, damit jeder Punkt die gleichen Koordinaten besitzt.

nCellsBetweenLevels musst du wissen was du möchtest. Ich verweis dich mal hierauf: snappyHexMesh Wiki, nCellsBetweenLevels

LocalCells wie schon erwähnt ist es nicht so wichtig, nur wenn du parallel rechnest. Hat keinen Einfluss auf deine Netzgenerierung.

resolveFeatureAngle ich hoffe du weißt was das für Auswirkungen hat. Wenn du bspw. für die surfaceLevels (2 3) angibst, dann wird Level 3 nur dann angewendet wenn der Winkel von resolveFeatureAngle gültig ist.

Zitat:

---

wieso den so viele surfaceRegions?
Aus der Not heraus wollte ein wenig was probieren bzw. nur die Zonen in denen ich hohe Geschwindigkeiten erwarte wollte ich verfeinern.

---

Das macht Sinn, dachte jedoch das es hier nur um die featureEdges geht. Deswegen war das meine Frage!

nSmoothPatch hat was mit deiner Oberflächen Smoothness zu tun (mir fällt tatsächlich nicht das deutsche Wort ein). Beim snappen kann man eigentlich kaum Fehler machen. Normalerweise reichen 3 - 4 hier.

Viel Erfolg.

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

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

---

Vielen Dank,

werde das ganze jetzt mal ein wenig testen. Und mich dann wieder melden.

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

---

Hallo, mal noch kurz zwei Fragen zwischendurch,

"LocalCells wie schon erwähnt ist es nicht so wichtig, nur wenn du parallel rechnest. Hat keinen Einfluss auf deine Netzgenerierung."

gilt dies für parallele rechnen, also das rechnen auf mehreren Kerne oder die Netzerstellung. Weil natürlich möchte ich später auf verschiedenen Kerne rechnen. Sollte doch eigentlich nur für die Netzgenerierung von Interesse sein, da sHM ja nicht auf meine Berechnung Einfluss hat, oder?

Kennst du eine guten Link bzw. einen Forumseintrag in dem Paralleles Vernetzen beschrieben wird, ich hab jetzt schon mehrfach gesucht aber nix gefunden.

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

---

Hallo,

• Wie bereits in der Datei geschrieben wird, wird nach überschreiten dieser Zahl die Balance mit dem Gewichtungsfaktor zwischen den Prozessoren getätigt
  
• Diese Einstellung ist nur für das Vernetzen, also sHM, zutreffend
  
• Paralleles Vernetzen ist wie parallels Ausführen eines jeden Programms:
  

  Code:

  ---

  
  decomposePar
  mpirun -np x snappyHexMesh -parallel [-overwrite]
  reconstructParMesh -mergeTol 1e-6  [-latestTime]
  

  ---

  
  
• Die in Klammern gesetzten Argumente sind optional
  

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

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

---

Duese.png

Hab das ganze jetzt mal hinbekommen und denke die Kanten schauen auch ganz gut aus. Hätte jetzt aber mal noch eine Frage:

Shorty du hast geschrieben, ich sollte eine STL-oberfläche erstellen um Fehler bzw. Löcher zwischen den einzelnen, STL zu vermeiden, hört sich sehr sinnvoll an. Ich würde das ganze jetzt einfach  innerhalb Salome machen oder gibt es dort bessere Vorgehensweisen? Eine andere Frage wäre nun: ich würde gerne meine Flexibilität behalten. Kann ich irgendwie die Oberflächen ausschreiben oder definieren um dann nur  bestimmte Oberflächen zu verfeineren?

In dem anderen Beitrag hast du was von Diffusor geschrieben, hast du den einphasig oder mehrphasig simuliert?

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

---

Hey,

• Salome ist meine erste Wahl für die Triangulation von Oberflächen
  
• Du kannst deine Flexibilität beibehalten in dem du jede Oberfläche extra vernetzt und dann exportierst. Danach musst du nur in die erste Zeile dieser STL Datei einen Namen angeben und abspeichern. Das machst du mit allen und kopierst einfach alle zusammen. Entsprechend hast du dann eine STL mit Regionen, die du in sHM einzeln ansprechen kannst. Jede Region ist danach auch eine Boundary
  
• Für die Namensgebung und das zusammenkopieren kannst du dir auch ein simples bash-Skript machen, das erspart imensen Arbeitsaufwand wenn du mehrere Regionen hast (bspw. bei 20 möchte ich das nicht manuell machen)
  
• Den Diffusor habe ich Einphasig berechnet (Fluid war Wasser)
  

Deine Geometrie sieht übrigens jetzt gut aus  
Kannst ja demnach den Thread als gelöst markieren und Unities vergeben sofern du magst.

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

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

---

Das mit Salome hab ich nicht so recht verstanden. Du meinst man sollte in Salome vernetzen? und dann erst exportieren? Ich hab bis jetzt immer nur mit sHM vernetzt? Oder hab ich das was falsch verstanden, gibt es dazu irgendwo Beispiel oder Tuotrien?

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

---

Ja du hast was falsch verstanden. In salome vernetzt du deine Oberfläche (STL) Files. Ist ja nichts anderes als eine Triangulation der Oberfläche. Wenn du dir meine tutorials anschaust und ml die STL Files lädst, die Triangulation betrachtest und ggg noch die normalen Vektoren anzeigen lässt und das mit den stl von CAD Programmen vergleichst, fällt dir sicher was auf

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

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