---

attachement.zip

Hallo zusammen,
ich bin relativ neu bei OpenFOAM und versuche mich derzeit an folgender Simulation mit dem Solver simpleFoam: ich habe ein koaxiales System bestehend aus einem Innenzylinder (R_i = 12,778 mm) und einem Außenzylinder (R_a = ca. 13,943 mm). Der Innenzylinder ist glatt, der Außenzylinder besitzt axiale Nuten. In dem Spalt zwischen den beiden Zylindern befindet sich ein newtonsches Fluid mit einer Viskosität von ca. 5 Pa*s. Ziel der Simulation ist es, das Moment am Innenzylinder (z-Achse) und das Geschwindigkeitsfeld in radialer Richtung zu erhalten.
Nun zum Problem: ich habe verschiedene Geometrien, die ich simulieren möchte (neun Stück). Bei den ersten drei Simulationen hat alles ohne Probleme geklappt, kein Abstürzen oder sonst etwas. Dann ist bei der 4. Geometrie auf einmal das Problem aufgetaucht, dass es nach einigen (im Bereich von 5000-15000) Zeit- bzw. Iterationsschritten (meist ist ein stationärer Zustand bei ca. t = 35 000 erreicht) auf einmal einen richtigen Sprung im Moment um die y-Achse gegeben hat, was vermutlich darauf zurückzuführen ist, dass das Geschwindigkeitsfeld lokal komplett durchgedreht ist (s. Bilder, einmal vorher, einmal nachher). Die Folge war, dass die Simulation dann irgendwann abgestürzt ist und sich der PC neugestartet hat (vermute ich jedenfalls, denn morgens war der PC dann einfach an, ohne dass irgendwelche Ordner offen gewesen sind). Ich dachte zuerst, dass es am Mesh lag, aber das Mesh war eigentlich komplett in Ordnung (zumindest der Funktion checkMesh nach zu urteilen). Trotzdem habe ich verschiedene Zellgrößen ausprobiert und und und, aber nichts hat geklappt, das Problem besteht immer noch. Verschiedene Foren habe ich natürlich auch schon durchstöbert, aber nicht Passendes gefunden. Daher hoffe ich sehr, dass mir jemand von euch helfen kann!

Kurz zum Vorgehen bei der Simulation (vllt liegt es ja auch in irgendeiner Weise an meinen Befehlen):
- setFields
- decomposePar
- mpirun -np 12 simpleFoam -parallel
- reconstructPar

Da ich wirklich nicht weiß, wo der Fehler liegt, habe ich euch mal den ganzen case angehängt. Das ist denke ich einfacher, als wenn ich die einzelnen Codes hier poste. Falls es speziell zu bestimmten files Fragen gibt und ihr nicht den ganzen Anhang runterladen wollt, kann ich den entsprechenden Code aber gerne auch noch posten!

Viele Grüße
Basti

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

---

Hi,
ich hoffe, Du konntest Dein Problem lösen...
Ich habe mir gerade mal Deine Bilder angesehen und wie Du siehst, geht es voll in die Luft... aber Du meinst, dass an Deinem Mesh alles ok ... außer einem Mesh Problem erinnern mich diese Bilder an Probleme mit den Randbedingungen ... z.B. ich habe viel channel flow cases bearbeitet ... und am Anfang hatte ich solche extremen Sprünge wenn die p/u Randbedingung nicht gepasst haben... zum Beispiel, wenn das Fluid "verdrängt" wurde und eine inlet/outlet Randbedingung gefehlt hat ... daher habe ich mir gerade mal Deine p Randbedingung angesehen... Hier hast Du alles auf zeroGradient gesetzt ... Check mal, ob es etwas bringt, wenn Du die beiden Wände (oben und unten am Kanal) zu inlet/Outlet Randbedingungen machst damit sich im System kein zu hoher Druck aufbauen kann ... GGf hilft es menn Du Dir mal den TJunktion case in den Tutorials ansiehst ...
LG H

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

---

Hallo Hulli,
das werde ich gleich mal probieren, berichte euch dann.
Nur, damit ich das richtig verstanden habe - ich habe jetzt sideX und sideY auf:

type fixedValue;
value uniform 100000;

gesetzt. Das meintest du, oder?

Viele Grüße
Basti

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

---

Inkedt9000_LI.jpg

Hi ja ich denke, dass es side x /y sein müssen ... habe die stl files nicht im ordner gefunden ...
... habe mich mal künstlerisch betätigt    ... ich hoffe es wird so klar

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

---

Leider hat das nichts gebracht   Bei der Simulation gab es die gleichen Probleme. Habe dann versucht, die Seiten top und bottom statt auf noSlip auf zeroGradient zu setzen, aber das hat auch nichts gebracht. Und wenn ich top und bottom auf empty setze, hört simpleFoam nach 1 Iteration auf, weil Konvergenz erreicht wurde   top und bottom sind übrigens auch nur "virtuelle" Wände, weil das Koaxialsystem in der Theorie eigentlich unendlich weit ausgedehnt wäre. Habe die daher erst mit "wall" typisiert und dann auf "slip" gesetzt, was ja eigentlich die ganze Zeit super funktioniert hat!

Habt ihr vielleicht sonst noch welche Tipps?   Hier einmal vielleicht die wichtigsten Codes:

p

Code:

---

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 0;

boundaryField
{
    top
    {
        type            zeroGradient;
    }
    bottom
    {
        type            zeroGradient;
    }
    innerWall
    {
        type            zeroGradient;
    }
    outerWall
    {
        type            zeroGradient;
    }
    sideX
    {
        type            fixedValue;
        value           uniform 0;
    }
    sideY
    {
        type            fixedValue;
        value           uniform 0;
    }
}

---

U

Code:

---

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
    bottom
    {
        type            zeroGradient;
    }
    top
    {
        type            zeroGradient;
    }
    sideX
    {
        type            zeroGradient;
    }
    sideY
    {
type zeroGradient;
    }
    innerWall
    {
type rotatingWallVelocity;
origin (0 0 0);
axis (0 0 1);
        omega           constant 0.213926751;
    }
    outerWall
    {
type noSlip;
    }
}

---

fvSolution

Code:

---

solvers
{
    p
    {
        solver          GAMG;
        tolerance       1e68;
        relTol          0.1;
        smoother        GaussSeidel;
nPreSweeps 0;
nPostSweeps 2;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

    U
    {
        solver          smoothSolver;
        smoother        GaussSeidel;
        nSweeps         2;
        tolerance       1e-20;
        relTol          0.1;
    }
}

SIMPLE
{
    nNonOrthogonalCorrectors 0;
    pRefCell 0;
    pRefValue 0;
    residualControl
    {
p 1e-2;
U 1e-3;
    }
}

relaxationFactors
{
    fields
    {
        p               0.2;
    }
    equations
    {
        U               0.4;
    }
}

---

fvSchemes

Code:

---

ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default         Gauss linear;
}

divSchemes
{
    default         Gauss linear;
    div(phi,U)      Gauss limitedLinearV 1;
}

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

fluxRequired
{
    default         no;
    p               ;
}

---

boundary File aus dem polyMesh

Code:

---

6
(
    top
    {
        type            patch;
        inGroups        1(patch);
        nFaces          51240;
        startFace       6313646;
    }
    bottom
    {
        type            patch;
        inGroups        1(patch);
        nFaces          50956;
        startFace       6364886;
    }
    innerWall
    {
        type            rotatingWallVelocity;
        inGroups        1(wall);
        nFaces          42000;
        startFace       6415842;
    }
    outerWall
    {
        type            wall;
        inGroups        1(wall);
        nFaces          62872;
        startFace       6457842;
    }
    sideX
    {
        type            patch;
        inGroups        1(patch);
        nFaces          2520;
        startFace       6520714;
    }
    sideY
    {
        type            patch;
        inGroups        1(patch);
        nFaces          2520;
        startFace       6523234;
    }
)

---

Würde mich echt freuen, wenn euch irgendetwas auffällt oder ihr Tipps habt. Sitze da schon seit gut 2 Wochen dran und versuche alles mögliche, aber irgendwie... Weiß nur nicht, ob es nicht vielleicht doch am Mesh liegt, weil die Simulationen davor ja alle geklappt haben, nur eben nicht, als ich eine andere Geometrie implementiert habe. Aber checkMesh ergibt, dass das Mesh OK ist, ohne einen einzigen Error.

[Diese Nachricht wurde von bastipa93 am 04. Feb. 2021 editiert.]

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

---

... was mir auf die schnelle einfällt wäre ein vereinfachen case zu bauen ... sprich ähnlich dem cavity case ... und dann Deine Settings testen ... dann könntest Du herausfinden ob die BC passen oder ob doch das Mesh schuld ist ... was hast Du denn zu den funktionierende cases verändert ??? 

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

---

Ja, ich habe auch bemerkt, dass ich mein mesh gar nicht so "hoch" bauen muss, weil mich die Geschwindigkeit sowieso nur in x-y-Richtung interessiert. Daher werde ich das schonmal vereinfachen.

Den cavity case schaue ich mir auch mal an, den kenne ich noch nicht.

Das EINZIGE was ich wirklich verändert habe, war das mesh. Habe einfach über SHM ein neues Mesh generiert und entsprechend im polyMesh-Ordner bei constant eingefügt. Den Rest habe ich so gelassen, wie vorher. Ich gehe mal davon aus, dass die Simulation vorher auch nicht bei noch höheren Laufzeiten abgestürzt wäre, denn die Iteration lief bis >60.000 Schritte und ich hatte schon ein konstantes Drehmoment bei ca. 35.000 Schritten. Habe die Simulationen dann immer nur bis 40.000 laufen lassen und alles war gut, die simulierten Drehmomente haben auch gut mit den praktischen Ergebnissen übereingestimmt. Und dann kamen die anderen Meshs (die haben ein anderes Nut/Steg-Verhältnis, doppelt so groß wie vorher) und dann hat nichts mehr geklappt...

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

---

Ich habe jetzt mal analog zum cavity Fall die Seite sideX und sideY (also die, die du richtig in deinem Gemälde markiert hast  ) auf empty gesetzt und den Rest entsprechend auch angepasst. Die Codes sehen so aus:

Druck p

Code:

---

dimensions      [0 2 -2 0 0 0 0];

internalField  uniform 0;

boundaryField
{
    top
    {
        type            zeroGradient;
    }
    bottom
    {
        type            zeroGradient;
    }
    innerWall
    {
        type            zeroGradient;
    }
    outerWall
    {
        type            zeroGradient;
    }
    sideX
    {
        type            empty;
    }
    sideY
    {
        type            empty;
    }
}

---

Geschwindigkeit U

Code:

---

dimensions      [0 1 -1 0 0 0 0];

internalField  uniform (0 0 0);

boundaryField
{
    bottom
    {
        type            slip;
    }
    top
    {
        type            slip;
    }
    sideX
    {
        type            empty;
    }
    sideY
    {
type empty;
    }
    innerWall
    {
type rotatingWallVelocity;
origin (0 0 0);
axis (0 0 1);
        omega          constant 0.213926751; //halbe Winkelgeschwindigkeit bei gamma = 5,17 1/s
    }
    outerWall
    {
type noSlip;
    }
}

---

Allerdings spuckt der mir jetzt einen anderen Fehler aus, mit dem ich nichts wirklich anfangen kann. Du/ihr vielleicht?

Code:

---

[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] Continuity error cannot be removed by adjusting the outflow.
Please check the velocity boundary conditions and/or run potentialFoam to initialise the outflow.
Total flux              : 1e-300
Specified mass inflow  : 4.22235e-25
Specified mass outflow  : 4.28928e-25
Adjustable mass outflow : 0
[1]
[1]
[1]    From function bool Foam::adjustPhi(Foam::surfaceScalarField&, const volVectorField&, Foam::volScalarField&)
[1]    in file cfdTools/general/adjustPhi/adjustPhi.C at line 110.
[1]
FOAM parallel run exiting
[1]

---

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

---

Interessant, den Fehler hatte ich bislang noch nicht.

Scheint als wäre bei dir die Konti-Gleichung nicht erfüllt, was wohl durch falsche Randbedingungen hervorgerufen wird.

Ich weiß nicht genau, wie deine Zuordnung der Randbedingungen ist, aber so wie ich es verstanden habe sind sideX und sideY deine Einlass bzw Auslass links und rechts? Wieso hast du die denn auf empty gesetzt? Wenn du quasi 2D rechnen willst, müsstest du glaube ich die obere und untere Seite auf empty setzen.

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

---

Habe die Analogie zu meinem Fall wohl nicht ganz richtig verstanden und dann die falschen Seiten auf empty gesetzt. Habe jetzt aber mal top und bottom auf empty gesetzt und nach ca. 16000 Iterationen folgenden Fehler erhalten:

Code:

---

[10] #0  Foam::error: rintStack(Foam::Ostream&)sh: 1: addr2line: not found
addr2line failed
[10] #1  Foam::sigSegv::sigHandler(int)sh: 1: addr2line: not found
addr2line failed
[10] #2  ?sh: 1: addr2line: not found
addr2line failed
[10] #3  Foam::fv::gaussGrad<Foam::Vector<double> >::gradf(Foam::GeometricField<Foam::Vector<double>, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::word const&)sh: 1: addr2line: not found
addr2line failed
[10] #4  Foam::fv::gaussGrad<Foam::Vector<double> >::calcGrad(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::word const&) constsh: 1: addr2line: not found
addr2line failed
[10] #5  Foam::fv::gradScheme<Foam::Vector<double> >::grad(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::word const&) constsh: 1: addr2line: not found
addr2line failed
[10] #6  Foam::tmp<Foam::GeometricField<Foam: uterProduct<Foam::Vector<double>, Foam::Vector<double> >::type, Foam::fvPatchField, Foam::volMesh> > Foam::fvc::grad<Foam::Vector<double> >(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&)sh: 1: addr2line: not found
addr2line failed
[10] #7  Foam::linearViscousStress<Foam::laminarModel<Foam::IncompressibleTurbulenceModel<Foam::transportModel> > >::DevRhoReff() constsh: 1: addr2line: not found
addr2line failed
[10] #8  Foam::IncompressibleTurbulenceModel<Foam::transportModel>::DevReff() constsh: 1: addr2line: not found
addr2line failed
[10] #9  Foam::functionObjects::forces::DevRhoReff() constsh: 1: addr2line: not found
addr2line failed
[10] #10  Foam::functionObjects::forces::calcForcesMoment()sh: 1: addr2line: not found
addr2line failed
[10] #11  Foam::functionObjects::forces::execute()sh: 1: addr2line: not found
addr2line failed
[10] #12  Foam::functionObjects::timeControl::execute()sh: 1: addr2line: not found
addr2line failed
[10] #13  Foam::functionObjectList::execute()sh: 1: addr2line: not found
addr2line failed
[10] #14  Foam::Time::run() constsh: 1: addr2line: not found
addr2line failed
[10] #15  Foam::Time::loop()sh: 1: addr2line: not found
addr2line failed
[10] #16  Foam::simpleControl::loop()sh: 1: addr2line: not found
addr2line failed
[10] #17  ?sh: 1: addr2line: not found
addr2line failed
[10] #18  __libc_start_mainsh: 1: addr2line: not found
addr2line failed
[10] #19  ?sh: 1: addr2line: not found
addr2line failed
[DESKTOP-3IFQ04O:00538] *** Process received signal ***
[DESKTOP-3IFQ04O:00538] Signal: Segmentation fault (11)
[DESKTOP-3IFQ04O:00538] Signal code:  (-6)
[DESKTOP-3IFQ04O:00538] Failing at address: 0x3e80000021a
[DESKTOP-3IFQ04O:00538] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x46210)[0x7fc91d356210]
[DESKTOP-3IFQ04O:00538] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7fc91d35618b]
[DESKTOP-3IFQ04O:00538] [ 2] /lib/x86_64-linux-gnu/libc.so.6(+0x46210)[0x7fc91d356210]
[DESKTOP-3IFQ04O:00538] [ 3] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam2fv9gaussGradINS_6VectorIdEEE5gradfERKNS_14GeometricFieldIS3_NS_13fvsPatchFieldENS_11surfaceMeshEEERKNS_4wordE+0x33b)[0x7fc921fd694b]
[DESKTOP-3IFQ04O:00538] [ 4] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZNK4Foam2fv9gaussGradINS_6VectorIdEEE8calcGradERKNS_14GeometricFieldIS3_NS_12fvPatchFieldENS_7volMeshEEERKNS_4wordE+0x4f)[0x7fc921fd6e4f]
[DESKTOP-3IFQ04O:00538] [ 5] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZNK4Foam2fv10gradSchemeINS_6VectorIdEEE4gradERKNS_14GeometricFieldIS3_NS_12fvPatchFieldENS_7volMeshEEERKNS_4wordE+0x1a5)[0x7fc921cc5a25]
[DESKTOP-3IFQ04O:00538] [ 6] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam3fvc4gradINS_6VectorIdEEEENS_3tmpINS_14GeometricFieldINS_12outerProductIS3_T_E4typeENS_12fvPatchFieldENS_7volMeshEEEEERKNS5_IS7_SA_SB_EE+0xa7)[0x7fc921cee837]
[DESKTOP-3IFQ04O:00538] [ 7] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libincompressibleTurbulenceModels.so(_ZNK4Foam19linearViscousStressINS_12laminarModelINS_29IncompressibleTurbulenceModelINS_14transportModelEEEEEE10devRhoReffEv+0x141)[0x7fc91f094691]
[DESKTOP-3IFQ04O:00538] [ 8] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libincompressibleTurbulenceModels.so(_ZNK4Foam29IncompressibleTurbulenceModelINS_14transportModelEE7devReffEv+0xd)[0x7fc91efdc07d]
[DESKTOP-3IFQ04O:00538] [ 9] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libforces.so(_ZNK4Foam15functionObjects6forces10devRhoReffEv+0xcc)[0x7fc900e668fc]
[DESKTOP-3IFQ04O:00538] [10] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libforces.so(_ZN4Foam15functionObjects6forces16calcForcesMomentEv+0x1972)[0x7fc900e68b62]
[DESKTOP-3IFQ04O:00538] [11] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libforces.so(_ZN4Foam15functionObjects6forces7executeEv+0x11)[0x7fc900e64861]
[DESKTOP-3IFQ04O:00538] [12] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x52)[0x7fc91e14ccc2]
[DESKTOP-3IFQ04O:00538] [13] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x13c)[0x7fc91e13d86c]
[DESKTOP-3IFQ04O:00538] [14] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam4Time3runEv+0xaf)[0x7fc91e15864f]
[DESKTOP-3IFQ04O:00538] [15] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam4Time4loopEv+0x12)[0x7fc91e158912]
[DESKTOP-3IFQ04O:00538] [16] /home/spawelcz/OpenFOAM/OpenFOAM-v1912/platforms/linux64Gcc63DPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam13simpleControl4loopEv+0x75)[0x7fc9220bfc85]
[DESKTOP-3IFQ04O:00538] [17] simpleFoam[0x42181c]
[DESKTOP-3IFQ04O:00538] [18] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fc91d3370b3]
[DESKTOP-3IFQ04O:00538] [19] simpleFoam[0x425ca1]
[DESKTOP-3IFQ04O:00538] *** End of error message ***

---

Könnte es bei diesem Fehler etwas bringen, in fvSchemes das gradScheme zu ändern? Habe da derzeit Gauss linear drin, bzw. folgendes:

Code:

---

ddtSchemes
{
    default        steadyState;
}

gradSchemes
{
    default        Gauss linear;
}

divSchemes
{
    default        Gauss linear;
    div(phi,U)      Gauss limitedLinearV 1;
}

laplacianSchemes
{
    default        Gauss linear corrected;
}

interpolationSchemes
{
    default        linear;
}

snGradSchemes
{
    default        corrected;
}

fluxRequired
{
    default        no;
    p              ;
}

---

Es tauchen einfach immer wieder Fehlermeldungen auf und ich hab keine Ahnung, weshalb 

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

---

Zitat:

---

Original erstellt von Friendly:
Interessant, den Fehler hatte ich bislang noch nicht.

Scheint als wäre bei dir die Konti-Gleichung nicht erfüllt, was wohl durch falsche Randbedingungen hervorgerufen wird.

Ich weiß nicht genau, wie deine Zuordnung der Randbedingungen ist, aber so wie ich es verstanden habe sind sideX und sideY deine Einlass bzw Auslass links und rechts? Wieso hast du die denn auf empty gesetzt? Wenn du quasi 2D rechnen willst, müsstest du glaube ich die obere und untere Seite auf empty setzen.

---

Das ist kein Fehler sondern das System wurde mit Randbedingungen belegt, die keine Lösung ergeben können (Können also unendlich viele sein).

Solltet Ihr nicht weiterkommen, könnt Ihr mich gerne dazuholen. Ich löse dann für euch auf 

------------------
Glück Auf,
Tobi

OpenFOAM® Community - Knowledge Base

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

---

Hi, also ich hatte den Fehler eigentlich, nur wenn die Randbedingungen nicht richtig gesetzt waren und mehr Fluid ins System hereinkam als wieder raus ... Soweit ich mich erinnere, waren meistens die Settings im p Feld das Böse ...
Nun gut um das ganze zu debuggen würde ich vorschlagen Du nimmst den Motorbike case zur Hilfe. Dazu würde ich so vorgehen:

- Motorbike case von Tutorials in Dein Arbeitsverzeichnis kopieren
- Case anpassen damit der ohne allrun Skript lauft bzw. das stl für das motorbike in constant/trisurface kopieren
- nu auf 1e-6 setzen, falls Du Wasser simulieren willst in den transportproperties
- Rechen lassen blockMesh | surfaceFeatureextract | snappyHexmesh | simpleFoam oder pimpleFoam
- hoffen, dass alles geklappt hat

Deinen Case an den Motorbike case anpassen
-  snappyHexmesh des Motorbike cases anpassen bzw. copypaste Deines snappyHexmeshDict files anstelle dessen aus dem Motorbike case
- Randbedingungen auf die Bezeichnungen Deiner patches  im 0 folder anpassen also U p und nut. Ich meine alles ergänzen, was Dir  an Randbedingungen noch fehlt, die Du zusätzlich benötigst um Deune komplexe Geometrie mit Randbedingungen zu definieren snappyHexmeshes ... sonst würde ich da gar nichts mehr ändern... und dann rechnen lassen.
- ggf musst Du den solver anpassen und nach simpleFoam umstellen

Die idee dahinter ist einfach Deine Geometire mit den settings eines existierenden tutorial cases zuverheiraten ... Damit setellst Du sicher dass die scemes Randbedingungen etc. halbwegs vernünftig eingestellt sind und das Ding nicht gleich explodiert ...
Falls Dir der Motorbike case zu blöde ist kannst Du Dir auch den case channel396 in den Tutorials ansehen und die zyklischen Randbedingungen mit inlet outlet Randbedingungen ersetzen wie im Motorbike case.

Ich weiß, es nervt ohne Ende aber Du schaffst das ... LG H

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

---

Kleines Update: mein Mesh wurde jetzt mit kommerzieller Software einmal generiert statt mit snappyHex und siehe da, alles konvergiert wunderbar. Jetzt stellt sich mir jedoch die Frage, warum OpenFOAM dann bei checkMesh anzeigt, dass alles in Ordnung ist...  aber gut. Ich habe noch einen anderen Ansatz, bei dem ich in fvSchemes ein paar Einstellungen geändert habe (im Wesentlichen das fvSchemes aus dem cavity-Fall übernommen nur bei divSchemes "Gauss linear" anstelle von "none" eingetragen, weil der gemeckert hatte) und gleichzeitig die Höhe in z-Richtung von 0,5 mm auf 0,05 mm reduziert habe. Und da siehts momentan eigentlich auch ganz ok aus.

@hulli1: den motorBike Fall habe ich mir mal kurz angeschaut. Dort wird aber mit einem Turbulenzmodell gerechnet, was bei mir ja nicht der Fall ist. Daher war ich da erstmal zu faul, alles einzustellen und zu gucken, ob das überhaupt etwas wird 

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

---

Okay, mit einer Geometrie hat es mit dem neuen Mesh geklappt, mit der anderen jetzt wieder nicht. Gleicher Fehler, irgendwann entstehen punktuell extrem hohe Geschwindigkeiten. Jetzt weiß ich nun wirklich nicht mehr weiter, denn mit den Randbedingungen etc. habe ich schon rumgespielt...
@Shor-ty: könntest du da eventuell weiterhelfen?

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

---

Du sagst, dass das Du Probleme mit einem snappyHexMesh hast? Kannst Du das mal zur Verfügung stellen?

------------------
Glück Auf,
Tobi

OpenFOAM® Community - Knowledge Base

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

---

mesh.zip

Ob das ein Problem bedingt durch das snappyHexMesh war oder durch die Simulation weiß ich leider nicht. Habe es jetzt so hinbekommen, dass ich die entsprechenden timesteps, bei denen es einen Geschwindigkeitssprung gab (habe festgestellt, dass die residuals einen Sprung nach oben um ca. 2 Dekaden gemacht haben) gelöscht und die Simulation dort angefangen, wo der Fehler noch nicht aufgetreten ist. Hat dann im Großen und Ganzen eigentlich gut funktioniert und die Ergebnisse sind auch sehr plausibel!

Im Anhang kannst Du aber dennoch das snappyHexMesh (bzw. die Dateien dafür, das war zu groß, um es hier hochzuladen) vorfinden. checkMesh sagt, dass alles in Ordnung ist und das mesh sieht meiner Meinung nach auch OK aus. Vielleicht findest Du ja trotzdem irgendeine Schwachstelle, die ich übersehen habe 

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

---

Kannst Du mir mal verraten was das ist?

constant/polyMesh/boundaries

Code:

---

    innerWall
    {
        type            rotatingWallVelocity;
        inGroups        1(wall);
        nFaces          42000;
        startFace      6415842;
    }

---

Solch einen Typ gibts nicht. Scheint so, als könne man da wirklich eintragen was man möchte. Sehr merkwürdig. Das ist hier eine »wall«.

------------------
Glück Auf,
Tobi

OpenFOAM® Community - Knowledge Base

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

---

Das rührt daher, dass ich das von einem ähnlichen Fall übernommen habe und zu faul war, das zu ändern  Aber ja, wie Du schon sagtest, es müsste eigentlich zur wall typisiert werden.

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