| |
| Leitfaden für die Materialauswahl im Spritzguss, ein Fachartikel
|
Autor
|
Thema: Viele Domains bei MultiregionMeshing mit SnappyHexMesh (1867 / mal gelesen)
|
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 12. Dez. 2016 18:55 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, ich möchte freie Konvektion um eine Lampe mit dem chtMultiRegionFoam simulieren und hänge wie so oft bei SnappyHexMesh fest. Ich habe meine STLs mit salome exportiert und habe das OF-Tutorial mit meinen STLs ersetzt. SnappyHexMesh läuft ohne Probleme durch. CheckMesh sagt alles ok. Für den SplitMeshRegion Befehl rechnet mein PC ewig, was daran liegt, dass sehr viele (>2000) zusätzliche Domains erstellt werden. Wer weiß weiter? Was für Alternativen bestehen? Danke und Grüße 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: 12. Dez. 2016 23:21 <-- editieren / zitieren --> Unities abgeben: Nur für perschr
Hi, das Problem liegt haupsachlich an deinen STLs. Schau dich mal um, entweder hier oder im cfd-online Forum. Die Frage habe ich schon sehr oft beantwortet. Alternativ könntest du jede Region selber vernetzten. Damit umgehst du das splitten und dementsprechend deine 1000 Domains. Zudem wäre es ggf sinnvoll deine allowFreeStandingFaces zu deaktivieren. Viel Erfolg. ------------------ Viele Grüße, Tobias Holzmann OpenFOAM Tutorials | Publikationen | Für Anfänger wiki.openfoam.com Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 14. Dez. 2016 19:47 <-- editieren / zitieren --> Unities abgeben:
|
Shor-ty Moderator
Beiträge: 2466 Registriert: 27.08.2010 ESI-OpenCFD OpenFOAM v2312
|
erstellt am: 14. Dez. 2016 19:52 <-- editieren / zitieren --> Unities abgeben: Nur für perschr
Die einzelnen Regionen (also die single STL's) haben interface Flächen, die genau zueinander trianguliert sein sollten. Ist das nicht der Fall, bekommst du Zwischenräume die bei genügend feiner Vernetzung sHM als eigene Domain behandelt. Salome export heißt nicht das es gut ist. Wenn du das im Goem-Modul exportiert hast, dann ist die Datei wie bei jeder andere CAD Software. ------------------ Viele Grüße, Tobias Holzmann OpenFOAM Tutorials | Publikationen | Für Anfänger wiki.openfoam.com Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 15. Dez. 2016 18:11 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobi, was würden die ganzen OpenFoam Lernenden ohne dich tun? Existiert eine Möglichkeit eine identische Surface Triangulation an den Interfaces zu haben? Mein erster Ansatz hierzu wäre, beim Exportieren der STLs für beide Bauteile die gleiche Surface zu nehmen. Ich vermute jedoch, dass ich dann Probleme bekomme, weil mein STL Löcher hat. Danke und Gruß 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: 19. Dez. 2016 12:34 <-- editieren / zitieren --> Unities abgeben: Nur für perschr
Zitat: Original erstellt von perschr: Hallo Tobi,was würden die ganzen OpenFoam Lernenden ohne dich tun?
Ich denke, das jeder weiterkommen würde :) früher oder später. Zitat:
Existiert eine Möglichkeit eine identische Surface Triangulation an den Interfaces zu haben?
Jap. Dazu verwendest du in Salome einfach das Mesh-Module und triangulierst alle Patches gleich (bspw. mit localLength). Zitat:
Mein erster Ansatz hierzu wäre, beim Exportieren der STLs für beide Bauteile die gleiche Surface zu nehmen. Ich vermute jedoch, dass ich dann Probleme bekomme, weil mein STL Löcher hat.
Möglich muss aber nicht. Wichtiger wäre dann hier ggf. die Ausrichtung der Surface-Normal-Vectors. Kann man aber auch mit FOAM Tools ändern. Da gibts nen Post bei sourceFlux. Alternativ wäre natürlich Blender zu empfehlen
------------------ Viele Grüße, Tobias Holzmann OpenFOAM Tutorials | Publikationen | Für Anfänger wiki.openfoam.com Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 20. Dez. 2016 17:11 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobi, inwieweit hat Blender seine Vorteile bei der Triangulation? ich habe für alle domains (fluid und solid) cad-dateien erstellt und bei iges-Baugruppe in salome reingeladen. Ich habe mein Problem gelöst indem ich eine domain komplett weggelassen habe. Dann hat er mir ordentlich die Regionen aufgeteilt. Dennoch würde mich interessieren, wie du alternativ mit blender vorgehst? Die Triangulation verfeinern oder einheitliche inferfaces erstellen? Wie. Habe meine Case jetzt soweit, dass ich Ihn das erste mal habe laufen lassen. Mit runApplication 'getApplication'läuft er. Mit runParallel 'getApplication' mit vorherigem decompose aber nicht? Fehler: --> FOAM FATAL ERROR: [0] Cannot find file "points" in directory "air2/polyMesh" in times 0 down to constant Weißt du hier weiter? Grüße 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: 20. Dez. 2016 18:59 <-- editieren / zitieren --> Unities abgeben: Nur für perschr
|
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 21. Dez. 2016 19:50 <-- editieren / zitieren --> Unities abgeben:
Servus, ich bin dem Fehler auf die Schliche gekommen. Kann ihn aber momentan noch nicht lösen. Und zwar liegen mir einige patches nach dem vernetzen vor, welche im Rahmen vom ChangeDictionary in symmetryPlanes geändert werden sollen. Das funktioniert jedoch nur teilweise. In den Fluid-Domains in den Dateien epsilon,k,p,p_rgh,T,U wird der patch erfolgreich in symmetryPlane geändert. In alphat und rho steht unter boundary beim relevanten Patch calculated und bei cellToRegion zeroGradient. Dadurch funktioniert Decompose nicht richtig. Erste FRage: FÜr was steht alphat? Für was brauch ich cellToRegion? Und wie können die boundarys einheitlich auf symmetry umgestellt werden, ohne es per Hand zu ändern? Ich will später mal ne Parameterstudie drüberlaufen lassen. Im Tutorial snappyMultiRegionHeater wird dafür im Changedictionary die Boundarys neu definiert. So habe ich es auch gemacht. Danke und frohe Weihnachten! Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 30. Dez. 2016 10:12 <-- editieren / zitieren --> Unities abgeben:
Hallo liebe Gemeinde, zum aktuellen Stand meines Projektes: Mit ChangeDictionary habe ich es nicht geschafft die boundarytypes entsprechend auf symmetryPlane zu ändern. Ich gebe mich jetzt vorerstmal mit dem händischen Ändern im 0-Folder zufrieden. Ich habe meinen Case zum laufen gebracht er läuft bis ca. 10 Sekunden. Dann bricht er aus mir unersichtlichen Gründen ab, ich habe bereits mit maxCo gespielt. Dabei tauchen folgende Auffälligkeiten auf: Das komplette Mesh nach der Berechnung mit dem Befehl paraFoam zur öffnen führt zu einer Fehlermeldung - siehe Bild im Anhang. Am unteren Inlet des umströmenden Fluids habe ich Temperaturen von 310 K trotz fixed Value von 300 K. Ich kann noch keine Wärmeleitung erkennen. Ich gebe die KOmponenten Diode eine Temperatur von 500 K vor. Wenn ich aber die Diode selbst betrachte habe ich das Gefühl selbst in der Diode wird keine Wärme geleitet. Hat jemand Input für mich? Danke! Anbei meine Boundarys für die umströmende Luft
Code:
FoamFile { version 2.0; format ascii; class volScalarField; location "0/domain0"; object T; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //dimensions [ 0 0 0 1 0 0 0 ]; internalField uniform 300; boundaryField { maxY { type zeroGradient; } minX { type fixedValue; value uniform 300; } maxX { type inletOutlet; value uniform 300; inletValue uniform 300; } minY { type zeroGradient; } minZ { type symmetryPlane; } maxZ { type zeroGradient; value uniform 300; } domain0_to_lampe { type compressible::turbulentTemperatureCoupledBaffleMixed; value uniform 300; Tnbr T; kappaMethod fluidThermo; } domain0_to_schirm { type compressible::turbulentTemperatureCoupledBaffleMixed; value uniform 300; Tnbr T; kappaMethod fluidThermo; } domain0_to_kuehlrippen { type compressible::turbulentTemperatureCoupledBaffleMixed; value uniform 300; Tnbr T; kappaMethod fluidThermo; } domain0_to_schirmhalter { type compressible::turbulentTemperatureCoupledBaffleMixed; value uniform 300; Tnbr T; kappaMethod fluidThermo; } domain0_to_leuchtenhalter { type compressible::turbulentTemperatureCoupledBaffleMixed; value uniform 300; Tnbr T; kappaMethod fluidThermo; } }
Und das zugehörige U-File: Code:
FoamFile { version 2.0; format ascii; class volVectorField; location "0/domain0"; object U; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //dimensions [ 0 1 -1 0 0 0 0 ]; internalField uniform ( 0 0 0 ); boundaryField { maxY { type zeroGradient; value uniform ( 0 0 0 ); } minX { type pressureInletVelocity; value uniform ( 0 0 0 ); } maxX { type pressureInletOutletVelocity; value uniform ( 0 0 0 ); inletValue uniform ( 0 0 0 ); } minY { type zeroGradient; value uniform ( 0 0 0 ); } minZ { type symmetryPlane; value uniform ( 0 0 0 ); } maxZ { type zeroGradient; value uniform ( 0 0 0 ); } domain0_to_lampe { type fixedValue; value uniform ( 0 0 0 ); } domain0_to_schirm { type fixedValue; value uniform ( 0 0 0 ); } domain0_to_kuehlrippen { type fixedValue; value uniform ( 0 0 0 ); } domain0_to_schirmhalter { type fixedValue; value uniform ( 0 0 0 ); } domain0_to_leuchtenhalter { type fixedValue; value uniform ( 0 0 0 ); } }
Sowie der Boundarys für der Diode:
Code:
FoamFile { version 2.0; format ascii; class volScalarField; location "0/diode"; object T; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //dimensions [ 0 0 0 1 0 0 0 ]; internalField uniform 300; boundaryField { minZ { type fixedValue; value uniform 500; } diode_to_lampe { type compressible::turbulentTemperatureCoupledBaffleMixed; value uniform 300; Tnbr T; kappaMethod solidThermo; } diode_to_air2 { type compressible::turbulentTemperatureCoupledBaffleMixed; value uniform 300; Tnbr T; kappaMethod solidThermo; } }
[Diese Nachricht wurde von perschr am 30. Dez. 2016 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 13. Jan. 2017 21:08 <-- editieren / zitieren --> Unities abgeben:
Hallo, also ich habe den entscheidenden Fehler gefunden. Der Befehl transformPoints beim Netzerstellung hat nicht funktioniert und ich hatte Ihn nicht kontrolliert. WEnn ich jede Region mit transformPoints -scale "(0.001 0.001 0.001)" -region REGIONNAME skalieren rechnet er plausibel los. Inzwischne stehe ich aber vor einen andere Problem. Ich habe die Berechnung bis 2 Sekunden physikalische Zeit laufen lassen. Die Ergebnisse schauen plausibel aus. Jetzt möchte ich wieder ab diesen 2 Stunden starten. Startfrom latesttime im controldict bewirkt zwar, dass er ab 2 Sekunden startet. Jedoch sind die Temperaturen wieder wie bei 0 Sekunden physikalischer Zeit. Weiß jemand was? Danke! Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 14. Jan. 2017 09:11 <-- editieren / zitieren --> Unities abgeben:
So sah meine Befehle zum restart aus: Code: #!/bin/sh cd ${0%/*} | | exit 1 # Source tutorial run functions . $WM_PROJECT_DIR/bin/tools/RunFunctions for i in air2 air3 diode domain0 kuehlrippen lampe leuchtenhalter schirm schirmhalter do runApplication -s $i changeDictionary -region $i done
#-- Run on single processor #runApplication `getApplication` rm -rf processor* rm -rf log.decomposePar ## Decompose runApplication decomposePar -allRegions # ## Run pyFoamPlotRunner.py mpirun -np 8 chtMultiRegionFoam -parallel >> log.chtMultiregionFoam # ## Reconstruct rm -rf log.reconstructParMesh runApplication reconstructPar -allRegions paraFoam -touchAll shutdown -h now
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: 14. Jan. 2017 15:41 <-- editieren / zitieren --> Unities abgeben: Nur für perschr
Hi, Code:
runApplication decomposePar -allRegions
Ich bin mir jetzt nicht sicher aber es kann sein das -allRegions (-force) enthält. Glaub ich zwar nicht aber könnte sein. Die Frage die sich mir stellt ist, wieso du wieder dein Netz zerlegst?
- DecomposePar
- Solver laufen lassen
- Checken -> paraview (da kann man direkt decomposed Ergebnisse betrachten)
- Solver stoppen
- Solver neustarten
- ...
Wenn du reconstructPar machst, deine processor* Ordner löscht, dann wäre ggf. noch das Argument -latestTime das fehlende Detail. Übrigens, FOAM gibt dir immer aus welchen Zeitordner er nimmt. Kann natürlich auch sein das
Code:
runApplication decomposePar -allRegions
Einfach den Zeitordner "0" als Standard nimmt. Falls ja, dann ist meine Aussage mit -force falsch und du musst lediglich das -latestTime anhängen. ------------------ Viele Grüße, Tobias Holzmann OpenFOAM Tutorials | Publikationen | Für Anfänger wiki.openfoam.com Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 14. Jan. 2017 21:40 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobi, danke für die schnelle Antwort. Kann ich frozenFlow Option in fvSolution zeitabhängig gestalten? Z.b. die ersten paar Sekunden physikalische Zeit frozenFlow true, dann false? Grüße 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: 14. Jan. 2017 22:05 <-- editieren / zitieren --> Unities abgeben: Nur für perschr
|
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 15. Jan. 2017 10:37 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobi, meines Wissens nach setzt frozenFlow die Lösung der Impulsgleichung und dazugehörige Druckgleichung (PISO, SIMPLE) aus. Die Strömung wird praktisch zum Zeitpunkt eingefroren. Dadurch rechnet er deutlich schneller, weil nur die Energiegleichung überbleibt. Für meine Anwendungsfall ist das interessant, da die Wärme erst nach einer gewissen Zeit an die Umgebungsluft getragen wird, und dann freie konvektion bewirkt. Bis dahin kostet mich die Lösung der IMpulsgleichung nur Rechenzeit. Grüße
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 15. Jan. 2017 16:56 <-- editieren / zitieren --> Unities abgeben:
Hallo Tobi, sorry aber wenn ich den Solver bis 2 Sekunden physikalischer Zeit laufen lasse und dann ohne Reconstruct die Ergebnisse eines Bauteils mit dem Befehl paraFoam -region <NAME> betrachten möchte, zeigt mit paraView keine Zeiten zu Auswahl an außer 0. Wie hast du das genau gemeint? Viele Grüße
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: 15. Jan. 2017 17:52 <-- editieren / zitieren --> Unities abgeben: Nur für perschr
|
perschr Mitglied Student
Beiträge: 22 Registriert: 25.10.2014
|
erstellt am: 20. Jan. 2017 23:58 <-- editieren / zitieren --> Unities abgeben:
Servus, also die geilen Videos bringen mich ja schon mal ordentlich weiter. Danke! Mein Case läuft einiger Maßen. Habe die Ergebnisse vom Velocity-Feld mal dargestellt. Wie plausibel empfindet ihr die freie Konvektion? Ich hätte eher erwartet, dass Rund um die Lampe es nach oben strömt. 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: 23. Jan. 2017 09:42 <-- editieren / zitieren --> Unities abgeben: Nur für perschr
Naja das kommt drauf an wie du deinen Case aufgesetzt hast. Für mich sieht das zuerstmal plausibel aus. Allerdings hab ich keine Ahnung wie deine Temperaturen sind, deine Dichte, dein Druckfeld. Das musst du schon selber entscheiden ob das korrekt ist oder nicht ... Simulationen kann man »oft« schnell machen, aber die Plausibilität zu klären ist dann nochmals was ganz anderes. Da ist dann wirklich Kenntnis gefordert in den einzelnen Teildisziplin. Allein schon numerische Schemen können hin und wieder dein Ergebnis komplett verfälschen (möglicherweise jetzt nicht in einem Standardfall, aber hier im Institut haben wir da schon das ein oder andere mal Probleme gehabt - zwecks Latent Heat etc.). ------------------ Viele Grüße, Tobias Holzmann OpenFOAM Tutorials | Publikationen | Für Anfänger wiki.openfoam.com Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |