OF - Tutorials (FEM / Genormte Berechnungen/OpenFOAM)

Hallo Kollegen,

wie ich finde, braucht das Forum noch einen Thema über die installieren Tutorials von OF. Da ich persönlich gerade dabei bin mich einzuarbeiten, stellen sich mir oft viele Fragen. Und für jede einzelne Frage ein Thema zu erstellen, wäre aus meiner Sicht unnötig. Jeder kann hier natürlich seine Fragen stellen. Der Mod kann dies aber gerne ändern.

Ich habe gestern versucht wieder weiter Tutorials zu machen. Zu meinen Fragen:

1. Manche Tutorials haben kein blockMeshDict-Datei. zB http://repo.or.cz/w/OpenFOAM-2.0.x.git/tree/master:/tutorials/basic/laplacianFoam/flange

Darin ist eine Datei "flange.ans". Wie lese ich denn diese Datei ein? Es gibt hier und da mal eine *.gz oder das "engine"-Tutorial hat eine otape17-Datei. Wie lade ich diese Dateien?

2.1 Ich habe versucht, das "potentialFoam"-Tutorial zum Laufen zu bringen. Wie im blockMeshDict zu sehen, soll eine *.H-Datei geladen werden. Wenn ich blockMesh eintippe, kommt aber eine Fehlermeldung dass eine Datei nicht gefunden werden konnte. Wie ist das Netz zu laden?

http://repo.or.cz/w/OpenFOAM-2.0.x.git/tree/master:/tutorials/basic/potentialFoam/cylinder/constant/polyMesh

2.2 Das "potentialFoam"-Tutorial hat einen 0.org-Ordner. Warum das *.org und muss das einfach umbenannt werden?

http://repo.or.cz/w/OpenFOAM-2.0.x.git/tree/master:/tutorials/basic/potentialFoam/cylinder

Das wäre es vorerst. Weitere "dumme" Fragen folgen bestimmt!

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

Hi Ay,

bei Deiner Frage mit der *.ans-Datei muss ich passen.

*.gz Dateien sind gnuzip-gepackte Dateien. (kurz *.gz)
Dort werden die Leute, die die jeweiligen Tutorials erstellt haben, irgendwelche Infos gepackt haben.
Habe einige Geometrien im triSurface-Ordner bei sHM-Tutorials gesehen, kann sein, dass sHM sogar mit gepackten STL's umgehen kann?!

Das mit dem 0.org hast Du richtig verstanden, der muss einfach umbenannt werden ... org steht da vermutlich für "Original".
In vielen Tutorials ist zu beobachten, dass wenn das "Allrun"-Skript ausgeführt wird, er einen Startordner 0 aus dem 0.org herauskopiert.

Hoffe, dass das vielleicht etwas weiterhilft.

Viele Grüße!

[Diese Nachricht wurde von bartholomew83 am 22. Feb. 2013 editiert.]

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

Hab gerade mal google angeworfen.

.ans-Dateien sind Daten aus ANSYS. Kein Wunder, dass ich die noch nicht kannte. Mit Ansys habe ich selbst noch nicht gearbeitet.
Sind vermutlich Daten aus Fluent oder so ...

Denke da werden Dir andere mehr zu sagen können.

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

Aaaah ein guter Tipp! Wahrscheinlich muss man erst mal diese AllRun und AllClear Dateien ausführen, damit man die Befehle blockMesh und potentialFoam ausführen kann bzw. AllRun macht dann alles bereits für mich. Kann das jetz nur nicht testen, da ich in der Arbeit bin.

Habe mich mal durchgeklickt. In den AllRun's stehen weitere Befehlen, die wohl Dateien wie *.ans *.gz oder otape17(?) umwandeln für oF.

Naja... habe ich mich mal lächerlich gemacht

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

Hi,

im AllRun script sind alle Befehle die du brauchst. Wie schon erwähnt wurde, ist das ein ANSYS Format. Ich persönlich habe immer ein *.unv Foramt, dass ich konvertiere.

Um Mesh-Conversation einzusehen stehen im User Guide viele Befehle, die dir aufzeigen, wie du mit welchem Befehl bestimmte Datenformate in OF konforme Datensätze überführst

Komprimierte Dateien:
In deiner ControlDict kannst du "file format compressed" oder so eingeben. Je nach dem was du stehen hast, werden alle Dateien gezippt um Speicher zu sparen. Somit kann OF auch mit gz Daten umgehen.

Wurde aber wie gesagt ja schon alles erwähnt.

------------------
Grüße Tobias Holzmann

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

Ok super, Danke für die Antworten.

Könnt ihr mir noch ein Tool zum Erzeugung von Netzen empfehlen? Ich hätte Zugang zu ANSA, aber es sollte eine Freeware-Software sein.

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

-> snappyHexMesh
-> Salome

------------------
Grüße Tobias Holzmann

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

Danke!

@Shor-ty und andere Erfahrene:

Wie läuft bei euch der Aufbauablauf ab? Welche Programme benutzt ihr? Benutzt ihr eine GUI für OF wie zB Helyx oder Discretizer? Dann schieß ich mich während den Tutorials schon mal auch auf diese Programme ein.

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

Hi,

mein Ablauf für meine Projekte sieht bislang wie folgt aus:

1. Was kann ich interessantes Simulieren/Welche physikalischen Effekte möchte ich gern berechnen
2. Geometrieerstellung mit Salome Meca (Open Source)
3. STL Generierung und Zerlegung der Geometrie für snappyHexMesh
4. Hintergrunderstellen (Salome Meca)
5. Vernetzen (OpenFOAM - snappyHexMesh)
6. Setup
7. Simulation
8. Auswerten mit Paraview
- - - - - - - - - - - - - - - - - - - -
Optional:
9. Grafiken mit gnuplot (Diagramme etc)
10. Dokumentation via LaTeX

Grafische Oberflächen sind nur Salome und Paraview.
Die GUI für OpenFOAM ist mein Terminal. Fühl mich da sehr wohl und wenn man sich mit diversen Befehlen und Skriptsprachen auskennt, ist man seh sehr schnell.

------------------
Grüße Tobias Holzmann

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

Und wie sieht es mit dem Betriebssystem aus? Habt ihr Ubuntu direkt auf eine Partition installiert oder läuft das über eine VM eigentlich genauso gut?

Ich hab bei parafoam immer eine Meldung bekommen, dass die 3D-Einstellung nicht aktiviert ist. Dann habe ich über vm korrigiert und auch an anderen Einstellung rumgespielt damit Ubuntu mehr RAM und cpu-Leistung abbekommt. Aber dann wurde Ubuntu richtig langsam und jetzt startet es garnicht mehr. Ich habe es wohl zerschossen.

Wie macht ihr das?

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

Hi,

Ubuntu läuft afu meinem Rechner auf ner eigenen HDD.

------------------
Grüße Tobias Holzmann

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

Ja werde ich wohl über kurz oder lang auch machen müssen. Denn VM kann nicht die volle Leistung des Rechners abrufen.

So und jetzt wieder eine Frage zu den Tutorials. Ich habe mir die Codes der einzelnen Solver angeschaut und bin nun beim Verständnis nun deutlich weiter. An einer Sache bin ich hängengeblieben. Im Tutorial zu "laplacianFoam" steht im Code "createField.H":

00017 Info<< "Reading transportProperties\n" << endl;
00018
00019 IOdictionary transportProperties
00020 (
00021 IOobject
00022 (
00023 "transportProperties",
00024 runTime.constant(),
00025 mesh,
00026 IOobject::MUST_READ_IF_MODIFIED,
00027 IOobject::NO_WRITE
00028 )
00029 );
00030

Was ist das eigentlich für eine (Transport-) Konstante? Denn sie taucht im Code "laplacianFoam.C" nicht auf:

00056 {
00057 solve
00058 (
00059 fvm::ddt(T) - fvm::laplacian(DT, T)
00060 );
00061 }

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

Du kannst auch einfach eine native Ubuntu-Installation neben Windows installieren. Das geht relativ einfach.
Beim Systemstart wählt man über den GRUB-Bootloader einfach das zu startende Betriebssystem aus.

Ist zwar nicht das Optimum, aber wenn man mal während einer Rechnung auf Windows zurückgreifen muss, dann bleibt noch das Laptop oder der 2.Rechner ..etc. etc.

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

Hi,

du meinst die Konstante DT ?

Diese ist d efinitiv im Solvercode vorhanden. Du kannst DT in den transportProperties eingeben. Du hast nämlich in diesem Solver nur den Transport durch Konvektion, nicht aber durch Diffusion. Den Diffusionskoeffizienten kannst du dann vorgeben - insofern du ihn kennst.

-> DT unter createFields als skalare Größe definiert.

------------------
Grüße Tobias Holzmann

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

Ich poste mal das Ganze:

Code:
createFields.H
00001    Info<< "Reading field T\n" << endl;
00002
00003    volScalarField T
00004    (
00005    IOobject
00006    (
00007    "T",
00008    runTime.timeName(),
00009    mesh,
00010    IOobject::MUST_READ,
00011    IOobject::AUTO_WRITE
00012    ),
00013    mesh
00014    );
00015
00016
00017    Info<< "Reading transportProperties\n" << endl;
00018
00019    IOdictionary transportProperties
00020    (
00021    IOobject
00022    (
00023    "transportProperties",
00024    runTime.constant(),
00025    mesh,
00026    IOobject::MUST_READ_IF_MODIFIED,
00027    IOobject::NO_WRITE
00028    )
00029    );
00030
00031
00032    Info<< "Reading diffusivity DT\n" << endl;
00033
00034    dimensionedScalar DT
00035    (
00036    transportProperties.lookup("DT")
00037    );
laplacianFoam.C
00030 \*---------------------------------------------------------------------------*/
00031
00032 #include "fvCFD.H"
00033 #include "simpleControl.H"
00034
00035 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
00036
00037 int main(int argc, char *argv[])
00038 {
00039    #include "setRootCase.H"
00040
00041    #include "createTime.H"
00042    #include "createMesh.H"
00043    #include "createFields.H"
00044
00045    simpleControl simple(mesh);
00046
00047    // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
00048
00049    Info<< "\nCalculating temperature distribution\n" << endl;
00050
00051    while (simple.loop())
00052    {
00053    Info<< "Time = " << runTime.timeName() << nl << endl;
00054
00055    while (simple.correctNonOrthogonal())
00056    {
00057    solve
00058    (
00059    fvm::Dnobiggrin:t(T) - fvm::laplacian(DT, T)
00060    );
00061    }
00062
00063    #include "write.H"
00064
00065    Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s"
00066    << " ClockTime = " << runTime.elapsedClockTime() << " s"
00067    << nl << endl;
00068    }
00069
00070    Info<< "End\n" << endl;
00071
00072    return 0;
00073 }
00074
00075
00076 // ************************************************************************* //

DT wird im createField ab Zeile 00032 definiert, das meine ich aber nicht. Davor ist mein beschriebenes Problem. Ist es einfach eine Definition, wonach "transportProperties" im Modell vorhanden sind? Ein File namens "transportProperties" befindet sich ja dann im Modell im Ordner "constant".

Editiert von Shor-ty: Codetags hinzugefügt.

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

Hi,

du musst ja OF sagen, dass die Datei vorhanden ist. Das machst du ja zuvor, damit du Einträge aus der Datei lesen kannst.

Code:

transportProperties.lookup("DT")

PS: mit Code Tags alles einfacher zu lesen.

------------------
Grüße Tobias Holzmann

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

Also ich versuch mich ja durch die Codes einen Überblick zu schaffen und das war in den "Basic"-Tutorials auch recht einfach. Da gabs nur 1-2 Gleichungen, einige Parameter und das wars.

Aber jetzt versuch ich mich durch die Solver wie interFoam, chtMultiRegionFoam und sonicFoam zu quälen, aber das ist ja echt schwer den Überblick zu behalten, weil es so viele Includes gibt. Und natürlich viele Gleichungen und zig Parameter.

zB. cht: Die Geometrie und das Netz zu bauen, ist ja kein Problem, aber wie gehe ich am Besten heran, und schreibe das Tutorial-Beispiel so um, dass es mein Problem löst? Muss ich einfach nur ins blockMeshDict rein oder bedarf es da einfach an viel mehr Aufwand?

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

Hallo Ay,

ich möchte hier nicht unhöflich werden!

Aber brems Dich erstmal! Du willst in kurzer Zeit einfach zuviel.
Etwas einfach nur auf die schnelle nachzuvollziehen ist etwas anderes, als es zu verstehen.
Gerade bei der schlechten Dokumentation von OF ist Letzteres sehr wichtig. Von daher gilt: Einfach halten und Step-by-Step....

Zum Thema:
Die blockMeshDict beinhaltet Daten in Form von Koordinaten, sowie dem definieren von Randbedingungen (Wände, Inlets, Outlets, etc.) für das Tool "blockMesh" zur Netzgenerierung.
Entweder für Deine Geometrie (wobei sich hier "blockMesh" nur für einfache Fälle eignet) oder für ein Hintergrundnetz für sHM, wenn man dieses nicht mit Salome erstellt.

Die blockMeshDict als solches hat mit den Gleichungen in Deinen angeführten Solvern erstmal nichts zu tun.
Ob nun ein Netz aus sHM, Salome oder aus einem konvertierten Ansysformat kommt, ist bei eingehaltenem Aufbau (unabhängig von der Qualität) erstmal egal.

--------
Nochmal Edith:
Wenn Dein Fall sehr dem aus dem Tutorial ähnelt, kann es schon reichen, nur die Geometrie und vielleicht 2-3 Parameter anzupassen.

--------

Zu den Solvern kann man sagen, dass diese drei sehr verschiedene Dinge bearbeiten. Einmal eine Zweiphasenströmung, einmal ein Wärmeübertragungsproblem (Fluid-Solid-Fluid bspw.) und einmal eine Überschallströmung.
Daher ordne Deinem Problem erstmal dem naheliegensten zu. Wenn Dein Fall nichts mit Wärmeübertragung zu tun hat, wozu dann mit chtMultiRegionFoam das Leben schwer machen?
Was ich damit sagen möchte ist, dass Du Dich lieber von der "ingenieurtechnischen" Seite näher solltest.

Ich behaupte mich mittlerweile einigermaßen mit OpenFOAM zurechtzufinden.
Allerdings wäre für mich der chtMultiFoam z.B. wieder Neuland. Auch wenn der Einstieg mit der vorhandenen Erfahrung natürlich leichter fällt...
Jedenfalls hat man bei OF die ganze Zeit das Gefühl ein "Newbie" zu sein

Viele Grüße & weiterhin viel Erfolg!

Edith: Vielleicht verwirrt "einen Überblick" schaffen nur. Ich habe bisher mit OF die Erfahrung gemacht, dass es vielleicht besser sein könnte, einige Puzzleteile besser zu verstehen bevor man das ganze Bild sieht.
Dafür ist (gerade am Anfang) diese ganze OF-terminalbasierte Grütze zu abstrakt
Naja, gute Nacht!

[Diese Nachricht wurde von bartholomew83 am 25. Feb. 2013 editiert.]

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

Zitat:
Original erstellt von bartholomew83:
Jedenfalls hat man bei OF die ganze Zeit das Gefühl ein "Newbie" zu sein

Wirklich? Ich glaub du kannst schon sehr gut mit OF umgehen

Zitat:
Original erstellt von bartholomew83:
Dafür ist (gerade am Anfang) diese ganze OF-terminalbasierte Grütze zu abstrakt
Naja, gute Nacht!

Das kommt auf den Benutzer drauf an.
Ich mag das Terminal von anfang an

------------------
Grüße Tobias Holzmann

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

@bartholomew83

Die Fragerei kommt auch deswegen weil ich im Moment mehr Zeit habe zu lesen als am Rechner zu üben. Mittlerweile verstehe ich den Aufbau, jedoch sind die Details deutlich schwieriger zu verstehen. Und ein C++-Kenner bin ich nun auch nicht. Aber ich möchte nun mal auch gerne wissen, wie welcher Parameter wo definiert ist. Und da ist das User Guide doch nicht gerade hilfreich. Die C++-Doku ist mal die Unübersicht pur. Nichtsdestotrotz, mein erster großer Schritt wird es sein, mein Netz in ein bestehendes Tutorial (sonicFoam) einzubauen.

Achja, es geht mir ausschließlich um Wärmeübertragung.

Naja, ich weiß Bescheid. Danke für die Hilfen!

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

Wenn es nur um WÜ geht dann empfehle ich den chtMultiRegionSimpleFoam Solver.
Bzgl. Dokumentation gibts den Programmers-Guide (müsst mal schaun wo das zu finden ist) und Doxygen (falls dir das was sagt).

Solver für FSI findest du auf der OF-ext version (glaub ich). Zumindest wurde das mal in einem Stammtisch gesprochen.

------------------
Grüße Tobias Holzmann

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

Noch eine kurze Frage. Ich will Ubuntu auf eine eigene Partition installieren.

1. Frage: Würdet ihr Ubuntu empfehlen oder eine andere Software?
2. Frage: Wieviel Speicherplatz brauche ich für Linux+OF?

Ich würde dies ausschließlich für OF benutzen.

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

Ich habe in der Arbeit damals Open Suse verwendet was auch okay war. Persönlich bin ich mit Ubuntu sehr zufrieden.

Was Ubuntu brauchst kann ich dir nicht sagen. OpenFOAM braucht bei mir mit den ThirdPartys 1,2 GB.

Allerdings sind das die kleinsten Sachen. Einige Projekte von mir haben mehrere 100 GB. (depends on your numerical mesh)

------------------
Grüße Tobias Holzmann

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

Ich habe in der Arbeit damals Open Suse verwendet was auch okay war. Persönlich bin ich mit Ubuntu sehr zufrieden.

Was Ubuntu brauchst kann ich dir nicht sagen. OpenFOAM braucht bei mir mit den ThirdPartys 1,2 GB.

Allerdings sind das die kleinsten Sachen. Einige Projekte von mir haben mehrere 100 GB. (depends on your numerical mesh)

Bei mir ist Linux auch nur für CFD ausgelegt.

------------------
Grüße Tobias Holzmann

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

Und die 32- oder 64-bit Version?

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

Das ist natürlich von deiner Rechnerarchitektur abhängig.

Allgemein kannst du mit 32-bit maximal 3,2 GB Arbeitsspeicher verwenden, bei 64-bit eben wesentlich mehr (ist für CFD wichtig).

Ich habe überall nur 64-bit laufen, da ich 32 GB Arbeitsspeicher habe.

------------------
Grüße Tobias Holzmann

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

Momentan habe ich nur 4GB. Da lässt sich mit meinem Rechner aber auch Ruckzuck auf 32 GB aufrüsten. Ich habe daneben noch einen i5-3470k und eine relativ gute Mainboard.

Ich werde 64 bit installieren und dementsprechend noch aufrüsten. Virtual Machine ist mir echt auf die Nerven gegangen.

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

4 GB reichen auch schon aus.

Es kommt immer auf dein Netz drauf an und wie du vernetzt. Da sHM immer zwei Netze speichert sobald etwas geändert wird (um rückwirkend wieder die Ausgangszellen zu erzeugen), braucht das doppelt so viel als andere Vernetzer.

Normale Simulationen brauchen bei mir 1 - 8 GB Speicher.

------------------
Grüße Tobias Holzmann

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

Zitat:
Original erstellt von Shor-ty:
Hi,

mein Ablauf für meine Projekte sieht bislang wie folgt aus:
1. Was kann ich interessantes Simulieren/Welche physikalischen Effekte möchte ich gern berechnen
2. Geometrieerstellung mit Salome Meca (Open Source)
3. STL Generierung und Zerlegung der Geometrie für snappyHexMesh
4. Hintergrunderstellen (Salome Meca)
5. Vernetzen (OpenFOAM - snappyHexMesh)
6. Setup
7. Simulation
8. Auswerten mit Paraview
- - - - - - - - - - - - - - - - - - - -
Optional:
9. Grafiken mit gnuplot (Diagramme etc)
10. Dokumentation via LaTeX

Grafische Oberflächen sind nur Salome und Paraview.
Die GUI für OpenFOAM ist mein Terminal. Fühl mich da sehr wohl und wenn man sich mit diversen Befehlen und Skriptsprachen auskennt, ist man seh sehr schnell.

Hi,

nach langer Zeit habe ich mich in den letzten Tagen wieder mit OF befasst. Aktuell hänge ich einfach an dem oben fettgedruckten. Ich habe mir Salome installiert und schon mal bisschen rumgespielt. Jetzt hätte ich paar Fragen:

1. Salome kann man doch auch zum Netzgenerieren benutzen. Wieso machst du das nicht? SnappyHexMesh nutzt man nur für Quasi-2D-Probleme, oder?
2. Was genau bedeutet eigentlich Punkt 3 und 4?
3. Sagen wir mal ich habe mein Netz erzeugt. Wie fasse ich Faces zusammen? zB. Wall, Inlet, Outlet, etc. Ich meine jetzt nicht Punkt 5, sondern dass ich im Setup zB sage "Face 1 ist der Einlass" etc.

Schon mal Danke!

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

Hi Ay,

frohe Ostern!

zu 1.:
Ja man kann auch mit Salome vernetzen. Gerade wenn Du einfach nur unstrukturierte Netze machen willst, kann man das gut nehmen.
Allerdings muckt Salome bei Hexaeder-Netzen gern mal rum.
sHM ist da einfach schneller und einfacher ... auch gerade was Layer-Generierung betrifft. sHM ist in erster Linie für 3D-Fälle.
Für einfache 2D-Geometrien würde ich blockMesh empfehlen. Oder halt direkt Salome, wobei die Zellenanzahl in einer Raumrichtung nur 1 sein darf.

zu 2.
-> STL ist ein Datei-Format in dem alle Daten für eine Geometrie gespeichert werden. Wenn man die Geometrie in Salome gebastelt hat, kann man diese als STL exportieren.
sHM benötigt für die Netzgenerierung die Geometrie als STL-Format.

-> Ein Hintergrundnetz braucht sHM für die Erzeugung eines Netzes aus einer STL. In dieses Netz legt sHM die STL rein. Das Hintergrundnetz bestimmt hauptsächlich die Netzauflösung (unabhängig vom Refinement).
Als Anwender kann man festlegen, ob Du ein Netz "innerhalb" oder "außerhalb" der STL haben willst. So können 1. z.B. Strömungen in Bauteilen simuliert werden, oder 2. Körperumströmungen (Motorräder z.b.)

Auf shorty's alter Internetseite gab es dazu irgendwo mal von einem Entwickler ein paar gute sHM-Slides, wie es genau funktioniert.
Auf der neuen finde ich's grad nicht. Vielleicht kann er da weiterhelfen.

zu 3.
Du kannst in Salome Deine "Faces" definieren, das geht über "Create"-Group.
Diesen Faces kannst Du dann Namen geben und mit als STL für sHM exportieren.
Diese tauchen dann auch bei sHM wieder auf.
Sollte mal eine Fläche die falsche Boundary haben, kannst Du im polyMesh unter "boundary" den Flächen noch andere Randbedingungen geben.

Hoffe, das hilft erstmal ein wenig weiter!
Viele Grüße!

[Diese Nachricht wurde von bartholomew83 am 01. Apr. 2013 editiert.]

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

Zitat:
Original erstellt von bartholomew83:
Hi Ay,
frohe Ostern!
zu 1.:
Ja man kann auch mit Salome vernetzen. Gerade wenn Du einfach nur unstrukturierte Netze machen willst, kann man das gut nehmen.
Allerdings muckt Salome bei Hexaeder-Netzen gern mal rum.

Ergänzend: Salome kann -- wie erwähnt -- auch Hexaeder vernetzen, jedoch würde ich "rum meckern" nicht sagen. Für die Generierung für Hexaederzellen benötigt man immer ein Face mit vier Flächen. Für 3D entsprechend ein Quadrat bzw. ein Hexaeder (6 Seitenflächen). Somit kann bspw. kein Kreis ohne entsprechende Vorbereitung aus Hexaedern erzeugt werden (vgl. ANSYS-ICEM).

Zitat:

sHM ist da einfach schneller und einfacher ... auch gerade was Layer-Generierung betrifft. sHM ist in erster Linie für 3D-Fälle.
Für einfache 2D-Geometrien würde ich blockMesh empfehlen. Oder halt direkt Salome, wobei die Zellenanzahl in einer Raumrichtung nur 1 sein darf.

SnappyHexMesh ist überhaupt nicht für 2D Simulationen geeigenet. Es ist ein 3D-hexadominater Vernetzer, der wie schon erwähnt, einfach und gut ist.

-> ich frag mich immer wieso alle Welt denkt, dass sHM ein 2D Vernetzer ist :D

Zitat:

zu 2.
-> STL ist ein Datei-Format in dem alle Daten für eine Geometrie gespeichert werden. Wenn man die Geometrie in Salome gebastelt hat, kann man diese als STL exportieren.
sHM benötigt für die Netzgenerierung die Geometrie als STL-Format.

Es können auch *.obj Dateien verwendet werden.

Zitat:

-> Ein Hintergrundnetz braucht sHM für die Erzeugung eines Netzes aus einer STL. In dieses Netz legt sHM die STL rein. Das Hintergrundnetz bestimmt hauptsächlich die Netzauflösung (unabhängig vom Refinement).
Als Anwender kann man festlegen, ob Du ein Netz "innerhalb" oder "außerhalb" der STL haben willst. So können 1. z.B. Strömungen in Bauteilen simuliert werden, oder 2. Körperumströmungen (Motorräder z.b.)

Das Hintergrundnetz muss die Geometrie komplett (oder ab und zu nur teilweise) umschließen. Das Koordinatensystem muss passen. Soll heißen, dass du dein Hintergrundnetz nicht irgendwo plazieren kannst. sHM legt die Geometrie NICHT in das Hintergrundnetz. Wenn dein Backgroundmesh im Ursprung seinen Schwerpunkt hat und 10x10x10 cm beträgt, deine Geometrie aber irgendwo nen Meter davon entfernt ist, wird nichts funktionieren.

Weitere Infos im UserGuide.

Zitat:

Auf shorty's alter Internetseite gab es dazu irgendwo mal von einem Entwickler ein paar gute sHM-Slides, wie es genau funktioniert.
Auf der neuen finde ich's grad nicht. Vielleicht kann er da weiterhelfen.

Dankeschön für die Information :)
Werde ich morgen gleich mal einbauen und hier wieder posten.

Zitat:

zu 3.
Du kannst in Salome Deine "Faces" definieren, das geht über "Create"-Group.
Diesen Faces kannst Du dann Namen geben und mit als STL für sHM exportieren.
Diese tauchen dann auch bei sHM wieder auf.

Ergänzung: Du kannst jede STL dann einzeln in sHM importieren, oder aber eine STL aus deinen anderen zusammenbauen. Damit kannst du dann mit Regionen arbeiten (ist mein präferiertes Vorgehen)

Zitat:

Sollte mal eine Fläche die falsche Boundary haben, kannst Du im polyMesh unter "boundary" den Flächen noch andere Randbedingungen geben.

Mittels createPatch -overwrite kannst du auch gleich noch alle BC mit Faceanzahl = 0 löschen
[Diese Nachricht wurde von bartholomew83 am 01. Apr. 2013 editiert.]

------------------
Grüße Tobias Holzmann

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

Für die Präsentation:

www.holzmann-cfd.de/

-> Simulation / Vernetzung /

------------------
Grüße Tobias Holzmann

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

Sehr gut!
Mit den Ergänzungen und den Slides steht dem Vernetzen mit sHM ja fast nichts mehr im Weg!

Außer vielleicht der Wuptität?!

Zitat:
Das Hintergrundnetz muss die Geometrie komplett (oder ab und zu nur teilweise) umschließen. Das Koordinatensystem muss passen. Soll heißen, dass du dein Hintergrundnetz nicht irgendwo plazieren kannst. sHM legt die Geometrie NICHT in das Hintergrundnetz. Wenn dein Backgroundmesh im Ursprung seinen Schwerpunkt hat und 10x10x10 cm beträgt, deine Geometrie aber irgendwo nen Meter davon entfernt ist, wird nichts funktionieren.

Ja das stimmt, habe mich da ein wenig falsch ausgedrückt. Wollte halt nur nicht so sehr ins Detail.
Als weiterer Hinweis: Kommen Hintergrundnetz und STL aus Salome und wird der Ursprung benutzt, gibt es die wenigsten Komplikationen.
Hatte, wie einige andere auch, das Problem, dass mir z.B. Blender den Ursprung der STL verschoben hat, und dass es nicht passte.

Naja, noch einen schönen Restfeiertag!

Gruß

[Diese Nachricht wurde von bartholomew83 am 01. Apr. 2013 editiert.]

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

Zitat:
Original erstellt von bartholomew83:
S
Hatte, wie einige andere auch, das Problem, dass mir z.B. Blender den Ursprung der STL verschoben hat, und dass es nicht passte.
[Diese Nachricht wurde von bartholomew83 am 01. Apr. 2013 editiert.]

Via Geomtry to Origin (während der Originpunkt auf 0 0 0 steht) ist das wieder kein Problem

------------------
Grüße Tobias Holzmann

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

Hi Leute,

also erst mal vielen Dank für die ausführlichen Antworten! Dass ihr euch so viel Zeit nimmt und einen so unterstützt, einfach Hammer! Danke!

Also ich habe eure Tipps gestern mal versucht umzusetzen. Und mir die Brückensimulation von Shorty's Seite runtergeladen und genauer angeschaut.

Was mir eigentlich direkt aufgefallen ist. Ihr hattet geschrieben, ich kann die ganzen Faces bereits beim STL-File definieren und rausschreiben. Aber Salome hat mir die Faces garnicht rausgeschrieben. In der Brückensimulation sind die Faces auch nicht im STL definiert, sondern im UNV.

Und was ich auch komisch fand. In Salome habe ich unter "Geometry" mir einen Quader gebastelt, aber STL's konnte nur unter "Mesh" rausschreiben. Im Grunde sind doch STL's und UNV's beides Mesh-Files, oder? Also keine Geometrie, wie zB ein CAD-File. Nur sollte ich wahrscheinlich das UNV-Netz etwas feiner modellieren. So hatte ich eure Beiträge verstanden.

Ich werde mal versuchen, die nächsten Abende eine einfache Rohrströmung zu simulieren. Aber nochmal: Der "Fluid-Raum" ist im UNV-File samt der Faces-Definition enthalten und im STL-File ist sozusagen die Rohr an sich (Festkörper). Ist doch richtig, oder?

Gruß
Ay

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

Eine zusaätzliche Frage an Shorty:

Was macht folgende Zeile in deiner Brückensimulation?

surfaceFeatureExtract -includedAngle 140 constant/triSurface/bruecke.stl bruecke

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

Hi,

1. es gibt viele Wege um ans Ziel zu kommen (vor allem in OpenFOAM)
2. STL kannst du im Geometrie und im Mesh Modul exportieren
3. UNV und STL haben so nichts gemeinsam
4. In meiner Brückensimualtion kommen alle BC von meinem Hintergrundnetz. Lediglich die Brücke liefert mir eine Wand als BC. Der Grund hierfür ist, dass es eig. ein Umströmungsproblem ist.
5. Mit deinem Rohr kannst du (wie gesagt) auf mehreren Wegen ans Ziel kommen.
5a. Rohr offen -> BC für inlet und outlet kommt vom Hintergrundnetz; BC für die Wand kommt vom Rohr.
5b. Rohr geschlossen -> alle BC kommen vom Rohr
6. surfaceFeatureExtract extrahiert die FeatureEdges für snappyHexMesh in der OpenFOAM-2.1.0 Version. Ab 2.2.x geht das dann mit nem Dictionary.

------------------
Grüße Tobias Holzmann

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

Danke für die Infos. Ich glaube, ich blicke schon relativ gut durch, wie es prinzipiell funktionieren soll. Das Problem im Moment ist noch der Umgang mit Salome. Wie im meinem letzten Beitrag geschrieben: Ich hatte meine Faces definiert und als STL rausgeschrieben. Ich habe sie nur nicht im STL danach gefunden. Ich habe mir dazu ein Tutorial auf youtube angesehen, wahrscheinlich habe ich die Faces nur der Geometrie und nicht der Mesh zugeordnet

Deswegen die Verwirrung in meiner letzten Email.

Wenn ich die obigen Schritte von 1-5 schaffe, fängt erst der interessante Part an!

Da ich Zugang zu ANSA habe und mir *.nas-Files erzeugen kann: Kann ich auch die Geometrie und das Hintergrundnetz aus diesem Filetyp erzeugen? In der Präsi von Jackson steht folgender Satz "Geometry data (stl, nas, obj) in constant/triSurface", aber ich habe bzgl. dem Hintergrundnetz (*.unv) nichts gefunden.

[Diese Nachricht wurde von Ay am 03. Apr. 2013 editiert.]

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

Moin Moin,

Du kannst das Hintergrundnetz (wenn es als unv exportiert wurde) mit dem Tool ideasUnvToFoam "Beispielmesh.unv" in ein polyMesh umwandeln.

Um die definierten Flächen auch im Mesh zu haben einfach "Rechts-klick" auf das Mesh im Verzeichnisbaum und auf "Create Groups from Geometry"
Da kannst dann die definierten Flächen aus dem Geom-Modul in das Mesh "reinmachen".

Gruß

[Diese Nachricht wurde von bartholomew83 am 03. Apr. 2013 editiert.]

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

Zitat:
Original erstellt von Ay:

In der Präsi von Jackson steht folgender Satz "Geometry data (stl, nas, obj) in constant/triSurface", aber ich habe bzgl. dem Hintergrundnetz (*.unv) nichts gefunden.
[Diese Nachricht wurde von Ay am 03. Apr. 2013 editiert.]

Du musst hierbei stark unterscheiden!

Was snappyHexMesh will ist eine Geometrie in dem Format stl, nas, obj. Das sind keine numerischen Netze sondern Geometrieoberflächennetze. STL arbeitet dabei mit einer Triangulation um die Oberfläche zu approximieren bei obj. und nas weiß ich es nicht aber es werden Algorithmen verwendet um die Oberfläche abzubilden.

Du solltest im User-Guide einmal die Sektion sHM durchlesen und den Grundgedanken festhalten.

sHM (im Folgenden mit ich bezeichnet) arbeitet wie folgt

Code:

a. ich brauche ein numerisches Rechennetz (Quader), das aus Hexaederzellen besteht (Hintergrundnetz)
b. ich belasse dieses numerische Netz, insofern mir nichts anderes gesagt wird
c. wenn mir gesagt wird, dass ich eine bspw. eine Außenkontur abbilden soll, dann benötige ich die Geometrieoberflächendaten (stl, obj, nas)
d. als nächstes prüfe ich, welche Zellen des numerischen Rechennetzes von der Geometrieoberfläche geschnitten werden
e. wenn ich was finde, dann verfeinere ich diese Zellen oder mach gar nichts; je nach dem was man mir vorgibt (SurfaceRefinements)
f. sollte ich die Arbeit erledigt haben, suche ich die Zelle in der der locationPoint zu finden ist
g. wenn ich ihn gefunden habe ist alles was mit dieser Zelle verbunden ist Region0; alles andere ist für mich eine andere Region
h. wird keine multiregionale Vernetzung gewünscht, entferne ich alle Zellen von allen Regionen außer Region0
i. nun hab ich das numerische Rechennetz auf die gewünschte Geometrie angepasst aber sie ist noch nicht sauber approximiert (castellated)
j. ich versuche nun die Hexaederzellen die an der Geometrieoberfläche sind durch verschieben der Eckpunkte an die Geometrie anzunähern (snap); hierbei entstehen dann auch andere Zellarten
k. wenn ich das erledigt habe bin ich fertig, außer der Benutzer wünscht eine Grenzschichtauflösung an bestimmten Geometrieoberflächen (layer)

Ich weiß jetzt zwar nicht ob man das verstehen kann, aber so würde ich es einem Laien (zumindest) versuchen zu erklären.

------------------
Grüße Tobias Holzmann

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

Hallo zusammen,

ich bin mir eigentlich sicher dass ich das so gemacht habe aber ich werde es nochmal nachprüfen (bzgl Salome).

Ich verstehe, was passiert und passieren soll. Das geht mir aus der Jackson-Präsi verständlich hervor. Shorty, du hast ja in dem "snappyHexMeshDict" deiner Brückensimulation sehr viel editiert, falls das von dir ist. So an sich verstehe ich das schon, nur gehts mir nur um den strukturellen Aufbau.

Die Geometrie liegt als *.STL (oder NAS oder OBJ) im Ordner /constant/triSurface/
Das Hintergrundnetz als *.unv (etwas anderes möglich?) einfach im Case-Ordner

Später wird das unv-File konvertiert mit "ideasUnvToFoam" zu blockMesh.unv (falls NAS geht, gibt ein ideasNasToFoam?)
Danach passiert "etwas" (die Antwort darauf von Shorty habe ich eigentlich nicht verstanden) mit dem *.STL-File mit "surfaceFeatureExtract -includedAngle 140 constant/triSurface/bruecke.stl bruecke"
Und danach wird mit "snappyHexMesh" das Skript im System-Ordner "snappyHexMeshDict" durchgeführt, worin man seine ganzen Parameter definiert.

Im "snappyHexMeshDict" wird das STL-File angezogen. Wie wird eigentlich das Hintergrundnetz angezogen? Und aus welchem Ordner? Allein durch den Namen "blockMesh.*"?

Und zu "surfaceFeatureExtract": Ist dieser Schritt zwingend erfolderlich?

Und zu *.nas: Ich arbeite damit seit Jahren und für mich ist das ein numerisches Netz. Da sind GRID's und CQUAD4's definiert. Die CQUAD4's bilden natürlich im Endeffekt eine Oberfläche, aber ist das denn die Definition eines "Geometrieoberflächennetzes"?

[Diese Nachricht wurde von Ay am 03. Apr. 2013 editiert.]

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

Zitat:
Die Geometrie liegt als *.STL (oder NAS oder OBJ) im Ordner /constant/triSurface/
Das Hintergrundnetz als *.unv (etwas anderes möglich?) einfach im Case-Ordner

Also die .unv-Datei kannst Du einfach in den Case-Ordner ablegen. Also neben "0" "constant" und "system".
Dann führst Du im Terminal den Befehl ideasUnvToFoam "Hintergrundnetz.unv" aus.
Das Programm schreibt Dir dann automatisch das Netz ins /constant/polyMesh/. Die unv-Datei könnte rein theoretisch danach wieder gelöscht werden.
Bevor Du sHM ausführst, muss dieser Schritt gemacht werden.

Das mit den triSurface hast Du richtig verstanden, da kommt die Geometrie rein.
Von NAS und OBJ hab ich leider keine Ahnung, arbeite nur mit STLs.

Zitat:
Später wird das unv-File konvertiert mit "ideasUnvToFoam" zu blockMesh.unv (falls NAS geht, gibt ein ideasNasToFoam?)

Also das "unv-Format" hat mit blockMesh nichts zu tun .... "blockMesh" ist ein Programm, welches Dir (aus der "blockMeshDict") ein Netz in das polyMesh schreibt.
Wenn man es so beschreibt, ist "ideasUnvToFoam" ein Programm welches Dir ein polyMesh aus der "unv" schreibt.

Zusammengefasst:
blockMeshDict enthält Input für "blockMesh" -> blockMesh schreibt polyMesh
unv enthält Input für "ideasUnvToFoam" -> ideasUnvToFoam schreibt polyMesh

Ein "ideasNasToFoam" gibt es glaub ich nicht?! Habe da aber nicht nachgeguckt.
Aber das Hintergrundnetz ist ja schnell mit Salome erstellt, zur Not gehts doch dann auch ohne ANSA, oder?
Ansonsten halt den Standardweg über blockMesh.

Hoffe, das war verständlich.
Bei Fehlern muss shorty mich korrigieren

Gruß

[Diese Nachricht wurde von bartholomew83 am 03. Apr. 2013 editiert.]

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

Hi,

wie gesagt von *nas hab ich noch keine Erfahrung gemacht. STL ist nur ein Oberflächennetz und beinhaltet keine internen Zellen.

SnappyHexMesh sucht nach seinem numerischen Netz immer im constant/polyMesh Ordner.
Wurde ja oben schon sehr schön beschrieben wie du das machen kannst. Optional wäre auch ein Hexaedernetz von ICEM möglich und das dann über die cfx4 Schnittstelle oder Fluentschnittstelle exportieren und mit dem entsprechenden Programm in ein OpenFOAM Mesh umwandeln.
Wenn du im *nas File auch interne Zellen hast und das Mesh aus Hexaedern besteht, kannst du das auch verwenden. Notwendig ist halt dann ein Tool, dass dir das in ein OpenFOAM Mesh konvertiert.

surfaceFeatureExtract ist nicht zwingend Notwendig;
Das ist nur ein Werkzeug(Feature um deine Kanten der Geometrie besser zu approximieren. Sollte der Schritt nicht erwünscht sein dann musst du im sHMDict die Einträge in der Sektion

Code:

features
(
.
.
.
);

löschen. Du wirst sehr schnell den Unterschied feststellen.
Im neuen sHM 2.2.x gabs da einige schöne Änderungen.

Die Einstellungen die ich geändert habe sind eben auf den Fall angepasst.
Von der Layergenerierung hab ich die Werte von der Präsentation herausgenommen, allerdings hab ich glaub bei der Brückensimulation keine Layer erzeugt.

Alle anderen wurden modifiziert und auf die Brücke angepasst.

------------------
Grüße Tobias Holzmann

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

Aaaahh super Danke! Also jetzt sind mir schon einige Lichter aufgegangen!

Zitat:
Also das "unv-Format" hat mit blockMesh nichts zu tun .... "blockMesh" ist ein Programm, welches Dir (aus der "blockMeshDict") ein Netz in das polyMesh schreibt.
Wenn man es so beschreibt, ist "ideasUnvToFoam" ein Programm welches Dir ein polyMesh aus der "unv" schreibt.

Das ist aus der Brückensimulation. Shorty hat das anscheinend nur "blockMesh.unv" genannt, den im /system gibt es kein "blockMeshDict". Hierbei wird nicht die Application "blockMesh" durchgeführt. Das hatte mich verwirrt, aber Shorty wird das sicherlich besser beantworten können.

PS: Ich hoffe, ich nerve euch nicht mit meinen doofen Fragen...

@Shorty: Danke! Mir ist einiges klarer geworden!!

[Diese Nachricht wurde von Ay am 03. Apr. 2013 editiert.]

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

Hey,

richtig. Die blockMesh.unv hat nichts mit blockMesh zu tun. Ich nenne diese *.unv Files immer blockMesh, weil ich damit sinnbildlich das Hintergrundnetz erstelle, das sehr oft mit der Applikation blockMesh generiert wird. Wenn ich bspw. ein Tetnetz aus Salome exportiere, dann heißt das anders, weil sHM für das Hintergrundnetz ein Hexaedernetz benötigt.

Na dann ist ja alles klar; freut mich/uns

------------------
Grüße Tobias Holzmann

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