---

Hallo, liebe Forengemeinde.

Im Rahmen meiner Bachelorarbeit befasse ich mich derzeit erstmals mit OpenFOAM.
Ich habe bereits einige Tutorials erfolgreich durchgeackert und versuche mich derzeit an meinem eigenen Case.
Dieses ist ein durchströmter Körper, von dem ich die 3D-Geometrie aus SolidWorks und einige Werte am Eingang gegeben habe.
Am Ende möchte ich den Druckunterschied am Ausgang messen, und dann mit anderen Geometrien vergleichen.

Allerdings scheitere ich derzeit schon an SnappyHexMesh.
Anfangs hatte ich eine blockMesh-Box und die stl-Datei meines Bauteils und habe versucht die beiden über snappy zu vereinen. Irgendwie hatte ich es geschafft die Box mit der Außenkontur meiner Geometrie zu schneiden. Ein Fehler der beiden Koordinatensysteme, wie ich dachte.
Als ich dann aber versuchte diese anzupassen, konnte man nach ewiger Rechnerei nur noch die Box sehen, die Geometrie war entweder "unsichtbar" oder ganz weg.

Da die Außenkontur eigentlich unwichtig für meinen Fall ist, habe ich eine stl-Datei vom Fluidvolumen allein erstellt, in der Hoffnung so weiter zu kommen, oder zumindest Rechenzeit zu sparen. Die jetzige Außenkontur entspricht also meiner blockMesh-Box, ich komme jedoch nicht mehr auf meine Geometrie innen. Ich kann nicht mehr den alten Zustand mit der geschnittenen Box herstellen.

Da mir mittlerweile schon komplett der Kopf schwirrt vor lauter Koordinatensystemen, wollte ich mal fragen ob ich denn zumindest grob auf dem richtigen Weg bin.
Und weil gerade irgendwie gar nichts mehr so funktioniert wie ich mir es vorstelle, haben sich mir mehrere Fragen aufgetan:

Wo genau befindet sich eigentlich der Koordinatenursprung wirklich?
In in stl-Datei nehme ich an, dass er dort ist wo man ihn im Konstruktionsprogramm eingebaut hat. Aber befindet er sich im BlockMesh dort wo man die blockMeshDict als (0 0 0) definiert, oder evtl im Center, welches Paraview anzeigt?

Hat mein Problem evtl eine ganz andere Ursache wie zB eine verkehrte location in Mesh? Diese sollte sich nach meiner Auffassung ja dann (irgendwo?) im Fluidvolumen befinden...

Wie sollte die BlockMesh-Box überhaupt aussehen?
Genügt eine große Box, in der sich die komplette Geometrie befindet, oder benötigt man je eine Box für Einlass, Körper und Auslass?

Über konstruktive Beiträge würde ich mich riesig freuen!

Gruß,
Christoph

------------------
Gruß,
Christoph

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

---

Hallo Christoph,

• hast du dir die Mühe gemacht hier im Forum, im cfd-online.com Forum, UserGuide oder auf der Wikiseite von OpenFOAM etwas zu recherchieren?
  
• deine Geometrie lässt sich sicherlich in ein paar Minuten vernetzen, sofern die Voraussetzungen stimmen
  
• die Voraussetungen werden aber nicht stimmen - sofern du verschiedene STL's verwendest - weil ich schon mal "SolidWorks" lese
  
• Bilder für die Untermauerung deiner Probleme und einer besseren Nachvollziehbarkeit sind meines Erachtens die beste Möglichkeit
  

Du schreibst das du schon an sHM scheiterst. Da muss ich schmunzeln weil es im Prinzip die zeitintensivste Phase deiner Rechnung sein sollte.
Aus deinem Text verstehe ich leider nicht all zu viel. Du hast zwar irgendwas versucht, mir ist jedoch nicht klar was und wo im Endeffekt dein Problem ist. Ich erkenne nur das du es nicht schaffst mit sHM deine Geometrie zu vernetzen.

Beispiel:

• Wenn ich in einem Forum Hilfe bezüglich einem Zweitaktmotor suchen würde und schreibe: "Motor läuft nicht", dann kannst du dir sicher vorstellen, dass mir hierbei niemand eine konkrete Antwort geben wird (;
  
• Ähnlich ist es in deinem Fall. Zwar könnt ich jetzt alle Informationen die ich benötige aufschreiben, aber das ist nicht meine Arbeit
  
• Wenn du ein paar Threads hier durchliest, wirst du feststellen, dass das größste Problem darin besteht, dass der Threadersteller einfach keine oder unvollständige Informationen liefert oder einfach den Text so verfasst, dass es für außenstehender nicht zugänglich ist; natürlich ist es in manchen Situationen (Geheimhaltung, persönliche Gründe eigenes Wissen nicht zu teilen etc.) nicht möglich Bilder oder sonstiges vorzuzeigen aber ich denke eine Auflistung was man gemacht hat oder Ausgaben von Programmen etc. ist durchaus drin.
  

Es gibt sehr viele Wege mit sHM ein Netz zu erstellen. Der Koordinatenursprung ist relativ egal. Wichtig ist nur das das Hintergrundnetz deine Geometrie umschließt, oder teilweise einschließt (je nach dem was du vernetzt haben willst).

Ich verweise mal hierauf: Vielleicht interessant zu lesen

Hier mal meine kurze Analyse deiner Aussagen (Vermutungen, da unzureichende Infos):

Zitat:

---

Anfangs hatte ich eine blockMesh-Box und die stl-Datei meines Bauteils und habe versucht die beiden über snappy zu vereinen. Irgendwie hatte ich es geschafft die Box mit der Außenkontur meiner Geometrie zu schneiden. Ein Fehler der beiden Koordinatensysteme, wie ich dachte.
Als ich dann aber versuchte diese anzupassen, konnte man nach ewiger Rechnerei nur noch die Box sehen, die Geometrie war entweder "unsichtbar" oder ganz weg.

---

Um die Dinge klar zu stellen:

• vereinigt wird hier nichts, sondern du diskretisierst dein Kontinuum der STL Datei mit Hilfe des Hintergrundnetzes (Ausgangspunkt)
  
• ewige Rechnerei ist sehr weitläufig. Ich nehme an das deine Geometrie aus mehreren STL' Dateien besteht. Diese weisen Lücken auf (SolidWorks) und deswegen schneidet sHM die nicht benötigten Zellen nicht weg, da deine Geometrie nicht geschlossen ist.
  

Zitat:

---

Da die Außenkontur eigentlich unwichtig für meinen Fall ist, habe ich eine stl-Datei vom Fluidvolumen allein erstellt, in der Hoffnung so weiter zu kommen, oder zumindest Rechenzeit zu sparen. Die jetzige Außenkontur entspricht also meiner blockMesh-Box, ich komme jedoch nicht mehr auf meine Geometrie innen. Ich kann nicht mehr den alten Zustand mit der geschnittenen Box herstellen.

---

Dick gedruckte wäre mit einem Bild wesentlich klarer, weil das was ich gerade darunter verstehe kann nich sein. Nachfolgender Satz kann ich nicht nachvollziehen weil ich nicht weiß was du eigentlich machen willst (: --- ich weiß es schon aber aus dem Kontext ist es mir nicht zugänglich.

Dein Problem lässt sich ganz einfach Lösen, in dem du ein paar Forenthreads durchschaust die mit sHM zu tun haben, dir nochmals Gedanken machst, deine Geometrie und das Hintergrundnetz mal in Paraview betrachtest und analysierst und danach kannst du mit deinen neuen Erkenntissen deine Sache neu angehen oder du wendest dich wieder - hoffentlich dann mit mehr Informationen - ans Forum.

Wir helfen dir alle gerne - nur auf eine schlecht formulierte Fragestellung kann man natürlich auch nicht wirklich gut antworten.

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

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

---

Welche Längeneinheit hast du denn als Standard in deinem CAD-System eingestellt ?
Wenn du die STL-Dateien mit Milimeter als Längeneinheit abgespeichert hast, musst du deine Geometrie einfach um den Faktor 1000 herunterscalieren.
Das kannst du z.B. in SnappyHexmesh machen. Den Eintrag hierzu müsstest du aber mal googlen.

Gruß

Torsten

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

---

Deswegen sollte man sich das ganze erstmal in Paraview anschauen oder einfach mal checkMesh und surfaceCheck laufen lassen, damit man weiß wie die Dimensionen sind.

Mir wäre es neu, dass man in sHM skalieren kann aber man kann das auch mit:

Code:

---

surfaceTransformPoints -scale "(vector)" alte.stl skalierte.stl

---

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

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

---

So, bin jetzt wieder an meinem Rechner und habe mal den Eintrag zum Skalieren in SnappyHexMesh rausgesucht.

Hier mal ein Auszug aus einer snappyHexMeshDict, in der ich STL Dateien herunterskaliert habe.

Ist gleich am Anfang der SHMDict im Bereich geometry

...
geometry
{
    part_01_Body.stl
    {
        type triSurfaceMesh;
        scale 0.001;
        name body;
    }
...

Gruß

Torsten

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

---

Snappy.jpg

Hey, danke dass ihr euch Zeit für mein Problem genommen habt!

Ich benutze nur eine einzelne stl-Datei für die gesamte Geometrie.
Mein Hintergrundnetz ist groß genug um meine Geometrie komplett aufzunehmen. Die Skalierung (Meter / Millimeter) passt.

Ich habe heute sämtliche Dateien komplett neu geschrieben - siehe da, die Rechenzeit betrug nur ein paar wenige Augenblicke anstatt 2h+ wie vorher. Wo genau der Fehler lag, kann ich jedoch nicht sagen.

Jetzt habe ich jedoch wieder das Problem dass ich in meinem ersten Post versucht hatte zu beschreiben:
Meine Geometrie ist nur zu ca 25% im Hintergrundnetz enthalten. (siehe Bild)

Zusätzlich dazu ist im Moment noch die Umgebung vernetzt, anstatt der Körper selbst. Ich nehme an, dass das an der location in Mesh liegt, die noch nicht stimmt.
Meiner Auffassung des UserGuides nach gibt die Location irgendeinen x-beliebigen Punkt innerhalb der zu vernetzenden Geometrie an. Das heisst, wenn ich das "Innere" anstatt dem "Äußeren" vernetzen will, muss ich einen Punkt innerhalb meiner stl-Geometrie wählen. (Verbessert mich bitte, falls ich mich irren sollte...)

Mir ist jedoch noch nicht klar, wie ich diesen Punkt korrekt angeben soll, wenn die stl-Datei anscheinend willkürlich(!?) irgendwo im Gitter liegt?
Ich könnte jetzt theoretisch das Hintergrundnetz dementsprechend vergrößern, so dass es meine stl-Datei schluckt, so dass die Geometrie zumindest komplett umschlossen wird, aber das kann doch auch nicht Sinn der Sache sein, oder?

Gruß,
Christoph

------------------
...im CAD hats gepasst.

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

---

Die Geometrie liegt nie willkürlich im Netz. Ist das vielleicht ein Viertel deiner Geometrie bzw. ein Viertel der Hälfte deiner Geomrtie? Also ein achtel. Vielleicht liegt der Mittelpunkt  deiner Geometrie in 0 0 0 und du musst dein Netz in den negativen Bereich ziehen, da deine Geometrie dort liegt. Ich würde an deiner Stell mal die Max Werte in die positiven Raumrichtung auch als Werte in die negative Richtung verwenden.

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

---

Huch, du hast recht, eigentlich ists grad ein Achtel 

Der Mittelpunkt meines Netzes liegt in (0 0 0), von da aus erstreckt es sich bereits in alle Richtungen.
Und der Koordinaten-Ursprung meiner Geometrie liegt (oder lag zumindest im CAD-Programm noch) auf der Rotationsachse, also auch Mittig.
Eigentlich sollte das Netz die Geometrie umschließen, umso mehr wundert mich, dass das Teil sowohl in X, als auch in Y und Z verschoben ist.
Ich werd morgen nochmal nachsehen ob sich beim exportieren in die stl-Datei vielleicht irgendwas verändert hat, würd mich aber eher wundern...

Gibts da irgendwo eventuell einen Vektor den ich bisher übersehen habe, der die beiden Mittelpunkte / Koordinatenursprünge zueinander dafiniert?

------------------
...im CAD hats gepasst.

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

---

Frage:

Wieso erstellt man das hintergrund Netz nicht einfach, lad es und öffnet die stl Datei auch? Ist mir unklar, denn dann sieht man das sofort. Naja (;

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

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

---

Frage:

Wieso erstellt man das hintergrund Netz nicht einfach, lad es und öffnet die stl Datei auch? Ist mir unklar, denn dann sieht man das sofort. Naja (;

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

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

---

Zum Einen, weil ich nicht wusste dass das so einfach funktioniert (wieder was dazugelernt   )
und zum Anderen weil es dann anscheinend doch nicht ganz so einfach funktioniert...

Zitat:

---

ERROR: In /build/buildd/paraview-4.1.0+dfsg/VTK/IO/Geometry/vtkSTLReader.cxx, line 435
vtkSTLReader (0x3188f50): STLReader error reading file: .../constant/triSurface/fluid100.stl Premature EOF while reading solid.

*** Error in `/usr/lib/paraview/paraview': double free or corruption (!prev): 0x00000000031cb250 ***
Aborted (core dumped)

---

Einen ähnlichen Fehler hattest du wohl auch schonmal, Tobi. http://www.cfd-online.com/Forums/openfoam-paraview/124839-problems-ascii-stl.html

Ein export LC_ALL=C funktionierte leider nicht, habe aber gerade eben trotzdem die Lösung meines Problems gefunden, und möchte sie euch natürlich nicht vorenthalten, vielleicht interessierts ja mal den Einen oder Andren:

Angenommen, Solidworks speichert eine Datei Xyz.STL.
Dass man sie im OpenFOAM/ParaView ohne Probleme verwenden kann, muss man diese in xyz.stl umbennenen.
Man sollte dabei aber auch darauf achten, dass man innerhalb der ASCII-Datei die Zeile 1 solid Xyz auch zu solid xyz ändert.
SnappyHexMesh kommt zwar anscheinend damit klar, Paraview hat da aber wohl Probleme damit.

------------------
...im CAD hats gepasst.

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

---

Hallo,

das mit der Groß- und Kleinschreibung im Namen kann nicht sein. Das einzige, wenn du bereits auf meinen Thread im CFD-Forum verweist, war ein Problem im Quellcode, bzw. ein Bug. Ich hab damals den Quellcode der alten und neuen Version von Paraview durchgeschaut und hab da Unterschiede festgestellt. Welche Paraview Version verwendest du denn? Oftmals ist es besser die Precompiled Paraview Dateien zu verwenden außer du möchtest natürlich MPI oder PYTHON Support, dann musst du es natürlich selbst kompilieren (:

Zuletzt möchte ich deine Aussage revidieren und sagen: "Doch es ist wirklich so einfach" (:
Viel Erfolg weiterhin, und wenn Fragen bestehen weißt du ja wo du dich melden kannst.

PS: kannst du mal eine "nicht lesbare STL" Datei hochladen, da es so aussieht als wäre dein Reader wie damals:

Code:

---

solid
.
.
.
end

---

Ausgabe von Solidworks (und sonst auch fast allen gängigen CAD Programmen), jedoch würde ich nach deiner Fehlermeldung:

Code:

---

ERROR: In /build/buildd/paraview-4.1.0+dfsg/VTK/IO/Geometry/vtkSTLReader.cxx, line 435
vtkSTLReader (0x3188f50): STLReader error reading file: .../constant/triSurface/fluid100.stl Premature EOF while reading solid.

---

Sagen, dass du sowas brauchst:

Code:

---

solid
.
.
.
end solid

---

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

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

---

Testkugel.STL

Ich benutze Paraview 4.10, 64bit, Qt-Version 4.8.6

Du hast Recht, es liegt nicht an der Groß- und Kleinschreibung innerhalb der Datei.
Die von Solidworks ausgegebene .STL muss zwar auf .stl geändert werden, dass ParaView sie im Ordner findet, aber was vor dem "." steht kann anscheinend sowohl groß als auch klein geschrieben sein.
Die stl-Datei funktioniert bei mir aber erst dann, wenn ich sie nochmals editiert habe.
d.h ich öffne sie im gedit, und speichere sie neu.

Im Solidworks gibt es unter den übrigens Speicheroptionen eine Option STL-Ausgabedaten nicht auf positiven Raum übertragen, die den ehemaligen Ursprung in der stl-Datei beibehält. Das war mein Vektor, der die Geometrie in X, Y und Z verschoben hat...

und nein, es ist

Code:

---

solid xyz
...
endsolid

---

Eine Datei zum Testen habe ich dir angehängt.

------------------
...im CAD hats gepasst.

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

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

---

Hallo,

du hast recht, es heißt endsolid.
Aber zu deinem Problem. Es liegt nicht direkt an der Groß- oder Kleinschreibung. Die Lösung/Ursache deines Problems liegt darin (ist mir auch neu):

• Bei *.STL wirst du aufgefordert das Fileformat anzugeben (Stereolith)
  
• Wenn du dann mit "Namen in den STL" arbeitest muss es folgendermaßen aussehen:
  

  Code:

  ---

  
  solid MyName
  .
  .
  .
  endsolid MyName
  

  ---

  
  
• Fehlt der letzte Eintrag nach endsolid bekommst du deinen Fehler
  
• Nennst du die Datei *.stl, tritt dieses Problem gar nicht erst auf
  
• Warum das so ist kann ich dir grad nicht sagen aber liegt wohl am Aufruf der von mir damals schon genannten Funktion, die seit 4.0.1 (glaub ich) geändert wurde
  

Das werde ich gleich mal im CFD-Forum nachtragen.
PS: Der Fehler rührt seit 4.0.1 daher:
Unterschied zwischen 3.9 und 4.0.1 und später

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

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

---

Ich wollte eigentlich eher darauf raus, dass das "MyName" hinter dem endsolid-Befehl gar nicht mehr benötigt wird.

Die .STL-Datei, die hier reingestellt hab kam genau so aus dem Solidworks, und funktioniert im Paraview, sobald die Dateiendung .stl ist und nur einmal kurz angesehen und neu abgespeichert wurde.

Aber hauptsache es funktioniert jetzt.
Danke nochmal!

Gruß,
Christoph

------------------
...im CAD hats gepasst.

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

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

---

Hey Christoph,

es ist gut das es funktioniert und das sollte es auch, allerdings ist das eine Art Bug die ich auf Mantis melden werde.
Ist immer gut wenn solche Fehler auftreten um die Open Source Software Sachen zu verbessern.

Die Frage die sich mir gerade stellt ist, ob es ein Bug ist, oder eben nicht. Immerhin wird durch das Ändern von *.STL zu *.stl das Problem behoben. Ich schau mir das die Tage mal näher an.

Wenn dein Problem behoben ist, kannst du das  Thema als "gelöst markieren". Dann wissen alle, dass die Diskussion erfolgreich war (:

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

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