| |  | Online-Kurs: Grundlagen des 3D-Druck-Designs für Industrieingenieure , ein Kurs
|
Autor
|
Thema: Messung in Paraview an STL-Fläche (5492 mal gelesen)
|
torty2014 Mitglied Konstrukteur

 Beiträge: 28 Registriert: 30.08.2014 Kubuntu 16.04 OF 2.4.0
|
erstellt am: 28. Sep. 2014 15:21 <-- editieren / zitieren --> Unities abgeben:         
Hallo zusammen, ich habe eine Strömungssimulation gerechnet. Jetzt möchte ich in Paraview Durchflussmengen an definierten Flächen messen. Die Flächen möchte ich als STL-Flächen an Parview geben. Wie kann ich die STL-Flächen mit den Simulationsdaten verknüpfen, so daß ich mit Integrate Variables auf die STL-Flächen die Strömungsgrößen wie z.B. Durchflussmenge oder mittlere Geschwindigkeit auslesen kann ? Danke. Gruß Torsten Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
torty2014 Mitglied Konstrukteur

 Beiträge: 28 Registriert: 30.08.2014 Kubuntu 16.04 OF 2.4.0
|
erstellt am: 07. Okt. 2014 11:00 <-- editieren / zitieren --> Unities abgeben:         
Dann stelle ich die Frage mal anders. Also: Ich habe ein Gebläse. Das Gebläse soll aus der Umgebung Luft ansaugen und in die Umgebung ausblasen. Daher habe ich mir mit BlockMesh einen großen Raum erzeugt und dann mit SnappyHexMesh mein Gebläse darin vernetzt. Das klappt auch ganz gut. Jetzt möchte ich aber mal ein paar Werte auslesen. Ich rechne inkompressibel (SimpleFoam, k-epsilon). Wenn meine Rechnung stimmt, müsste ja die Luftmenge, die in das Gebläse rein geht, gleich der Menge sein, die aus dem Gebläse raus kommt. Und das ganze dann auch noch recht konstant über mehrere Iterationsschleifen. Im Bild habe ich mal die Geometrien aufgezeigt. Wenn ich SnappyHexMesh die Flächen vom Einlass und vom Auslass gebe und als Patch definiere und danach einen Punkt im Gebläse wähle, wirft Snappyhexmesh alles weg, was ausserhalb des Gebläses ist (doof). Daher habe ich beim Vernetzen Einlass und Auslass weg gelassen. Allerdings kann ich jetzt in Paraview auch nicht an den Flächen messen (auch doof). Hat jemand eine gute Idee, was ich tun kann ? Danke. Gruß Torsten Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
     

 Beiträge: 2466 Registriert: 27.08.2010
|
erstellt am: 07. Okt. 2014 22:05 <-- editieren / zitieren --> Unities abgeben:          Nur für torty2014
Hallo Torsten, ich wollte mal schauen ob sich andere zur Diskussion miteinschalten aber da hab ich wohl wieder falsch gelegen. Daher beantworte ich dir jetzt mal deine ganzen Fragen:
- Wenn du an einer Wand keinen Patch definiert hast, kannst du mit Slices und Clips arbeiten. Solltest du beispielsweise in einer gekrümmten Wand einen Wert haben, dann wählst du das "internalField" ab und dann nur die Wände und splittest das dann mit Clips so das es dem entspricht was du möchtest. Anderes Beispiel: in einem Kanal möchtest du den Massenstrom bestimmen; dazu mit Clips + Slices arbeiten und dann auf dem Slice deinen Massenstrom berechnen.
- Massenstrom in Paraview kann man wie folgt berechnen: Slice, IntegrateVariable, Calculator --> berechnen über Geschwindigkeitsfeld, Querschnitt und Dichte
- Die Massenerhaltung MUSS bei jedem Iterationsschritt erhalten sein, sonst ist die Berechnung nicht stabil und wird dir in den meisten Fällen abbrechen.
- Sei gewarnt, wenn du den Massenstrom von Inlet und Outlet über Paraview berechnest (starke Interpolationsfehler), alternative natürlich mittels OpenFOAM Tools wie patchIntegrate etc.
- Zum Netz: Wieso ist es wichtig was außerhalb passiert? Wenn es wichtig für dich ist, kannst du auch internalPatches generieren mit createPatch ist das beispielsweise möglich oder Stichwort "baffles"
- Zum Simulationsfall, wieso simulierst du ein stehenden Rotor? Das ist doch physikalisch nicht das was du eigentlich simulieren möchtest (:
------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
torty2014 Mitglied Konstrukteur

 Beiträge: 28 Registriert: 30.08.2014 Kubuntu 16.04 OF 2.4.0
|
erstellt am: 08. Okt. 2014 00:39 <-- editieren / zitieren --> Unities abgeben:         
Hallo Thobias, vielen Dank für deine Antwort. Das mit dem Slice und Clip habe ich gerade mal ausprobiert. Mit dem Calculator muß ich noch ein bischen üben. Gibt es da auch einen Trick, um runde (oder Freiform-) Flächen zu extrahieren ? Das mit dem Baffles hat noch nicht geklappt. Ich habe in der snappyhexmeshdict den Einlass und den Auslass als baffle definiert. Dabei hat SnappyHexMesh alle Zellen außerhalb des Gebläses weg geworfen. Die Zellen außerhalb des Gebläses habe ich mit berechnet, weil ich um den Rotor eine MRF-Zone gelegt habe, für die ich eine Rotation definiert habe. Sollte doch für eine SteadyState Rechnung ausreichen, um z.B. ein Fördervolumen zu berechnen. Oder? In meinen ersten Versuchen hatte ich nur das Gebläse vernetzt und habe dann festgestellt, daß die Geschwindigkeiten schnell in physikalisch sehr unrealistische Größen ansteigen. Daher meine Idee, den Raum um das Gebläse mit zu vernetzen und so aus der Umgebung Luft anzusaugen und auszublasen. Gruß Torsten Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
     

 Beiträge: 2466 Registriert: 27.08.2010
|
erstellt am: 09. Okt. 2014 09:57 <-- editieren / zitieren --> Unities abgeben:          Nur für torty2014
Zitat: Original erstellt von torty2014:
Gibt es da auch einen Trick, um runde (oder Freiform-) Flächen zu extrahieren ?
Einen Trick kenne ich da nicht, außer eben das man nur die Surface anzeigen lässt (sofern vorher definiert) und dann mit Clips arbeitet oder wenn die Surface so verarbeitet wurde das es genau die zu interessierende Oberfläche ist, dann ist das ja nur die Auswahl im linken Menü Zitat:
Das mit dem Baffles hat noch nicht geklappt. Ich habe in der snappyhexmeshdict den Einlass und den Auslass als baffle definiert. Dabei hat SnappyHexMesh alle Zellen außerhalb des Gebläses weg geworfen.
Kannst du mal den Teil deiner sHMD angeben? Zitat:
Die Zellen außerhalb des Gebläses habe ich mit berechnet, weil ich um den Rotor eine MRF-Zone gelegt habe, für die ich eine Rotation definiert habe. Sollte doch für eine SteadyState Rechnung ausreichen, um z.B. ein Fördervolumen zu berechnen. Oder?
Habe mit MRF noch nicht gearbeitet aber ist das in simpleFoam implementiert? Ich finde nur den SRFSimpleFoam Löser. Außerdem verstehe ich nicht wie du die Simulations aufsetzt wenn du außerhalb deiner Geometrie eine MRF definierst. Sollte das nicht der Rotor sein?
- Wie gesagt, ich habe damit keine explizite Erfahrun
Zitat:
In meinen ersten Versuchen hatte ich nur das Gebläse vernetzt und habe dann festgestellt, daß die Geschwindigkeiten schnell in physikalisch sehr unrealistische Größen ansteigen. Daher meine Idee, den Raum um das Gebläse mit zu vernetzen und so aus der Umgebung Luft anzusaugen und auszublasen.
Das sollte aber nicht sein, ich nehme stark an, dass dein Setup des Cases dann nicht korrekt war. ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
torty2014 Mitglied Konstrukteur

 Beiträge: 28 Registriert: 30.08.2014 Kubuntu 16.04 OF 2.4.0
|
erstellt am: 09. Okt. 2014 22:25 <-- editieren / zitieren --> Unities abgeben:         
Hallo Tobias, ich habe mal meinen Case als ZIP Datei hochgeladen. So wie ich das verstehe, wird bei der MRF Simulation Energie eingebracht (über die rotierende Zone). Die Energie muß natürlich auch irgendwo abgebaut werden, ansonsten steigt die Geschwindigkeit der Luft an, bis das System im Gleichgewicht ist. Ich arbeite mich aber gerade erst in das Thema Strömungssimulation ein und lese mich gerade noch mit dem Ferziger schlau. Ich denke mal in meinem Case stecken noch ein paar Fehler. Bei den STL-Dateien findest du auch zwei Flächen mit Einlass und Auslass. Ich habe auch zwei verschiedene SnappyHexMeshdicts im Case. Das eine (ohne Anhang) vernetzt das komplette Gebiet mit dem Raum um das Gebläse. Die Snappyhexmeshdict mit Endung, vernetzt nur das Gebläseinnere (ich habe den Einlass und den Auslass mit eingebracht). Die Vernetzung läuft nur unter OpenFoam 2.3.0. Unter OpenFoam 2.2.2 ändert SnappyHexMesh die Namen leider ab, so das die definierten Randbedingungen nicht passen. Gruß Torsten Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
     

 Beiträge: 2466 Registriert: 27.08.2010
|
erstellt am: 15. Okt. 2014 12:30 <-- editieren / zitieren --> Unities abgeben:          Nur für torty2014
Hallo Thorsten, ich bin mir nicht sicher ob du deine Geometrie so abbilden kannst wie du das machen willst (deinen Case noch nicht angeschaut). Müsste mir die MRF Tutorials nochmals genauer betrachten aber soweit wie ich das beurteilen kann, ist das so auf deinen Fall nicht anwendbar. In den Tutorials sind ja immer nur Ausschnitte gezeigt, die dann stehen und via BC sich die Wand mit einer bestimmten Geschwindigkeit bewegt. Nach dem ersten Ermessen ist das so ne Art Superpositionsprinzip bei der der Betrachter eben auf dem beweglichen sitzt. Entsprechen bewegt sich ja dann die Wand, welche mit Randbedingungen entsprechend modelliert werden kann. Daraus folgt, dass man keine Drehbewegung benötigt. Jedoch stellt sich mir die Frage ob das in deinem Fall funktioniert oder nicht und wenn, dann müsstest du ggf. um deinen Rotor eine Face-Zone Definieren, die dann mit einer rpm BC belegt wird. Wie gesagt ich bin keineswegs in der Thematik MRF oder SRF bewandert. ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
torty2014 Mitglied Konstrukteur

 Beiträge: 28 Registriert: 30.08.2014 Kubuntu 16.04 OF 2.4.0
|
erstellt am: 15. Okt. 2014 22:36 <-- editieren / zitieren --> Unities abgeben:         
Hallo Tobias, prinzipiell läuft die Rechnung ja. In den beiden Bildern im Anhang habe ich mal das Geschwindigkeitsprofil in einem z-Schnitt dargestellt. Um den Rotor habe ich natürlich eine Zone (ist im zweiten Bild transparent dargestellt) definiert, die ich dann über die fvOptions als Rotation definiert habe. Gruß Torsten Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
     

 Beiträge: 2466 Registriert: 27.08.2010
|
erstellt am: 16. Okt. 2014 10:14 <-- editieren / zitieren --> Unities abgeben:          Nur für torty2014
Sehr schöne Darstellung, joa dann hab ich mir das gestern schon fast richtig erklärt:
Zitat:
Frage ob das in deinem Fall funktioniert oder nicht und wenn, dann müsstest du ggf. um deinen Rotor eine Face-Zone Definieren, die dann mit einer rpm BC belegt wird.
An die CellZone + Rotation habe ich gar nicht gedacht aber wunderbar. Sieht doch schon ganz gut aus. Die Sache wäre natürlich zu wissen, wie sich das mit MRF (oder verwendest du SRF?) und einem DyM verhält. Sowie die Betrachtung in qualitativer und quantitativer abschneidet. Wenn du möchtest, kann ich deinen Case gerne mal mit DyM laufen lassen... (: sofern ich das video dann auch veröffentlich kann. Ansonsten würde ich ggf. ein ähnlichen Case mal aufsetzen. Zurück zur eigentlichen Thematik, dann läuft deine Rechnung ja jetzt ohne Probleme?! Was sich mir gerade stellt, läuft der Rotor mit oder gegen den Uhrzeigersinn. Laut meinem Verständnis müsste er gegen den Uhrzeigersinn laufen aber deine Geschwindigkeitsfelder sehen so aus als würde der sich mit dem Uhrzeiger sinn drehen ... kann mich auch irren (: ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
torty2014 Mitglied Konstrukteur

 Beiträge: 28 Registriert: 30.08.2014 Kubuntu 16.04 OF 2.4.0
|
erstellt am: 16. Okt. 2014 11:11 <-- editieren / zitieren --> Unities abgeben:         
Hallo Tobias, die Geometrien habe ich mir mal einfach zum Üben erstellt. Wer die Daten für eigene Berechnungen nutzen möchte darf das gerne tun. Würde mich freuen, wenn du die Rechnung mit DyM machen möchtest. Die Rotation sollte schon gegen den Uhrzeiger laufen. Ich bin mal stumpf davon ausgegangen, daß ich in der fVOptions mit dem Vektor die Achse und auch die Richtung für einen rechtsdrehenden Rotor festgelegt habe. Die Drehzahl habe ich dann berechnet mit ((Umdrehung pro Minute)/60)*2*Pi (Der Rotor müsste sich mit 1000 Umdrehungen pro Minute drehen.) In dem gezeigten Case habe ich die Umgebung mit vernetzt. Als ich nur das innere des Gebläses vernetzt hatte, sind die Geschwindigkeiten stark angestiegen. Meine Vermutung geht dahin, daß ich über die MRF-Zone Kraft auf die Luft ausübe. Daher wird es zu einer Beschleunigung der Luft kommen, bis sich irgendwann ein Beharrungszustand einstellt, bei dem über Reibung oder Druckerhöhung so viel Energie abgeführt wird, wie ich über den Rotor in das System einbringe. Das hätte vermutlich auch funktioniert, wenn ich ein poröses Medium im Ausgang des Gebläses definiert hätte, durch das ich hindurch blase. War aber (noch nicht) das, was ich wollte. Daher habe ich die Umgebung genutzt, um einen realistischen Gegendruck für meine Luft zu erzeugen. Beim Vernetzen habe ich übrigens auf Layer verzichtet, weil ich später dann mal Geometrien berechnen möchte, bei denen ich mit Layern bestimmt auf die Nase falle. Von daher habe ich versucht, die Bereiche in Wandnähe über ein feineres Netz aufzulösen, so daß ich mit meinen y+ Werten im Bereich unter 300 bleibe. Zur Stabilität der Rechnung muß ich leider sagen, daß ich auf einem Laptop rechne (i7-Prozessor mit 4 Kernen). Der hat sich im Laufe der Rechnung leider öfters aufgehängt (ich vermute mal Temperaturprobleme). Die Rechnung an sich müsste aber schon ziemlich stabil laufen. Aber wie gesagt, ich stehe noch ziemlich am Anfang und arbeite mich gerade mit dem Ferziger als Gute-Nacht-Lektüre in das Thema ein (sehr interessantes Buch). Gruß Torsten [Diese Nachricht wurde von torty2014 am 16. Okt. 2014 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
     

 Beiträge: 2466 Registriert: 27.08.2010
|
erstellt am: 16. Okt. 2014 11:22 <-- editieren / zitieren --> Unities abgeben:          Nur für torty2014
Ja Ferziger ist einer meiner Lieblingsbücher. Aber auch eine harte Kost zu beginn. Derzeit arbeite ich "The OpenFOAM Tchnology Primer" durch. Noch knappe 100 Seiten übrig. Vllt schreibe ich ein kleines Feedback über das Buch mal schauen. Werde mir deinen Case mal näher betrachten und das ggf. dann auf meinem Cluster mit dem DyM probieren. Ggf. könnte man dann hierüber ein neues Thema erstellen, weil das ja eigentlich mit deiner Anfangsfrage nicht mehr zu tun hat (: ------------------ Best regards, Tobias Holzmann Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
torty2014 Mitglied Konstrukteur

 Beiträge: 28 Registriert: 30.08.2014 Kubuntu 16.04 OF 2.4.0
|
erstellt am: 16. Okt. 2014 12:00 <-- editieren / zitieren --> Unities abgeben:         
Ja, der Ferziger ist harte Kost. Ich denke auch mal, daß ich (wenn ich das Buch mal durch habe) nochmal am Anfang beginnen kann. Aber es werden halt auch viele Themen ausführlich erklärt. :-) Ziel bei meiner Gebläseberechnung ist übrigens, daß ich mal ermitteln wollte, welchen Volumenstrom das Gebläse umsetzt. Als nächstes will ich dann auch mal herausfinden, wie ich das Antriebsdrehmoment berechnen kann (Leistungsabschätzung). Danach will ich dann das Gebläse noch um einen Luftfilter erweitern (poröses Medium). Damit müsste ich dann alles haben, um auch mal ein realistisches Gebläse zu berechnen. Das mit dem neuen Thema ist eine gute Idee. Gruß Torsten Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
User1000 Mitglied Student
 
 Beiträge: 163 Registriert: 07.06.2011
|
erstellt am: 16. Okt. 2014 17:07 <-- editieren / zitieren --> Unities abgeben:          Nur für torty2014
Hallo, vielen Dank an euch, das mit der Installation hat nun endlich geklappt. Hier würde ich gerne kurz einsteigen, vor allem weil ich was von Literatur höhre. Wie ist das mit dem Buch OpenFoam the ... Primer. Ist es halbwegs empfehlenswert, kostet ja jetzt nicht die Welt. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty Moderator
     

 Beiträge: 2466 Registriert: 27.08.2010 ESI-OpenCFD OpenFOAM v2312
|
erstellt am: 16. Okt. 2014 17:12 <-- editieren / zitieren --> Unities abgeben:          Nur für torty2014
|
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
 |