|
Autor
|
Thema: AMI bewegt sich nicht (1603 mal gelesen)
|
bastipa93
Mitglied
   Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 04. Mrz. 2021 11:57  <-- editieren / zitieren -->   Unities abgeben:          
Hallo zusammen, ich habe mich an einem rotating mesh ausprobiert und mich mit Hilfe des Tutorials "rotatingFanInRoom" dort entlanggehangelt. Jetzt bin ich jedoch auf das Problem gestoßen, dass sich mein mesh nicht dreht. Ich habe die mesh-files und die case-files angehängt (mesh war zu groß zum Anhängen, daher konnte ich das leider nicht im case mit einfügen). Zu meinem Vorgehen: analog zum Tutorial rotatingFanInRoom habe ich über AMI eine Zone definiert, in welcher sich die Zellen bewegen sollen. Meiner Einschätzung nach sieht das mesh mit AMI auch korrekt aus, aber ich kann mich da natürlich auch komplett irren. Soweit habe ich eigentlich alles aus dem Tutorial übernommen, bis auf dass ich die Randbedingungen einzelner Flächen ganz anders definiert habe. Background dazu: ich habe im Prinzip die gleiche Simulation mit einer glatten Wand schon einmal gemacht, nur dass man hier entsprechend der Wand eine Geschwindigkeit zuordnen konnte, da diese halt glatt war. Dort hat alles mit den Randbedingungen geklappt, sodass ich sie für ein rotierendes mesh übernommen habe. Da ich jetzt eben keine glatte Wand mehr habe, musste ich auf ein rotierendes mesh zurückgreifen... Ich habe leider keinen Anhaltspunkt, warum sich mein mesh nicht dreht. Ich habe auch schon in mehreren Foren gesucht, aber keine Lösung dafür gefunden. Ich hatte zunächst angenommen, dass es am dynamicMeshDict liegt, aber dieses ist, bis auf origin, axis und omega, identisch zu dem aus dem Tutorial: Code:
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2012 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "constant";
object dynamicMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //dynamicFvMesh dynamicMotionSolverFvMesh; motionSolverLibs (fvMotionSolvers); motionSolver solidBody; cellZone rotatingZone; solidBodyMotionFunction rotatingMotion; origin (0 0 0);
axis (0 0 1);
omega 0.427853502; // ************************************************************************* //
Hat einer von euch eine Idee, woran es liegen könnte? Viele Grüße
bastipa93 [Diese Nachricht wurde von bastipa93 am 04. Mrz. 2021 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
    
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 04. Mrz. 2021 13:04 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93 
Der erste Schritt ist immer den moveDynamicMesh löser zu verwenden. Wenn sich da nichts tut dann schau mal Deinen Output des Lösers bzw. vom moveDynamicMesh an. Wie sind deine Zeitschritte? 0.4278 1/rad ist natürlich auch sehr wenig. Da muss man schon mal ne 0.2 s mindestens haben das man was sieht. Ist ja immerhin nicht mal ne viertel Umdrehung pro Sekunde. ------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 04. Mrz. 2021 14:50 <-- editieren / zitieren --> Unities abgeben:
Ach, cool, moveDynamicMesh kannte ich noch gar nicht! Funktioniert auf jeden Fall und das mesh bewegt sich so, wie es soll. Mir ist auch aufgefallen, dass ich eine Sache nicht aus dem Tutorial übernommen habe, nämlich habe ich die rotierende innerWall vorher auf noSlip gesetzt, laut Tutorial wurde aber die sich bewegende Fläche bzw. das Objekt auf Code:
{
type movingWallVelocity;
value uniform (0 0 0);
}
gesetzt. Das habe ich so übernommen, allerdings schießen die Zahlen, sowohl Moment als auch Courant-Zahl, extrem in die Höhe und das bei einem deltaT von 2E-10. Das scheint also nicht der Weg zur Lösung zu sein... Also habe ich die innerWall wieder auf noSlip gesetzt und das deltaT "drastisch" auf 0.002 erhöht. Und jetzt weiß ich nun wirklich gar nicht, wo das Problem liegt, denn: mein mesh bewegt sich wunderbar, aber überall ist die Geschwindigkeit 0. Eigentlich müsste das Fluid ja durch die Kanten im Mesh mitgetragen werden und so eine Geschwindigkeitskomponente erhalten, aber da tut sich wirklich gar nichts... Weißt du da zufällig, woran es liegen könnte? Hier einmal mein p und U, falls es irgendwie daran liegen sollte, aber die Randbedingungen haben, wie gesagt, in einem anderen Fall bei mir sehr gut funktioniert. p
Code:
dimensions [0 2 -2 0 0 0 0];
internalField uniform 0;
boundaryField
{
top
{
type empty;
}
bottom
{
type empty;
}
innerWall
{
type zeroGradient;
}
outerWall
{
type zeroGradient;
}
AMI1
{
type cyclicAMI;
value uniform 0;
}
AMI2
{
type cyclicAMI;
value uniform 0;
}
}
U
Code:
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
top
{
type empty;
}
bottom
{
type empty;
}
innerWall
{
type noSlip;
}
outerWall
{
type noSlip;
}
AMI1
{
type cyclicAMI;
value uniform (0 0 0);
}
AMI2
{
type cyclicAMI;
value uniform (0 0 0);
}
}
Diese Dateien bleiben auch in den nachfolgenden Zeitschritten komplett gleich. Edit:
So wie ich das verstehe (und bitte korrigiert mich, wenn ich falsch leige  ) muss die innerWall mit movingWallVelocity typisiert werden, da der innerWall ja die Geschwindigkeit der Wand zugeordnet werden muss. Allerdings bleibt für mich immer noch die Frage offen, warum es nach ca. 5 Iterationen zu solch derartigen Zusammenbrüchen kommt... [Diese Nachricht wurde von bastipa93 am 04. Mrz. 2021 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 15. Mrz. 2021 11:49 <-- editieren / zitieren --> Unities abgeben:
Hat niemand eine Idee, woran es liegen könnte? Was mir dazu noch aufgefallen ist: ich habe fvSolution und fvSchemes aus dem Tutorial rotatingFanInRoom übernommen. Die Sache ist jetzt die, dass ich das Tutorial ohne Probleme durchführen konnte. Wenn ich nun aber meinen case mit diesem fvSolution und fvSchemes ausführen möchte, kommt dort die Fehlermeldung: Code:
[7]
[7]
[7] --> FOAM FATAL IO ERROR:
[7] Unable to set reference cell for field p
Please supply either pRefCell or pRefPoint
[7]
[7]
[7] file: IOstream.PIMPLE
[7]
[7] From function bool Foam::setRefCell(const volScalarField&, const volScalarField&, const Foam::Dictionary&, Foam::label&, Foam::scalar&, bool)
[7] in file cfdTools/general/findRefCell/findRefCell.C at line 100.
[7]
FOAM parallel run exiting
Diesen Fehler habe ich damals umgangen, indem ich bei fvSolution unter "PIMPLE" die folgenden Einträge hinzugefügt habe: Code:
pRefCell 0;
pRefValue 0;
Dann tritt diese Fehlermeldung nicht mehr auf, allerdings schießen die Werte dann nur so in die Höhe. Könnte es eventuell auch damit zusammenhängen? (p ist bei mir allerdings überall auf den Wert 0 gesetzt...) Und falls ja, wieso läuft meine Simulation denn ohne pRefCell und pRefValue nicht, das Tutorial allerdings schon? [Diese Nachricht wurde von bastipa93 am 15. Mrz. 2021 editiert.] [Diese Nachricht wurde von bastipa93 am 15. Mrz. 2021 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 15. Mrz. 2021 18:17 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Wissen tut man das schon nur kannst Du nicht erwarten, dass sich zu jederzeit jemand um Deine Themen kümmert 
- pRef muss man angeben, wenn man keine Druckrandbedingung definiert und sich somit unendlich viele Lösungen einstellen könnten. Es ist nur der Druckgradient entscheidend und ob wir jetzt 1000 - 300 als Gradient berechnen oder 25735 - 25035 ist vollkommen egal.
- Wo bekommst Du denn deine Extremwerte? Ist dein Case noch aktuell oben?
- Du erwähnst immer ein Tutorial - welches denn?
- Und ja movingWallVelocity muss gesetzt werden.
------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 16. Mrz. 2021 07:59 <-- editieren / zitieren --> Unities abgeben:
Das erwarte ich natürlich auch nicht und freue mich über jede Hilfestellung, die mir gegeben wird  Es ist nur ziemlich nervenzerreibend, wenn man an solch einer Thematik seit Längerem sitzt und die Antwort auf das Problem hoffentlich in diesem Forum zu finden sein wird Da wird man bei längerer Zeit ohne Antwort schon ein wenig ungeduldig und hofft, dass sein Problem nicht in Vergessenheit gerät Zu Deinen Fragen:
Im Grunde genommen bricht alles komplett aus. Im Folgenden einmal die ersten 7 Iterationen, nach denen ich abgebrochen habe, weil es einfach keinen Sinn mehr ergab. Auch bei niedrigeren Zeitschritten gibt es keine Verbesserung. Code:
Create mesh for time = 0Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: solidBody
Applying solid body motion to cellZone rotatingZone
Selecting solid-body motion function rotatingMotion
Applying solid body motion to cellZone rotatingZone PIMPLE: no residual control data found. Calculations will employ 3 corrector loops Reading field p Reading field U Reading/calculating face flux field phi AMI: Creating addressing and weights between 38400 source faces and 38400 target faces
AMI: Patch source sum(weights) min:0.9999987 max:1.000023 average:1
AMI: Patch target sum(weights) min:0.9999986 max:1.000003 average:1
Selecting incompressible transport model Newtonian
Selecting turbulence model type laminar
Selecting laminar stress model Stokes
No MRF models present No finite volume options present
Constructing face velocity Uf Courant Number mean: 0 max: 0 Starting time loop forces forces:
rho: rhoInf
Freestream density (rhoInf) set to 970
Not including porosity effects Courant Number mean: 0 max: 0
Time = 1e-10 PIMPLE: iteration 1
AMI: Creating addressing and weights between 38400 source faces and 38400 target faces
AMI: Patch source sum(weights) min:0.9999987 max:1.000023 average:1
AMI: Patch target sum(weights) min:0.9999986 max:1.000003 average:1
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 4.878015e-07, No Iterations 63
time step continuity errors : sum local = 2.36015e-13, global = 6.628137e-18, cumulative = 6.628137e-18
GAMG: Solving for p, Initial residual = 1, Final residual = 9.577344e-07, No Iterations 44
time step continuity errors : sum local = 1.296643e-16, global = 2.969879e-17, cumulative = 3.632692e-17
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 0.6915528, Final residual = 7.858256e-07, No Iterations 33
time step continuity errors : sum local = 1.894482e-14, global = 1.840867e-14, cumulative = 1.844499e-14
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 0.3505879, Final residual = 9.970442e-07, No Iterations 50
time step continuity errors : sum local = 2.107605e-13, global = 2.092296e-13, cumulative = 2.276746e-13
ExecutionTime = 9.19 s ClockTime = 10 s forces forces write:
Sum of forces
Total : (92.07507 4.89126 -3.969121e-08)
Pressure : (92.07576 4.891331 -1.687607e-08)
Viscous : (-0.0006916661 -7.144392e-05 -2.281514e-08)
Sum of moments
Total : (0.004157572 -0.07826381 -1.135043)
Pressure : (0.004157632 -0.07826439 -1.134551)
Viscous : (-6.084247e-08 5.876467e-07 -0.0004921251)
Courant Number mean: 3.752563e-09 max: 4.323769e-07
Time = 2e-10
PIMPLE: iteration 1
AMI: Creating addressing and weights between 38400 source faces and 38400 target faces
AMI: Patch source sum(weights) min:0.9999987 max:1.000023 average:1
AMI: Patch target sum(weights) min:0.9999986 max:1.000003 average:1
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 8.729927e-07, No Iterations 48
time step continuity errors : sum local = 2.092153e-13, global = 2.092152e-13, cumulative = 4.368897e-13
GAMG: Solving for p, Initial residual = 0.7617769, Final residual = 9.931779e-07, No Iterations 52
time step continuity errors : sum local = 2.207653e-12, global = 2.20052e-12, cumulative = 2.63741e-12
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 0.8202843, Final residual = 4.3359e-07, No Iterations 56
time step continuity errors : sum local = 2.300902e-11, global = 2.298036e-11, cumulative = 2.561777e-11
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 0.8246963, Final residual = 9.216107e-07, No Iterations 52
time step continuity errors : sum local = 2.404884e-10, global = 2.398405e-10, cumulative = 2.654583e-10
ExecutionTime = 19.14 s ClockTime = 21 s forces forces write:
Sum of forces
Total : (107866.7 6397.93 -4.225532e-05)
Pressure : (107867.5 6397.975 -8.63595e-06)
Viscous : (-0.836187 -0.04544276 -3.361937e-05)
Sum of moments
Total : (5.438241 -91.68667 -1.182977)
Pressure : (5.438279 -91.68738 -1.182404)
Viscous : (-3.875105e-05 0.0007105739 -0.0005727623)
Courant Number mean: 1.135027e-06 max: 0.0004956078
Time = 3e-10
PIMPLE: iteration 1
AMI: Creating addressing and weights between 38400 source faces and 38400 target faces
AMI: Patch source sum(weights) min:0.9999987 max:1.000023 average:1
AMI: Patch target sum(weights) min:0.9999986 max:1.000003 average:1
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 9.156822e-07, No Iterations 54
time step continuity errors : sum local = 2.398247e-10, global = 2.398245e-10, cumulative = 5.052828e-10
GAMG: Solving for p, Initial residual = 0.8258288, Final residual = 9.619184e-07, No Iterations 60
time step continuity errors : sum local = 2.516767e-09, global = 2.509721e-09, cumulative = 3.015003e-09
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 0.8248912, Final residual = 8.767956e-07, No Iterations 55
time step continuity errors : sum local = 2.627809e-08, global = 2.621e-08, cumulative = 2.9225e-08
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 0.825485, Final residual = 9.525761e-07, No Iterations 57
time step continuity errors : sum local = 2.759529e-07, global = 2.751799e-07, cumulative = 3.044049e-07
ExecutionTime = 28.95 s ClockTime = 31 s forces forces write:
Sum of forces
Total : (1.237554e+08 7335818 -0.0503867)
Pressure : (1.237563e+08 7335870 -0.009861865)
Viscous : (-955.1255 -51.99841 -0.04052484)
Sum of moments
Total : (6235.445 -105192.1 -71.97944)
Pressure : (6235.489 -105192.9 -71.91701)
Viscous : (-0.04434473 0.8116448 -0.06243315)
Courant Number mean: 0.001297225 max: 0.5686528
Time = 4e-10
PIMPLE: iteration 1
AMI: Creating addressing and weights between 38400 source faces and 38400 target faces
AMI: Patch source sum(weights) min:0.9999987 max:1.000023 average:1
AMI: Patch target sum(weights) min:0.9999986 max:1.000003 average:1
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 9.216153e-07, No Iterations 54
time step continuity errors : sum local = 2.751618e-07, global = 2.751615e-07, cumulative = 5.795664e-07
GAMG: Solving for p, Initial residual = 0.8311887, Final residual = 7.609059e-07, No Iterations 56
time step continuity errors : sum local = 3.067758e-06, global = 3.061417e-06, cumulative = 3.640983e-06
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 0.8561607, Final residual = 8.472403e-07, No Iterations 156
time step continuity errors : sum local = 4.818097e-05, global = 4.810522e-05, cumulative = 5.17462e-05
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 0.947935, Final residual = 9.650419e-07, No Iterations 588
time step continuity errors : sum local = 0.002012817, global = 0.002011355, cumulative = 0.002063101
ExecutionTime = 63.73 s ClockTime = 67 s forces forces write:
Sum of forces
Total : (9.490346e+11 5.635415e+10 -6030.76)
Pressure : (9.489834e+11 5.635167e+10 -49.30893)
Viscous : (5.119372e+07 2479843 -5981.451)
Sum of moments
Total : (4.790117e+07 -8.06679e+08 -607053.6)
Pressure : (4.789892e+07 -8.066359e+08 -609038.7)
Viscous : (2252.019 -43128.67 1985.121)
Courant Number mean: 4.193965 max: 4156.3
Time = 5e-10
PIMPLE: iteration 1
AMI: Creating addressing and weights between 38400 source faces and 38400 target faces
AMI: Patch source sum(weights) min:0.9999987 max:1.000023 average:1
AMI: Patch target sum(weights) min:0.9999986 max:1.000003 average:1
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 8.598714e-07, No Iterations 75
time step continuity errors : sum local = 0.002011222, global = 0.00201122, cumulative = 0.004074321
GAMG: Solving for p, Initial residual = 0.9935367, Final residual = 8.446779e-07, No Iterations 199
time step continuity errors : sum local = 0.09984286, global = 0.09979674, cumulative = 0.1038711
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 0.998539, Final residual = 9.990623e-07, No Iterations 187
time step continuity errors : sum local = 4.422467, global = 4.420349, cumulative = 4.524221
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 0.9993361, Final residual = 9.69855e-07, No Iterations 212
time step continuity errors : sum local = 320.8884, global = 320.7289, cumulative = 325.2531
ExecutionTime = 91.92 s ClockTime = 96 s forces forces write:
Sum of forces
Total : (7.116617e+20 4.639476e+19 -9.057569e+12)
Pressure : (7.116617e+20 4.639476e+19 -7.960405e+10)
Viscous : (3.766951e+11 -3.696463e+11 -8.977965e+12)
Sum of moments
Total : (3.943554e+16 -6.049128e+17 -8.565371e+14)
Pressure : (3.943555e+16 -6.049127e+17 -8.565367e+14)
Viscous : (-2.943343e+09 -1.092625e+11 -3.891511e+08)
Courant Number mean: 571811.6 max: 6.627588e+08
Time = 6e-10
PIMPLE: iteration 1
AMI: Creating addressing and weights between 38400 source faces and 38400 target faces
AMI: Patch source sum(weights) min:0.9999987 max:1.000023 average:1
AMI: Patch target sum(weights) min:0.9999986 max:1.000003 average:1
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 9.138477e-07, No Iterations 49
time step continuity errors : sum local = 320.7077, global = 320.7075, cumulative = 645.9606
GAMG: Solving for p, Initial residual = 0.9993673, Final residual = 8.980421e-07, No Iterations 146
time step continuity errors : sum local = 14242.73, global = 14236.57, cumulative = 14882.54
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 0.9991243, Final residual = 7.743635e-07, No Iterations 177
time step continuity errors : sum local = 741932.7, global = 741637.2, cumulative = 756519.7
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 0.9993733, Final residual = 7.72753e-07, No Iterations 160
time step continuity errors : sum local = 4.544968e+07, global = 4.543268e+07, cumulative = 4.61892e+07
ExecutionTime = 116.19 s ClockTime = 121 s forces forces write:
Sum of forces
Total : (1.727958e+31 1.112663e+30 -1.849561e+21)
Pressure : (1.727958e+31 1.112663e+30 -1.846929e+21)
Viscous : (2.112425e+18 8.058579e+16 -2.631532e+18)
Sum of moments
Total : (9.457633e+26 -1.468765e+28 -2.042538e+25)
Pressure : (9.457633e+26 -1.468765e+28 -2.042538e+25)
Viscous : (-1.35874e+15 -3.370279e+16 1.563493e+14)
Courant Number mean: 7.640161e+10 max: 9.388297e+13
Time = 7e-10
Und ja, mein case ist noch aktuell, ich habe daran nichts verändert und komme leider nicht weiter. Ich habe das case mal hier angehängt. Sowohl mesh als auch case-Ordner sind darin enthalten, da das polyMesh zu groß gewesen ist. Das Tutorial auf das ich mich beziehe ist "rotatingFanInRoom":
https://www.openfoam.com/documentation/guides/latest/doc/tutorial-pimplefoam-ami-rotating-fan.html
bzw.
https://develop.openfoam.com/Development/openfoam/-/tree/develop/tutorials/incompressible/pimpleFoam/RAS/rotatingFanInRoom Anhand dessen habe ich auch mein AMI ausgelegt etc. Wie gesagt, mit moveDynamicMesh klappt alles wunderbar, und es werden sowohl dort als auch bei checkMesh keine Fehler angezeigt. Daher schließe ich Meshprobleme eigentlich aus und denke, dass es irgendwie an den Randbedingungen o.ä. liegt. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 16. Mrz. 2021 13:58 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Hey Basti, also das man da verzweifelt kenn ich. Vor ca. 10 Jahren war das hier auch meine Anlaufstelle aber prinzipiell - ich behaupte das jetzt einfach mal - gibt es hier nur mich, der sich sehr gut mit FOAM auskennt - außer es gibt irgendwelche stillen Leser, die nichts beantworten. Natürlich sind hier - und das freut mich sehr - zwei/drei Leute noch aktiv und helfen aus, aber oft kommen auch sie zu nem Punkt wo es nicht mehr weitergeht und es ist halt auch oft eine "Probier" mal das oder das Antwort ohne die Numerik im Auge zu behalten - und ja auch ich hab das ne Zeitlang gemacht aber man kommt irgendwann halt an die Grenzen - vor allem wenn es Probleme sind, die man nicht lokalisieren kann wie bspw. ein Netzproblem oder Schemen. Wird schon spannender wenn die Gradienten einem ein Strich durch die Rechnung machen - außerdem stellen die meisten ja in den fvSolution und fvSchemes nichts sonderlich groß um. Okay, kleiner Ausflug. Möchte mich da auch nicht zu sehr ins Licht heben aber ich machs halt schon über 10 Jahre und bin ja sehr aktiv in der Community (übrigens auf cfd-online.com bekommst schneller Hilfe - da beweg ich mich eigentlich hauptsächlich - außer ich bekomm ne Mail von cad.de, dann schau ich au hier rein).
Zum Case
Netzproblem kann man mit moveDynamicMesh nicht ausschließen, da es nur die Netzbewegung darstellt. Man kann aber durchaus Zellen haben, die Probleme machen sobald man die Zellwerte auf die Faces interpoliert oder die diversen Berechnungen macht wie bereits den erwähnten Gradienten bildet. Allerdings fällt schon mal auf, dass Du den PIMPLE Algorithmus nicht korrekt verwendest. Ferner nimmt die Co Zahl zwischen den Zeitschritten um circa den Faktor 1000 zu... das scheint komisch zu sein. Fatal ist die Verwendung vom Linearen Schema beim den Div-Schemes. Das gleich mal rausnehmen. Fang mit Upwind an. Deine snGrad Schemen sind auch nicht sonderlich toll. uncorrected nimmt man nur bei sehr guten Netzen. Du hast hier nur nen Relaxationsfaktor von cos^-1(alpha) dabei aber keine Explizite korrektur. Deine nOuterCorrectors kannst auf 1 stellen wenn Du den PIMPLE nicht richtig verwendest. Ich hab das in meinem Buch erklärt (siehe meine Webseite - Mathematics, Numerics, Derivations and OpenFOAM). Natürlich kann der sehr gut sein, aber dann musst halt auch unterrelaxieren.
Deine Zone rotiert sehr langsam (1 Umdrehung in 14 Sekunden), passt das? Dann hast Du kein Inlet/Outlet, richtig? Da Du Dein Druck (was für eine schöne Alliteration) auch nirgends fixierst, machst Du das ja in den fvSolution (hoff Dir ist das klar). Die Frage ist, ob die Zelle mit dem Index "0" hier geeignet ist. Vielleicht macht das ja Probleme?
Schon mal einen Zeitschritt angeschaut und geprüft was oder wo eigentlich ein Problem vorliegt? Ich hab hier gerade kein FOAM zur Hand, schau es mir aber später mal zu Hause an (ist ja auch n 2D Case - also sollte schnell gehen).
Allerdings konnte ich die STL´s mal anschauen und so wie es aussieht dreht sich da ein Zahnkranz. Das AMI ist meines Erachtens aber ggf. falsch oder schlecht. Keine Ahnung wie viele Zellen Du hast aber ich hab da schon nen Verdacht.
------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 16. Mrz. 2021 15:16 <-- editieren / zitieren --> Unities abgeben:
Hey Tobi, interessanter Ausflug cfd-online kannte ich tatsächlich auch schon, aber ich hatte den Eindruck, dass hier irgendwie besser auf Probleme eingegangen wird. Ich habe nun mal mein fvSchemes wie folgt angepasst. Allerdings habe ich das mit dem Relaxationsfaktor nicht verstanden/gefunden, sodass ich in diese Richtung nichts korrigiert habe. Code:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //ddtSchemes
{
default Euler;
} gradSchemes
{
default Gauss linear;
} divSchemes
{
default none; //vorher Gauss linear
div(U) Gauss linearUpwind; //vorher Gauss linear
div(phi,U) Gauss linearUpwind grad(U);
div(phi,k) Gauss linearUpwind grad(U);
div(phi,K) Gauss linearUpwind grad(U);
div(phi,omega) Gauss linearUpwind grad(U);
div((nuEff*dev2(T(grad(U))))) Gauss linear;
} laplacianSchemes
{
default Gauss linear corrected;
} interpolationSchemes
{
default linear;
} snGradSchemes
{
default corrected;
} wallDist
{
method meshWave;
} fluxRequired //war vorher nicht drin
{
default no;
p ;
}
// ************************************************************************* //
Die Simulation scheint etwas stabiler zu laufen, allerdings kann ich das Problem immer noch nicht genau lokalisieren. Zumindest kann ich z.B. bei einem Zeitschritt von 2e-10 auf 3e-10 keine genaue Stelle ausmachen, sondern alles scheint aus dem Ruder zu laufen (s. Bilder). 
Diese Simulation habe ich dann bei 14e-10 abgebrochen, da die Courant-Zahl bei jedem Zeitschritt um ca. eine Dekade angestiegen ist und dann letztendlich bei 14e-10 bei 41 gewesen ist... Die Geschwindigkeit der Zone sollte korrekt sein, denn normalerweise bewegt sie sich mit ca. 4 U/min, was ja entsprechend die von Dir genannten 1 U/15s wäre. Im Prinzip sind es zwei gezahnte Wände (eine außen, eine innen) zwischen denen sich Flüssigkeit befindet. Die innere Wand soll sich drehen, während die äußere Wand stillsteht und das Ziel ist es, das Flüssigkeitsfeld in der x-y-Ebene zu bestimmen sowie das Drehmoment, welches an der inneren Wand anliegt.
Genau, ich habe kein inlet/oulet, da dieses zylindrische System in der Theorie unendlich ausgedehnt ist und es keine Fluidströme gibt, außer die, die durch die Bewegung der Innenwand hervorgerufen werden.
Das mit der Zelle beim Druck ist eine interessante Idee, habe ich ausprobiert, aber auch ein andere pRefCell funktioniert nicht (warum ich das definieren muss ist mir mittlerweile zum Glück klar ) Beim AMI war ich mir nicht ganz sicher, wie weit es gehen muss. Wie gesagt soll sich nur der innere Zahnkranz drehen. Entsprechend habe ich das AMI vom Radius her etwas über den Radius der Zähne an der Innenwand gesetzt. Super wäre es natürlich, wenn es tatsächlich doch "nur" ein Mesh-Problem ist, denn ich hatte erst gedacht, dass ich die Randbedingungen verstanden habe und die so bleiben müssten
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 16. Mrz. 2021 20:26 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 16. Mrz. 2021 20:41 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 17. Mrz. 2021 06:18 <-- editieren / zitieren --> Unities abgeben:
Oh sorry, dann habe ich das mit dem upwind falsch verstanden! Werde das dann gleich mal anders ausprobieren, sobald ich die Zeit habe! Sorry wegen des Runskripts. Aber mein Mesh erzeuge ich wie folgt: Code:
blockMesh
surfaceFeatureExtract
decomposePar
mpirun -np 12 snappyHexMesh -overwrite -parallel
reconstructParMesh -constant -mergeTol 1E-06
renumberMesh -overwrite
createPatch -overwrite
Anschließend dann noch in der boundary-Datei im polyMesh die types von top und bottom auf empty statt Wall setzen, damit das mit den Randbedingungen in p und U passt. Was meinst Du genau mit "4 Zellen sollten zwischen den AMI liegen"? Liegen die beiden AMI nicht direkt aneinander?
Danke für den Tipp mit ACMI, den werde ich mir auch noch anschauen, sobald ich Zeit dafür finde! Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 17. Mrz. 2021 09:22 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Okay, also Du willst 2D rechnen, hast aber kein 2D Netz. Das ist schon mal der erste Punkt. Bei der Erstellung Deines Netz hast Du probleme mit dem VOlumen, da sind 2365816 Zellen betroffen, dadurch bekommst Du total schlechte Zellen an deinen Ecken... Um das zu verbessern, kannst mal Dein Netz um Faktor 1000 hochskalieren (und die STL`s) und dann nochmals machen. Natürlich zurückskalieren am Schluss. Wenn das alles gemacht wurde, dann sollte der Case Laufen. ------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 18. Mrz. 2021 08:36 <-- editieren / zitieren --> Unities abgeben:
Tatsächlich wusste ich bis zu Deiner letzten Antwort nicht, dass es sowas wie extrudeMesh gibt und 2D-Simulationen im Grunde genommen nur mit einem wirklichen 2D-Mesh (z.B. 1 Zelle in z-Richtung) klappen. Dachte bis jetzt, dass 1 Zelle in die entsprechende Richtung eher eine "Empfehlung" wäre, die 2D-Simulationen aber eigentlich auch so klappen sollten... Gut, dass ich das jetzt auch mal gelernt habe Dann werde ich mich sobald ich die Zeit finde gleich mal daran setzen und gucken, wie das mit dem extrudeMesh und AMI und allem zusammen klappt, aber auf die Schnelle habe ich da glaube ich schon einige Beispiele gefunden... Hoffentlich klappt es dann auch damit. Vielen Dank! Notfalls melde ich mich nochmal Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 22. Mrz. 2021 14:29 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Also eine 2D oder 1D Simulation ist immer 3D in Bezug auf die Zellen. Wir arbeiten mit der FiniteVolumen Methode, somit brauchen wir ein Volumen und dementsprechend eine Zelle in die entsprechende Richtung ( checkMesh sagt dir übrigens ob du 2D, 1D, 3D hast). Eine Empfehlung mit einer Zelle ist das nicht sondern Mathematik. Außerdem hast Du wesentlich weniger Zellen -> viel schneller. ------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 25. Mrz. 2021 14:12 <-- editieren / zitieren --> Unities abgeben:
So, ich habe jetzt endlich mal die Zeit gefunden, mich weiter damit zu beschäftigen und einiges auszuprobieren. Entsprechend Deines Tipps habe ich die ganze Geometrie jetzt erstmal um den Faktor 1000 hochskaliert - was an sich auch gar nicht so schlimm erstmal ist, denn vorwiegend geht es mir darum, schauen zu können, wie das Fließfeld im Spalt aussieht. Die Erstellung des 2D-meshs hat auch, soweit ich das beurteilen kann, gut geklappt. Zumindest sehen checkMesh und moveDynamicMesh wie folgt aus: checkMesh (hier zwar mit dem Hinweis, dass 2 Regionen vorhanden sind, aber laut meiner Recherche ist das wohl bei AMI normal - zumindest ist genau der gleiche "Fehler" auch im tutorial rotatingFanInRoom vorzufinden) Code:
Create mesh for time = 0Time = 0 Mesh stats
points: 1131220
internal points: 0
faces: 2220158
internal faces: 1088594
cells: 551516
faces per cell: 5.999376
boundary patches: 6
point zones: 0
face zones: 1
cell zones: 1 Overall number of cells of each type:
hexahedra: 551172
prisms: 344
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0 Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
*Number of regions: 2
The mesh has multiple regions which are not connected by any face.
<<Writing region information to "0/cellToRegion"
<<Writing region 0 with 77988 cells to cellSet region0
<<Writing region 1 with 473528 cells to cellSet region1 Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
top 551516 565610 ok (non-closed singly connected)
bottom 551516 565610 ok (non-closed singly connected)
innerWall 7832 15664 ok (non-closed singly connected)
outerWall 7900 15800 ok (non-closed singly connected)
AMI1 6400 12800 ok (non-closed singly connected)
AMI2 6400 12800 ok (non-closed singly connected) Checking faceZone topology for multiply connected surfaces...
FaceZone Faces Points Surface topology
rotatingZone 12800 25600 ok (non-closed singly connected) Checking basic cellZone addressing...
CellZone Cells Points Volume BoundingBox
rotatingZone 77988 170044 4.500771 (-12.29826 -12.29951 -0.0004778075) (12.3 12.29951 0.300181) Checking geometry...
Overall domain bounding box (-13.59672 -13.59363 -0.0004778075) (13.59672 13.59363 0.300181)
Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
Mesh has 3 solution (non-empty) directions (1 1 1)
Boundary openness (-4.54452e-17 -1.2414e-16 -6.463497e-15) OK.
Max cell openness = 2.246667e-16 OK.
Max aspect ratio = 100.6988 OK.
Minimum face area = 4.635199e-05. Maximum face area = 0.009128399. Face area magnitudes OK.
Min volume = 1.39056e-05. Max volume = 0.000128074. Total volume = 32.82717. Cell volumes OK.
Mesh non-orthogonality Max: 23.74909 average: 0.4767338
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 3.803226 OK.
Coupled point location match (average 0) OK. Mesh OK.
moveDynamicMesh: Code:
Create timeCreate mesh for time = 0 Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: solidBody
Applying solid body motion to cellZone rotatingZone
Selecting solid-body motion function rotatingMotion
Applying solid body motion to cellZone rotatingZone PIMPLE: Operating solver in PISO mode Time = 0.1
PIMPLE: iteration 1
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Mesh topology OK.
Boundary openness (-1.457819e-16 1.578874e-16 -6.844506e-15) OK.
Max cell openness = 2.24869e-16 OK.
Max aspect ratio = 100.8702 OK.
Minimum face area = 4.6352e-05. Maximum face area = 0.009128399. Face area magnitudes OK.
Min volume = 1.39056e-05. Max volume = 0.000128074. Total volume = 32.82717. Cell volumes OK.
Mesh non-orthogonality Max: 23.74909 average: 0.4767338
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 3.803226 OK.
Mesh geometry OK.
Mesh OK.
ExecutionTime = 8.74 s ClockTime = 9 s
Soweit also anscheinend alles gut. Mesh sieht auch gut aus und es gibt, wie vorgeschrieben, nur eine Zelle in z-Richtung. Die einzelnen patches/walls habe ich mir auch in paraView angeschaut und es gehört auch alles dort hin, wo es hin soll - bis auf top und bottom, die sind durch extrudeMesh vertauscht, was aber (hoffe ich) nicht wirklich tragisch ist, oder? (zumindest sind top und bottom ja eigentlich exakt die gleichen Flächen mit den gleichen Randbedingungen etc.) Jetzt habe ich aber das Problem, dass die Simulation immer noch nicht super laufen will. Denn: das Fließfeld sieht nicht wirklich so aus, wie es aussehen soll, s. Bild: 
Hier ist auffällig, dass die Geschwindigkeitsspitzen genau an diesen Kanten sitzen. Eigentlich müsste das gesamte Fluid, welches mit dem inneren Zahnring in Kontakt steht, die Geschwindigkeit der Wand annehmen - was leider nicht der Fall ist. Die boundaryFields in "U" sehen wie folgt aus, was (denke und hoffe ich), eigentlich alles so ist, wie es sein müsste. Code:
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
top
{
type empty;
}
bottom
{
type empty;
}
innerWall
{
type movingWallVelocity;
value uniform (0 0 0);
}
outerWall
{
type noSlip;
}
AMI1
{
type cyclicAMI;
value uniform (0 0 0);
}
AMI2
{
type cyclicAMI;
value uniform (0 0 0);
}
}
Weiterhin bricht die Simulation nach 0.6 s Simulationszeit ab, da die Courant-Zahl wieder explodiert, s. log-Datei: Code:
Time = 0.6158PIMPLE: iteration 1
AMI: Creating addressing and weights between 6400 source faces and 6400 target faces
AMI: Patch source sum(weights) min:0.9997653 max:1.001311 average:1.000034
AMI: Patch target sum(weights) min:0.9997702 max:1.001312 average:1.000034
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 8.337608e-07, No Iterations 91
time step continuity errors : sum local = 3.364239e-10, global = 2.99025e-10, cumulative = 7.762854e-07
GAMG: Solving for p, Initial residual = 0.02404468, Final residual = 6.977045e-07, No Iterations 38
time step continuity errors : sum local = 4.843557e-10, global = 3.012742e-10, cumulative = 7.765866e-07
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 5.983633e-05, Final residual = 7.441486e-07, No Iterations 11
time step continuity errors : sum local = 4.62329e-10, global = 2.691435e-10, cumulative = 7.768558e-07
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 2.283448e-06, Final residual = 6.378249e-07, No Iterations 1
time step continuity errors : sum local = 4.2711e-10, global = 2.676462e-10, cumulative = 7.771234e-07
ExecutionTime = 14169.1 s ClockTime = 14175 s forces forces write:
Sum of forces
Total : (-1255.682 103507.3 1.896502e-09)
Pressure : (-1248.051 103479.5 -4.176809e-13)
Viscous : (-7.63111 27.82239 1.89692e-09)
Sum of moments
Total : (-15423.47 -186.8843 -1.146327e+09)
Pressure : (-15419.33 -185.7477 -1.145165e+09)
Viscous : (-4.14383 -1.13661 -1162569)
Courant Number mean: 0.007604107 max: 0.2496156
Time = 0.6159
PIMPLE: iteration 1
AMI: Creating addressing and weights between 6400 source faces and 6400 target faces
AMI: Patch source sum(weights) min:0.9997654 max:1.001302 average:1.000034
AMI: Patch target sum(weights) min:0.999772 max:1.001303 average:1.000034
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 0.1008651, No Iterations 1000
time step continuity errors : sum local = 4.789039e-08, global = 2.880061e-10, cumulative = 7.774114e-07
GAMG: Solving for p, Initial residual = 0.07989607, Final residual = 0.01982781, No Iterations 1000
time step continuity errors : sum local = 5.490972e-06, global = -8.121366e-10, cumulative = 7.765993e-07
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 0.4547013, Final residual = 0.03488779, No Iterations 1000
time step continuity errors : sum local = 2.225811e-05, global = 6.018412e-08, cumulative = 8.367834e-07
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 0.4700924, Final residual = 0.001745068, No Iterations 1000
time step continuity errors : sum local = 5.434991e-06, global = -2.682575e-07, cumulative = 5.685259e-07
ExecutionTime = 14218.1 s ClockTime = 14224 s forces forces write:
Sum of forces
Total : (1.872295e+11 1.022366e+11 6.470695e-09)
Pressure : (1.872289e+11 1.022364e+11 -2.085025e-09)
Viscous : (596105.7 228088.5 8.55572e-09)
Sum of moments
Total : (-1.523328e+10 2.789723e+10 -6.115079e+09)
Pressure : (-1.523324e+10 2.789714e+10 -6.113697e+09)
Viscous : (-33985.44 88820.71 -1382114)
Courant Number mean: 0.6292206 max: 99.86146
Time = 0.616
PIMPLE: iteration 1
AMI: Creating addressing and weights between 6400 source faces and 6400 target faces
AMI: Patch source sum(weights) min:0.9997654 max:1.001293 average:1.000034
AMI: Patch target sum(weights) min:0.9997739 max:1.001295 average:1.000033
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 0.1378577, No Iterations 1000
time step continuity errors : sum local = 1.666333e-06, global = -2.735875e-07, cumulative = 2.949384e-07
GAMG: Solving for p, Initial residual = 0.3473507, Final residual = 0.009897996, No Iterations 1000
time step continuity errors : sum local = 3.979695e-05, global = 7.584497e-07, cumulative = 1.053388e-06
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 0.3002557, Final residual = 0.008830755, No Iterations 1000
time step continuity errors : sum local = 4.159794e-05, global = 8.739251e-07, cumulative = 1.927313e-06
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 0.9700798, Final residual = 0.01911551, No Iterations 1000
time step continuity errors : sum local = 0.005140806, global = 1.199015e-06, cumulative = 3.126328e-06
ExecutionTime = 14268.06 s ClockTime = 14274 s forces forces write:
Sum of forces
Total : (8.118555e+11 4.617663e+11 -2.638457e-09)
Pressure : (8.118538e+11 4.617658e+11 -4.220283e-09)
Viscous : (1675581 470326.9 1.581826e-09)
Sum of moments
Total : (-6.880328e+10 1.209666e+11 -1.101699e+11)
Pressure : (-6.880321e+10 1.209664e+11 -1.101723e+11)
Viscous : (-70079.56 249664.7 2396254)
Courant Number mean: 2.053024 max: 927.098
Time = 0.6161
PIMPLE: iteration 1
AMI: Creating addressing and weights between 6400 source faces and 6400 target faces
AMI: Patch source sum(weights) min:0.9997654 max:1.001284 average:1.000033
AMI: Patch target sum(weights) min:0.9997761 max:1.001286 average:1.000033
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 0.06025701, No Iterations 1000
time step continuity errors : sum local = 0.0006735374, global = 1.231815e-06, cumulative = 4.358143e-06
GAMG: Solving for p, Initial residual = 0.8033525, Final residual = 0.00256513, No Iterations 1000
time step continuity errors : sum local = 0.0001361918, global = 1.635707e-06, cumulative = 5.99385e-06
PIMPLE: iteration 2
GAMG: Solving for p, Initial residual = 0.8828121, Final residual = 0.4961167, No Iterations 1000
time step continuity errors : sum local = 0.0432364, global = -1.347923e-06, cumulative = 4.645927e-06
PIMPLE: iteration 3
GAMG: Solving for p, Initial residual = 0.9985675, Final residual = 1.394334, No Iterations 1000
time step continuity errors : sum local = 12.7303, global = -3.887534e-05, cumulative = -3.422942e-05
ExecutionTime = 14322.31 s ClockTime = 14328 s forces forces write:
Sum of forces
Total : (1.1426e+16 3.998887e+15 -4.671284e-05)
Pressure : (1.1426e+16 3.998887e+15 -4.674602e-05)
Viscous : (8.847124e+08 4.586789e+08 3.317647e-08)
Sum of moments
Total : (-5.958352e+14 1.702476e+15 7.109164e+14)
Pressure : (-5.958351e+14 1.702476e+15 7.109173e+14)
Viscous : (-6.83435e+07 1.318233e+08 -8.340982e+08)
Courant Number mean: 763.7898 max: 1712852
Jetzt weiß ich nun wirklich nicht weiter... Ich habe einmal meinen mesh-Folder und meinen case-Folder (dieses mal sogar mit Allrun-Skripts ) angehängt. Vielleicht fällt Dir / Euch ja etwas auf?
Kleiner Nachtrag zu den Allrun-Skripts: die Anzahl der Kerne müsste man ggf. manuell ändern, genauso wie im decomposeParDict. [Diese Nachricht wurde von bastipa93 am 25. Mrz. 2021 editiert.] [Diese Nachricht wurde von bastipa93 am 25. Mrz. 2021 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 25. Mrz. 2021 16:05 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Also in 2D löst du sicher nicht. Code:
Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
Mesh has 3 solution (non-empty) directions (1 1 1)
Wenn Du das mal mit pitzDaily I'm OpenFOAM tutorial gegenprüfst:
Code:
Mesh has 2 geometric (non-empty/wedge) directions (1 1 0)
Mesh has 2 solution (non-empty) directions (1 1 0)
Also hast entweder falsche RB order dein Netz ist nicht für 2D. Eine Skalierung um Faktor 1000 ist auch nur für die Vernetzung sinnvoll. Du musst nachdem das Netz für Dich in Ordnung ist natürlich wieder zurückskalieren.
Schau mir das mal schnell an..
------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 25. Mrz. 2021 16:40 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Es gibt immer wieder neues zu sehen Code:
#snappyHexMesh
runApplication mpirun -np 12 snappyHexMesh -overwrite -parallel
Dafür gibts extra:
Code:
runParallel snappyHexMesh -overwrite
Dein AMI hat immer nur noch 2 Zellen zwischen AMI und Wand. Numerisch ist das nicht so toll. Mindestens solltest Du da mal 4 Zellen Einplanen. Mach doch dein AMI einfach größer. Spielt ja keine Rolle ob das in der MItte ist oder direkt an den Zähnen. Nur weil sich das Netz dann dreht, heißt das nicht das sich die Flüssigkeit bewegt. Das wird alles rausgerechnet über die Mesh-Fluxes (natürlich hat man Fehler aber das is eben ganz normal hier).
Dein AMI ist auch kein AMI sondern eine Wall (boundries file), hier auch der Fehler mit deinem Top und Bottom -> sind keine Wände sondern empty.
Aber wenn Du das alles korrigierst, dann funktionierts immer noch nicht:
Code:
***Number of edges not aligned with or perpendicular to non-empty directions: 2231778
Da müsstest wohl erstmal noch flattenMesh verwenden. Wenn Du das dann machst, passts:
Code:
Mesh has 2 geometric (non-empty/wedge) directions (1 1 0)
Mesh has 2 solution (non-empty) directions (1 1 0)
FlattenMesh verwendest Du normalerweise vor dem ExtrudeMesh kannst aber in deinem Fall auch danach anwenden. Ferner hast du bei deinen Fields immer AMI1 AMI2. Soweit das mit den Skripten gemacht wird, sind die Einträge im boundaries File falsch. Das sowas funktioniert:
Code:
div(phi,U) Gauss upwind grad(U);
Wusst ich auch nicht. Woher hast Du den diese Syntax?
Ferner,
Code:
nOuterCorrectors 3; // Was versprichst Du Dir davon?
Entweder verwendest Du den PISO oder PIMPLE Algorithmus. Details in meinem Buch, sofern dir das nichts sagt. Die Courant Zahl lässt Du dann auch bei < 0.8 und lässt Deinen Zeitschritt bezüglich Co anpassen Code:
adjustTimeStep yes;
Dein Kommentar dahinter (also im controlDict) ist übrigens falsch und hat nichts mit writeControl zu tun.
Solltest Du das alles so in etwa umsetzen, dann klappts auch mit der Berechnung. Dein Zeitschritt ist bei ca. 2e-4 (PISO) und läuft stabil weiter. Mir wäre das Netz zu fein für Testzwecke. Übrigens, ich weiß jetzt nicht bei welchem Zeitschritt dein Bild ist aber das ist ganz normal das sich da erstmal sowas ausbildet: Trägheit nennt sich sowas. Wenn Du am Stationären Profil interessiert bist, kanns sein das MRF eine bessere Wahl ist. AMI und dynamische Netze bedarfen halt einer Zeitableitung und machens langsam.
Ich lass das mal n bisschen rechnen und mach dann mal nen Video davon
Allerdings muss ich noch erwähnen, dass ich erst bei 0.2 s bin. Mal kucken ob ich bei 0.6 ein Problem sehe. Alternativ nehme ihc mal PIMPLE mit Co ~ 50. Dann läfuts schneller
------------------
Glück Auf,
Tobi
OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 25. Mrz. 2021 16:52 <-- editieren / zitieren --> Unities abgeben:
Oha, genau so habe ich mir das Fließfeld in den ersten Sekundenbruchteilen vorgestellt! Sehr schön zu sehen, dass es bei Dir klappt! Dass sich das Fließfeld aufgrund der Trägheit erst noch ausbilden muss, war mir bewusst - nur hatte ich die Simulation bereits bei 0.6 s und es sah immer noch so aus... Da diese ganze Problematik aus der Rheologie kommt und sich normalerweise (bei glatten Wänden) das stationäre Fließfeld in dieser Geometrie und der Winkelgeschwindigkeit innerhalb von ca. 0.2 s hätte ausbilden müssen, bin ich halt etwas stutzig geworden... aber Dein Bild sieht echt gut aus, hoffen wir mal, dass ich das auch hinkriege! Danke auf jeden Fall für die ganzen Tipps, das weiß ich wirklich zu schätzen. Leider fehlen mir nur heute und morgen die Zeit, das alles in Gang zu bringen  Hoffen wir mal, dass es dann am Montag klappen wird... PS: Die falschen Codes muss ich wohl irgendwo mal aufgeschnappt haben (ob falsch oder nicht...) und sind wohl da drin geblieben. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 25. Mrz. 2021 17:05 <-- editieren / zitieren --> Unities abgeben:
Mir sind aber noch ein paar Fragen zu deiner Antwort aufgefallen: Zitat:
Dein AMI ist auch kein AMI sondern eine Wall (boundries file), hier auch der Fehler mit deinem Top und Bottom -> sind keine Wände sondern empty.
Moment, da verstehe ich bei AMI etwas nicht. Sind die nicht schon mit AMI typisiert? Jedenfalls steht das bei mir in der boundary-File:
Code:
AMI1
{
type cyclicAMI;
inGroups 1(cyclicAMI);
nFaces 6400;
startFace 2207358;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch AMI2;
}
AMI2
{
type cyclicAMI;
inGroups 1(cyclicAMI);
nFaces 6400;
startFace 2213758;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch AMI1;
}
So war es auch im tutorial rotatingFanInRoom und daher war ich davon ausgegangen, dass es richtig ist...
Achso, und dass top und bottom mit empty typisiert werden müssen, da hast du natürlich recht, das habe ich danach immer manuell gemacht (ich weiß, geht glaube ich auch über das snappyHexMeshDict mit patch Info irgendetwas, aber das habe ich erst letztens gesehen und noch nicht integriert ) Dann zu Folgendem: Zitat:
Da müsstest wohl erstmal noch flattenMesh verwenden. Wenn Du das dann machst, passts:
flattenMesh kannte ich noch nicht. Auf die Schnelle habe ich gesehen, dass man vermutlich ein flattenMeshDict haben muss, richtig? Gibt es da irgendwelche anderen signifikanten Einträge, außer denen?: Code:
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.0 |
| \\ / A nd | Web: http://www.openfoam.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
// flattenMesh tool definitiondescription "Flatten the front and back planes of a 2D cartesian mesh"; flattenMeshDict
{
type dictionary;
description "flattenMesh control dictionary";
dictionaryPath "system"; entries
{
arguments
{
type rootCaseArguments;
}
}
} // ************************************************************************* //
Dann verstehe ich nicht genau, was Du damit meinst: Zitat:
Ferner hast du bei deinen Fields immer AMI1 AMI2. Soweit das mit den Skripten gemacht wird, sind die Einträge im boundaries File falsch.
Wie oben gezeigt, habe ich in meiner boundary-File AMI1 und AMI2. Ist das jetzt doch nicht korrekt?
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 25. Mrz. 2021 18:15 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 25. Mrz. 2021 18:23 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Hey,
- Also flattenMesh braucht prinzipiell keine Einträge sofern du Top und Bottom auf Empty setzt. Damit weiß FOAM was zu tun ist. Man bekommt mit sHM einfach keine 100% Ebene Fläche, daher FlattenMesh
- Das mit AMI1 und AMI2 kam daher, dass aufgrund deines Skripts diese Einträge nicht verändert worden sind. Daher meine Anmerkung. Aber da Du das ja alles manuell machst, passt das (nur eben mit dem Skript wurde das nicht gemacht)
Somit, für mich, die Simulation abgeschlossen. Ich würde - sofern ich das untersuchen würde, das AMI Interface noch zwischen mehr Zellen haben wollen. Aber sieht ganz sauber aus meine Rechnung. Wenn Du sagst, dass sich das stationäre Profil nach 0.2 s einstellen sollte, dann kanns ggf. noch an der Viskosität liegen. Aber die hast Du ja auch angepasst.
Ich hoffe es stört Dich nicht, wenn ich die Berechnung auf meinen Kanal stelle. Find ich ganz lustig mal wieder was dynamisches zu haben.
------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 26. Mrz. 2021 06:33 <-- editieren / zitieren --> Unities abgeben:
Dein Bild nach 6.33 s soll genau so aussehen, perfekt! Ok super, dann hoffe ich mal, dass ich das jetzt endlich hinkriegen werde...
Gerne kannst du das Video etc. auf deinen Kanal stellen Vielen Dank nochmal! [Diese Nachricht wurde von bastipa93 am 26. Mrz. 2021 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 26. Mrz. 2021 09:00 <-- editieren / zitieren --> Unities abgeben:
Bevor ich nun weitermache und notfalls wieder alles nicht klappt, wollte ich Dich kurz fragen, ob der workflow sowie die Ein-/Ausgaben so korrekt sind. Denn weiter unten wirst Du sehen, dass es einen kleinen Fehler bei checkMesh und moveDynamicMesh gibt. Ich gehe also derzeit wie folgt vor: Code:
runApplication blockMesh#runApplication surfaceFeatureExtract (rauskommentiert, da ja einmal vorher reicht) runApplication decomposePar runApplication mpirun -np 12 snappyHexMesh -overwrite -parallel (deinen Tipp dazu habe ich wahrgenommen ;) ) runApplication reconstructParMesh -constant -mergeTol 1E-06 runApplication renumberMesh -overwrite
runApplication createPatch -overwrite
An diesem Punkt ändere ich den Eintrag für "top" und "bottom" in constant/polyMesh/boundary für "type" und "inGroups" von "wall" auf "empty", also so: Code:
top
{
type empty;
inGroups 1(empty);
nFaces 551516;
startFace 1088594;
}
bottom
{
type empty;
inGroups 1(empty);
nFaces 551516;
startFace 1640110;
}
Anschließend gehts weiter mit: Code:
runApplication extrudeMeshrunApplication checkMesh runApplication moveDynamicMesh
Die Ausgaben der beiden "Checks" sind: checkMesh Code:
Time = 0Mesh stats
points: 1131220
internal points: 0
faces: 2220158
internal faces: 1088594
cells: 551516
faces per cell: 5.999376
boundary patches: 6
point zones: 0
face zones: 1
cell zones: 1 Overall number of cells of each type:
hexahedra: 551172
prisms: 344
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0 Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
*Number of regions: 2
The mesh has multiple regions which are not connected by any face.
<<Writing region information to "0/cellToRegion"
<<Writing region 0 with 77988 cells to cellSet region0
<<Writing region 1 with 473528 cells to cellSet region1 Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
top 551516 565610 ok (non-closed singly connected)
bottom 551516 565610 ok (non-closed singly connected)
innerWall 7832 15664 ok (non-closed singly connected)
outerWall 7900 15800 ok (non-closed singly connected)
AMI1 6400 12800 ok (non-closed singly connected)
AMI2 6400 12800 ok (non-closed singly connected) Checking faceZone topology for multiply connected surfaces...
FaceZone Faces Points Surface topology
rotatingZone 12800 25600 ok (non-closed singly connected) Checking basic cellZone addressing...
CellZone Cells Points Volume BoundingBox
rotatingZone 77988 170044 4.500771 (-12.29826 -12.29951 -0.0004778075) (12.3 12.29951 0.2995222) Checking geometry...
Overall domain bounding box (-13.59672 -13.59363 -0.0004778075) (13.59672 13.59363 0.2995222)
Mesh has 2 geometric (non-empty/wedge) directions (1 1 0)
Mesh has 2 solution (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
Boundary openness (6.696483e-17 8.17847e-17 -6.463497e-15) OK.
Max cell openness = 2.246667e-16 OK.
Max aspect ratio = 2.711529 OK.
Minimum face area = 4.635199e-05. Maximum face area = 0.009128399. Face area magnitudes OK.
Min volume = 1.39056e-05. Max volume = 0.000128074. Total volume = 32.82717. Cell volumes OK.
Mesh non-orthogonality Max: 23.74909 average: 0.4767267
Non-orthogonality check OK.
Face pyramids OK.
***Max skewness = 7.902774, 8 highly skew faces detected which may impair the quality of the results
<<Writing 8 skew faces to set skewFaces
Coupled point location match (average 0) OK. Failed 1 mesh checks.
--> Dass die "skewness" hier einen Fehler ausspuckt, dessen bin ich mir bewusst. Ich bin mir nur unsicher, wie tragisch das ist, denn beim tutorial rotatingFanInRoom gab es hier exakt den gleichen "Fehler". Daher meine Frage bzw. der Sinn dieses Posts hier: tritt dieser Fehler bei Dir auch auf und falls nicht, woran könnte es bei mir liegen? moveDynamicMesh sieht wie folgt aus: Code:
Create mesh for time = 0Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: solidBody
Applying solid body motion to cellZone rotatingZone
Selecting solid-body motion function rotatingMotion
Applying solid body motion to cellZone rotatingZone PIMPLE: Operating solver in PISO mode Time = 0.1
PIMPLE: iteration 1
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Mesh topology OK.
Boundary openness (2.134021e-16 1.794096e-16 -6.844506e-15) OK.
Max cell openness = 2.24869e-16 OK.
Max aspect ratio = 100.8702 OK.
Minimum face area = 4.6352e-05. Maximum face area = 0.009128399. Face area magnitudes OK.
Min volume = 1.39056e-05. Max volume = 0.000128074. Total volume = 32.82717. Cell volumes OK.
Mesh non-orthogonality Max: 23.74909 average: 0.4767267
Non-orthogonality check OK.
Face pyramids OK.
***Max skewness = 7.902774, 8 highly skew faces detected which may impair the quality of the results
Failed 1 mesh geometry checks.
Failed 1 mesh checks.
ExecutionTime = 8.74 s ClockTime = 9 s End
Auch hier wieder der Punkt mit der skewness, bin mir nur unsicher, wie "tragisch" das ist, oder ob ich das Mesh jetzt eigentlich so für die Simulation verwenden kann - daher würde es mich brennend interessieren, ob bei Dir das selbe rauskommt. Ich habe heute morgen schonmal die Simulation auf die Schnelle gestartet, nur hat das leider nicht wirklich funktioniert. War, wie gesagt, auf die Schnelle, da ich eigentlich keine Zeit hatte, daher könnte es auch an meinen Simulationssettings liegen.
Deinen Tipp mit dem vergrößerten AMI habe ich auch wahrgenommen, nur da das ja bei dir auch so bereits geklappt hat, wollte ich zumindest alles andere schonmal zum Laufen kriegen Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 26. Mrz. 2021 11:04 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 26. Mrz. 2021 11:26 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 30. Mrz. 2021 11:09 <-- editieren / zitieren --> Unities abgeben:
|
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 31. Mrz. 2021 17:48 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 12. Apr. 2021 06:22 <-- editieren / zitieren --> Unities abgeben:
|
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 15. Apr. 2021 11:26 <-- editieren / zitieren --> Unities abgeben:
Hey Tobi, ich konnte bei einem deiner Beiträge lesen, dass mit Co ~ 50 der pimple-Algorithmus schneller laufen würde. Ich habe derzeit das kleine Mesh am Laufen, und mit Co = 1 steht das deltaT auf 2e-9 - was bei 0.5 s Simulationszeit gut 8 Jahre dauern würde  Verstehe ich dich also richtig, dass ich ggf. im controlDict das maxCo auf 50 setzen könnte, um das alles ein wenig zu beschleunigen? Gibt es eventuell auch noch andere Möglichkeiten, die Simulation schneller laufen zu lassen, außer z.B. auch noch das Mesh gröber zu gestalten? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 15. Apr. 2021 14:03 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Eine Zeitschrittweite von 1e-9 habe ich nur bei Strömungen bei Ma > 1. Ich gehe davon aus, dass Du das nicht hast. Daher ist schonmal irgendwas falsch oder macht Probleme. Wohl möglich eine Zelle die Dir das versaut. Schon mal deine Geschwindigkeiten angeschaut? Bei 1e-9 wäre ich sehr kritisch. Zum anderen Thema. Ja, mit PIMPLE kann man die Courant-Zahl deutlich >> 1 halten. Bspw. auch 200. Aber dann verliert man Zeitinformationen. Sofern das nicht von großer Bedeutung ist, kann man das natürlich durchaus machen. Ich wieß auch nicht ob Du eine stationäre Lösung bevorzugst. ------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 15. Apr. 2021 14:26 <-- editieren / zitieren --> Unities abgeben:
Ma > 1 ist es definitiv nicht, da sich der innere Zylinder gerade mal mit einer Winkelgeschwindigkeit im Bereich von ca. 0.3 rad/s dreht. Gibt es irgendeine Möglichkeit außer checkMesh und moveDynamicMesh die Anwesenheit solcher Zellen herauszufinden? Du hattest ja meinen Fall bei dir laufen, hast du da noch irgendetwas am Mesh verändert? (Ich weiß, ist schon ein wenig her, aber vielleicht erinnerst du dich ja noch) Einerseits interessiert es mich schon, wie sich das Geschwindigkeitsfeld ausbildet, aber eigentlich bin ich nur am stationären Geschwindigkeitsprofil am Ende interessiert. Wenn es daher also eine deutlich einfachere und schnellere Variante gibt, würde ich das auf jeden Fall bevorzugen. Gibt es da irgendetwas?
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 15. Apr. 2021 16:48 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Also der Case lief bei mir recht schnell durch Kann also nicht sein, dass hier irgendwie mit einer Erhöhung der Courant-Zahl gearbeitet werden muss. Ich hab die Schemen angepasst. Weiß nicht ob du "FlattenMesh" auch dabei hattest?... CheckMesh muss definitiv 2D anzeigen. Ansonsten kann ich mich nicht mehr so genau daran erinnern Hier mal mein Case: holzmann-cfd.com/forum/case.tar.gz ------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 19. Apr. 2021 13:04 <-- editieren / zitieren --> Unities abgeben:
Okay, wenn ich deinen case verwende, läuft alles eigentlich genauso schnell. Der Unterschied war halt, dass ich bei den Zeitschritten von 1e-9 das skalierte mesh (auf 0.001) verwendet habe, aber das mesh in deinem case ist ja auch noch, wenn ich mich nicht irre, unskaliert. Was mich allerdings noch stutzig macht ist folgendes: wenn ich mir das Moment etc. ausgeben lasse, oder auch, wenn ich mir den Druck in ParaView anschaue, dann oszilliert der Druck ziemlich stark. Das sieht man z.B. an diesen Werten hier (Moment durch Druck hervorgerufen):
Code:
(pressure_x pressure_y pressure_z)
(1.7518401e+03 -6.7203744e+02 -2.1432562e-10)
(-6.2807255e+02 8.1142978e+02 1.1699511e-10)
(-3.2655562e+03 2.5123267e+03 4.3873757e-10)
(-7.5370407e+03 5.4321997e+03 1.0637484e-10)
(-1.0219316e+04 7.5500360e+03 1.0661592e-10)
(-1.2814649e+04 9.1787478e+03 -2.2657226e-10)
(-1.5820870e+04 1.1051259e+04 4.5039307e-10)
(-1.9136095e+04 1.2974807e+04 -2.2677302e-10)
(-2.2890558e+04 1.5131831e+04 4.4181917e-10)
(-2.7560866e+04 1.7844903e+04 1.0322578e-10)
(-3.0334835e+04 1.9663113e+04 1.0366693e-10)
(-2.6781253e+04 1.7293074e+04 9.5681080e-11)
(-2.2637311e+04 1.4619727e+04 -2.1195170e-10)
(-1.7855789e+04 1.1508419e+04 4.3090148e-10)
(-1.3354634e+04 8.5602148e+03 1.0028367e-10)
(-9.4187950e+03 5.9335554e+03 1.0023567e-10)
(-6.0659507e+03 3.6396693e+03 1.0580222e-10)
(-2.3673665e+03 1.2227784e+03 -2.2782687e-10)
(2.0266627e+02 -5.1147566e+02 4.4163779e-10)
(2.8118392e+03 -2.1933850e+03 8.8748946e-11)
(5.2693830e+03 -3.6085773e+03 9.5734927e-11)
(7.4786406e+03 -4.9023909e+03 -2.1992691e-10)
(8.7714588e+03 -5.7634902e+03 1.1430596e-10)
(1.1642576e+04 -7.4453310e+03 4.2407699e-10)
(1.2554922e+04 -8.3633375e+03 9.4243655e-11)
(1.3818596e+04 -9.3893909e+03 -2.1447409e-10)
(1.4683254e+04 -9.9843201e+03 4.3210447e-10)
(1.5288847e+04 -1.0376060e+04 8.5562389e-11)
(1.5759140e+04 -1.0627053e+04 1.0328554e-10)
(1.5030568e+04 -1.0164280e+04 9.2815670e-11)
(1.6264292e+04 -1.0712754e+04 1.0141986e-10)
(1.5605004e+04 -1.0318496e+04 -2.2088997e-10)
(1.5180357e+04 -9.9977682e+03 1.1379786e-10)
(1.4402463e+04 -9.5118583e+03 1.2182526e-10)
(1.3358426e+04 -8.8339629e+03 1.0308726e-10)
(1.2172287e+04 -8.0113159e+03 1.0445900e-10)
(9.7231683e+03 -6.4219387e+03 4.2564396e-10)
(9.3100389e+03 -5.8294812e+03 -2.1496764e-10)
(6.8687519e+03 -4.2207301e+03 4.2559866e-10)
(4.8657258e+03 -2.9146481e+03 -2.2306213e-10)
(2.4771809e+03 -1.3972960e+03 1.0712775e-10)
(-1.0318886e+02 3.1648634e+02 4.2585284e-10)
(-2.8404693e+03 2.1298828e+03 8.7367951e-11)
(-6.5413920e+03 4.4139006e+03 -2.2698329e-10)
(-8.6491706e+03 6.0897787e+03 4.2105473e-10)
(-1.2390754e+04 8.4640428e+03 9.8135239e-11)
(-1.5762995e+04 1.0548873e+04 8.2788854e-11)
(-1.9716655e+04 1.2953071e+04 8.9683566e-11)
(-2.3903444e+04 1.5463573e+04 9.1107268e-11)
(-2.8243446e+04 1.8031112e+04 9.5862925e-11)
(-3.1914484e+04 2.0159129e+04 9.6827048e-11)
(-2.8444245e+04 1.7933800e+04 9.8293525e-11)
(-2.3186053e+04 1.4645332e+04 1.0349075e-10)
(-1.8322481e+04 1.1582617e+04 9.1347236e-11)
(-1.3637494e+04 8.6072404e+03 9.2426038e-11)
(-9.5457246e+03 5.9144108e+03 9.6726054e-11)
(-5.8113694e+03 3.4037390e+03 9.9430323e-11)
(-2.5858010e+03 1.1734764e+03 9.3235544e-11)
(2.0219548e+02 -8.0332858e+02 -2.1295959e-10)
(3.2907779e+03 -2.6889343e+03 4.1672272e-10)
(6.1553439e+03 -4.5400633e+03 1.1330826e-10)
(8.3687738e+03 -5.9412763e+03 9.3207308e-11)
(1.0352965e+04 -7.1118285e+03 1.0674283e-10)
(1.2053723e+04 -8.1940825e+03 -2.1170519e-10)
(1.3409468e+04 -9.2290688e+03 4.0978349e-10)
(1.4583128e+04 -1.0044457e+04 8.5548023e-11)
(1.5294044e+04 -1.0473623e+04 9.2165909e-11)
(1.5102534e+04 -1.0412354e+04 -2.0379628e-10)
(1.6308529e+04 -1.0956553e+04 4.1021615e-10)
(1.6137992e+04 -1.0850739e+04 1.0935191e-10)
(1.5923735e+04 -1.0637797e+04 9.3799630e-11)
(1.5588750e+04 -1.0325774e+04 9.9494814e-11)
(1.4924649e+04 -9.8332701e+03 9.3918473e-11)
(1.3949874e+04 -9.2054112e+03 9.9211805e-11)
(1.2916583e+04 -8.3939517e+03 -2.0967013e-10)
(1.1225559e+04 -7.2338527e+03 4.0504226e-10)
(8.3614218e+03 -5.3864539e+03 -2.1274439e-10)
(7.2412375e+03 -4.2539327e+03 4.0970613e-10)
(4.9453117e+03 -2.7157963e+03 9.2372151e-11)
(2.8302579e+03 -1.1621761e+03 9.4399152e-11)
(5.5567267e+02 4.0815378e+02 1.0480883e-10)
(-2.2523665e+03 2.1591890e+03 8.8154402e-11)
(-5.3013583e+03 3.9679844e+03 1.0068581e-10)
(-8.6966796e+03 6.1987368e+03 -2.0930238e-10)
(-1.3482438e+04 9.1995160e+03 1.2126281e-10)
(-1.6978649e+04 1.1363910e+04 4.1703532e-10)
(-2.1131562e+04 1.3970187e+04 -2.1131735e-10)
(-2.5376896e+04 1.6530489e+04 4.1983518e-10)
(-2.9482049e+04 1.9075801e+04 -2.1378190e-10)
(-3.1221902e+04 2.0097750e+04 1.1079507e-10)
(-2.9260789e+04 1.8875428e+04 1.0484990e-10)
(-2.4250435e+04 1.5562413e+04 4.2346593e-10)
(-1.8782643e+04 1.2016705e+04 9.8431233e-11)
(-1.3871209e+04 8.9072025e+03 8.9385059e-11)
(-9.8208665e+03 6.2113556e+03 1.0580067e-10)
(-6.1001423e+03 3.7122354e+03 9.4446792e-11)
(-2.7254552e+03 1.3374421e+03 9.9755594e-11)
(3.9232835e+02 -9.1776459e+02 9.8515357e-11)
(2.9494155e+03 -2.6216524e+03 9.3717156e-11)
(5.5218443e+03 -4.3593734e+03 1.1052636e-10)
Auch das Drehmoment um die z-Achse, welches ich eigentlich zur Verifizierung der Simulation benötigen würde, zeigt (auch nach 200 s) keinen stationären Endwerte, was es eigentlich tun sollte bzw. sollte es nicht derartig schwanken. Code:
(viscous_x viscous_y viscous_z)
(3.9335526e+00 2.0647557e+00 4.3873927e-10)
(3.0222311e+00 2.7374984e+00 1.0637358e-10)
(1.9435845e+00 3.5325199e+00 1.0661563e-10)
(7.2670674e-01 4.4023340e+00 -2.2657154e-10)
(-6.5194306e-01 5.3493944e+00 4.5039350e-10)
(-2.1986191e+00 6.3659528e+00 -2.2677270e-10)
(-3.9534290e+00 7.4701342e+00 4.4181985e-10)
(-5.9745175e+00 8.7167994e+00 1.0322580e-10)
(-8.1207488e+00 1.0025156e+01 1.0366528e-10)
(-9.9147702e+00 1.1102284e+01 9.5679291e-11)
(-1.1251561e+01 1.1870879e+01 -2.1195105e-10)
(-1.2141206e+01 1.2355849e+01 4.3090140e-10)
(-1.2614751e+01 1.2577750e+01 1.0028474e-10)
(-1.2726877e+01 1.2576729e+01 1.0023590e-10)
Daher stelle ich mir die Frage: ist die Simulation so wirklich plausibel und ist das Fließfeld, was ich sehe, auch wirklich das, was theoretisch vorliegt? Der Gedanke ist mir nämlich gekommen, da das Fließfeld genauso aussieht, wie wenn die Wände glatt wären (also ohne Nuten). Rein theoretisch müsste das Geschwindigkeitsfeld nämlich so aussehen, dass das Fluid in die Nuten immer etwas rein und wieder rausfließt. Also nicht in einer Kreisbahn fließt (wie bei glatten Wänden), sondern immer kleine Ausbuchtungen dort aufweist, wo die Nuten liegen. So war es jedenfalls bei einer Simulation, bei der ich die Innenwand glatt gestaltet habe und nur die Außenwand genutet. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 20. Apr. 2021 09:05 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 21. Apr. 2021 09:36 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Also die Skalierung ändert natürlich das Problem in Sinne der Zeitskalen. Faktor 1000 ist dann natürlich schon etwas anders was dazu fährt, dass auch die Fluidinteraktion ändert. Immerhin ist der Spalt wesentlich kleiner. Was mich gerade stuzig macht ist die Tatsache, dass Du laminar rechnest. Hast Du tatsächlich eine laminare Strömung vorliegen? Wenn ich das skaliere und laufen lass, siehts zu Beginn gut aus, bis innerhalb 3 Zeitschritte die Co > 5 geht und dann geht der Zeitschritt in Keller. Ich hab mir das nochmals angeschaut und es ist ein Problem mit dem Druck. Das AMI ist nicht 100 % konservativ (kann Dir aber adhoc nicht sagen, ob es daran liegt). Jedenfalls bekommst Du Druckschwankungen in das System das Dir alles zerstört. Ich teste mal n paar Sachen. ------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 21. Apr. 2021 11:29 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 21. Apr. 2021 11:40 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
|
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 21. Apr. 2021 13:07 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
PIMPLE bringt hier auch nix. Sobald der Zeitschritt größer wird, braucht man weit über 100 äußere Iterationen. Auch momentumPredictor flux correction und anderes hat nicht geholfen. Ich würde als allererstes mal die AMI etwas weiter in die Mitte legen. Ansonsten fällt mir gerade auch nichts ein wie man die "closed-Domain" betrachten sollte. ggf. mal dein Druckpunkt auch wo anders hinlegen. ------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 22. Apr. 2021 08:53 <-- editieren / zitieren --> Unities abgeben:
Hey Tobi, vielen Dank für Deine Zeit und die Antworten! Ich habe das AMI jetzt mal direkt in die Mitte des Spalts gelegt und mit der "größeren" Geometrie die Simulation laufen lassen. Leider springt der Druck immer noch hoch und runter.
Werde dann im nächsten Schritt mal probieren, den Druckpunkt (ich vermute mal, Du meinst pRefCell?) woanders hinzulegen. Mal sehen, ob das etwas bringt. Edit: ja, eigentlich sollte das Fließfeld laminar sein, gerade bei der Drehzahl. Zumal die Anwendung dieses Systems in der Realität auch darauf basiert, dass es ein laminares Fließfeld ist. Falls nicht, dann hätte ich ein ganz anderes Problem [Diese Nachricht wurde von bastipa93 am 22. Apr. 2021 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 22. Apr. 2021 09:37 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Probier mal folgendes: Setz die outer-wall mit fixedValue für p auf 0. Ich kenn mich in Deiner Anwendung jetzt nicht genau aus und daher weiß ich nicht ob diese Annahme korrekt ist aber prinzipiell sollte sich doch überall eine gleiche Druckverteilung ergeben, oder? Wenn Du das machst, dann läuft alles stabil und korrekt. Keine großen Druckschwankungen. Allerdings wäre das Geschwindigkeitsfeld immernoch nicht so wie Du es beschreibst. Nochmals zur Info. Du hast 0.5 rad/s. Das sind circa 4 U/min -> 0.06 u/s (ca. 25 °/s). Also ne sehr kleine Geschwindigkeit. Da Du ein viskoses Fluid hast, sollte das über die Scherung hauptsächlich gehen. Bin da aber nicht so tief drin. Versuch das mal + AMI in die Mitte (mir ist das zu nah an der Wand). Anschließend die Momente prüfen, ob diese in nem Bereich sind, die sinnvoll sind. ------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 22. Apr. 2021 11:02 <-- editieren / zitieren --> Unities abgeben:
Ich habe jetzt mal mein p wie folgt eingestellt, also das p für outerWall auf fixedValue mit uniform 0: Code:
dimensions [0 2 -2 0 0 0 0];
internalField uniform 0;
boundaryField
{
top
{
type empty;
}
bottom
{
type empty;
}
innerWall
{
type zeroGradient;
}
outerWall
{
type fixedValue;
value uniform 0;
}
AMI1
{
type cyclicAMI;
value uniform 0;
}
AMI2
{
type cyclicAMI;
value uniform 0;
}
}
Das AMI habe ich auch in die Mitte gelegt, aber ich bekomme immer noch die gleichen Sprünge im Druck. Habe ich etwas übersehen bzw. war bei Deinen Solutions vielleicht noch etwas anders eingestellt? (Du meintest ja, dass Du etwas mit den momentumPredictors etc ausprobieret hast). Meins sieht so aus: Code:
solvers
{
"(p|pcorr)"
{
solver GAMG;
smoother DICGaussSeidel;
tolerance 1e-06;
relTol 0.1;
}
"(p|pcorr)Final"
{
$p;
tolerance 1e-06;
relTol 0;
}
"(U|k|omega)"
{
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-06;
relTol 0.1;
}
"(U|k|omega)Final"
{
$U;
tolerance 1e-06;
relTol 0;
}
}
PIMPLE
{
momentumPredictor yes;
nOuterCorrectors 3;
nCorrectors 1;
nNonOrthogonalCorrectors 0;
pRefCell 0;
pRefValue 0;
}
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 22. Apr. 2021 11:57 <-- editieren / zitieren --> Unities abgeben:
Ok, also ein bisschen verbessert hat sich die Sache mit dem Druck schon. Derzeit bin ich bei einer reinen Simulationszeit von ca. 15 Sekunden (für das große System). Bevor das mit p = 0 für die outerWall geändert wurde, hat der Druck innerhalb von gut 0.1 Sekunden eine "Schwingung" durchgeführt. Jetzt hat die Frequenz deutlich abgenommen und bis eine Schwingung durch ist, vergehen ca. 0.8 Sekunden. Aber das "Auf und Ab" beim Druck ist immer noch da... Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Shor-ty
Moderator
Beiträge: 2463
Registriert: 27.08.2010 OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)
|
erstellt am: 22. Apr. 2021 12:09 <-- editieren / zitieren --> Unities abgeben: Nur für bastipa93
Also ich hab jetzt keine "Schwingungen" mehr im System. Zu Beginn ist natürlich erstmal die Dynamik zu sehen, dann pendelt es sich ein. Zuvor hatte ich Werte von +- 1e7 Pa (das nicht sein kann). Jetzt sieht man deutlich kleine Werte < 0.005. Damit bin ich eigentlich "satisfied". Deine outerCorrectors bitte auf 1 setzen. Den Momentum-Predictor habe ich ausgeschalten (kann man machen, wenn das System weit genug beim Druck konvergiert ist) - eigentlich hat man den oft nur bei sehr hochviskosen Flüssigkeiten dabei (zur Stabilisierung und besseren Prediction - daher auch »momentumPREDICTOR«). Du kannst auch noch correctPhi in Dein PIMPLE Dict aufnehmen. Wenn Du den MomentumPredictor rausnimmst (false), dann die Toleranz beim deinem p/pcorr auf 1e-8 oder 1e-10 stellen. ------------------
Glück Auf,
Tobi OpenFOAM® Community - Knowledge Base Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
bastipa93
Mitglied
Beiträge: 37
Registriert: 03.02.2021
|
erstellt am: 22. Apr. 2021 13:45 <-- editieren / zitieren --> Unities abgeben:
Irgendwo scheint bei mir der Wurm drin zu sein. Mit den Einstellungen klappt es, wie es aussieht, wohl auch nicht. Wäre es eventuell möglich, dass Du mir nochmals Deinen case zur Verfügung stellst? Dann könnte ich in aller Ruhe jede Datei durchgehen und prüfen, wo es Unterschiede gäbe und das entsprechend anpassen. Natürlich nur, wenn das ok für Dich ist. Edit: Ich weiß nicht, woran es liegt, aber nachdem ich die outerCorrectors auf 1, den momentumPredictor auf false und die Toleranz bei p/pcorr auf 1e-10 gesetzt habe, tauchen in meiner residuals-Datei nicht mehr die Residuen für die Geschwindigkeit auf, sondern nur noch für den Druck. Ich frage mich, ob ich irgendwo an anderer Stelle noch eine Kleinigkeit übersehen habe, die das ganze zerschießt.
[Diese Nachricht wurde von bastipa93 am 22. Apr. 2021 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
 |
Foren auf CAD.de (alle Foren)
| 
