---

rohrgrob.zip

Hallo,

ich bin noch komplett unerfahren, was OF anbelangt und im anliegenden Fall ziemlich ratlos. Zum Einstieg möchte ich eine sich ausbildende laminare Rohrströmung simulieren (d=0.1m, l=0.5m, u_in=0.1m/s in pos. y-Richtung, rho=900kg/m³, mu=0.1 kg/ms). Bisher ist mir leider immer die Courantzahl um die Ohren geflogen, aber ich finde den Ursprung davon nicht heraus. Die BCs erscheinen mir eigentlich richtig und wurden auch bei Onlinebeispielen verwendet. Egal wie klein ich deltaT einstelle oder wie grob das Netz ist, es ändert nichts am Verhalten. icoFoam und pisoFoam zeigen das gleiche Gebaren, selbst mit aktiviertem adjustTimeStep ändert sich in pisoFoam nix, was wirklich seltsam ist. Angehangen ist ein sehr grob vernetztes Rohr (25mm Tetras) mit den verwendeten BCs und sonstigen Einstellungen. Für Faule:

p

Code:

---

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

internalField   uniform 0;

boundaryField
{
    inflow
    {
        type            zeroGradient;
    }

    wall
    {
        type            zeroGradient;
    }

    outflow
    {
        type            fixedValue;
value uniform 0;
    }
}

---

U

Code:

---

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

internalField   uniform (0 0 0);

boundaryField
{
    inflow
    {
        type            fixedValue;
        value           uniform (0 0.1 0);
    }

    wall
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }

    outflow
    {
        type            zeroGradient;
    }
}

---

Der Rest in der ZIP-Datei. Ich nutze OF 4.0 und Ubuntu 16.04 in einer VM, die Testmodelle funktionieren. Erstellt wird das Netz mit Hypermesh 14. In Acusolve und Abaqus funktionieren die erstellten Rohrmodelle mit den gleichen BCs eigentlich. Ich würde mich über Rat freuen, denn ich komme im Moment nicht weiter.

Edit: Ich bin weitergekommen! Mit dem sehr groben Netz (25mm Tetras), den Solvereinstellungen vom Rohrmodel von FOAMHouse und einem deltaT von 0.0005s läuft icoFoam stabil. Mit deltaT=0.005 aber schon nicht mehr! Warum? Die Courantzahl ist damit immer noch weit unter 1, dennoch wächst sie pro Iteration rasant an. Woher kommt das?

Shor-ty: Code-Tages eingefügt

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

---

Hi Ingeniorator,

wie ich sehe bist du bislang nur im Abaqus Forum aktiv gewesen. FEM und FVM ist etwas anders und dadurch bedingt muss das eine nicht auf dem anderen laufen. Ich persönlich hab noch nie Tetraedernetze verwendet (dafür gibt es verschiedene Gründe). IcoFoam oder pisoFoam sind prinzipiell die identischen Solver, nur das beim icoFoam ein anderer Spannungstensor berechnet wird (bzw. anders). In IcoFoam gibt es auch keine dt Steuerung aufgrund der Co Zahl (kann man natürlich dazuprogrammieren wenn man lustig ist). Entsprechend nehm ich diesen Solver auch gar nicht. PisoFoam sollte aufjedenfall funktionieren, mit entsprechenden Einstellungen. Übrigens Co = 1 ist zwar ein Stabilitätskriterium, sodass die Information von einer Zelle nur bis zur nächsten gelangt und nicht darüber hinaus (Explizit-Limitierung), heißt aber noch lange nicht das die Löser bis Co = 1 stabil laufen. Nehm mal 0.3 oder bei deinem Netz ggf. 0.1. Dann sollte das alles funktionieren. Außerdem nimmst du ein recht bescheidenes Diskretisitationsverfahren ** LINEAR ** nimmt man eigentlich nicht.

Außerdem, wenn du dein Korrekturschritte erhöhst, deine Residuals etwas drückst, wirst du sehen, dass es funktioniert (icoFoam dt=0.02).

------------------
Viele Grüße,
Tobias Holzmann

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

---

Hallo,

ja das stimmt, bisher habe ich eher in der FEM gewildert. Könntest du  den Punkt Tetra vs Hexa erläutern? Ich las desöfteren, dass Tetras vor ein paar Jahren Hexas in Sachen Präzision nicht ebenbürtig waren, aber mittlerweile stark aufholen konnten. Vor allem Acusolve nutzt fast nur Tetras - Hypermesh ist natürlich auch dementsprechend auf Tetras ausgelegt. Ich fragte mich allerdings schon, weshalb in den Tutorials von OF eigentlich nur Hexas verwendet werden - der vorherige Satz scheint eher für FEM zu gelten. icoFoam nutzte ich deshalb zuerst, weil es für den Einstieg der einfachste Solver zu sein schien; ich stieß aber schnell auf seine Nachteile.

Irgendwo glaubte ich gelesen zu haben, dass Gauss upwind am stabilsten sei - kommt das hin? Sobald ich etwas bewandter mit OF bin, werde ich die Verfahren alle mal durchtesten und für mich dokumentieren. Jedenfalls vielen Dank für die Antwort, damit kann man arbeiten. Du wirst mich wahrscheinlich die nächste Zeit noch öfter hier sehen 

BTW, gute Arbeit bei deinem Buch. Ich habe zwar schon diverse Literatur angesammelt, darunter auch "The FVM in CFD" von Moukalled et al. samt OF-Teil, aber zum Einstieg und schnellen Nachschlagen gut.

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

---

Hi,

• "The FVM in CFD" von Moukalled hab ich auch seit ein paar Tagen. Ist echt ein sehr gutes Buch. Finde vor allem die Erläuterung der Druck-Geschwindigkeits-Kopplung exzellent.
  
• Numerische Schemen: http://www.holzmann-cfd.de/index.php/de/numerische-schemen - du kannst dir die Arbeit natürlich selber auch machen.
  
• Gauss Upwind ist das einzige Verfahren, dass immer physikalische Ergebnisse liefert, die meisten anderen (ich nehm mal die Limiter Schemes raus) haben oft Werte, die außerhalb des Gültikeitsbereichs liegen.
  
• Tets sind sehr beliebt in der FEM, liegt aber auch daran, dass die FEM eine komplett anderen Aufbau der Numerik hat. Weak-Formulation, Minimierungsprobleme, Realraum transformation zum Referenzraum etc. Das sind komplett andere Berechnungswege wie bei der FVM. Ich hüte mich also da einen direkten Vergleich zu ziehen.
  
• Hex vs Tets ist numerisch bedingt mit nonOrthogonalität etc. Einfach mal etwas nachdenken wie interpoliert wird. Face-Normal to Cell-Center etc.
  
• OpenFOAM kommt auch mit Tetraedernetzen klar, keine Frage. Wäre ja schlimm wenn nicht  aber dein Case hat wenig Netzzellen und bedarf dann etwas erhöhter Aufmerksamkeit bei der Numerik.
  
• Wenn du hier öfter Fragen hast, dann überlass ich die Arbeit mal den Community - Mit - Verwender  ** Spaß.
  
• Übrigens, die FVM hat vorallem daher guten Anklang in der CFD gefunden, da Konservativität für egal welchen Zelltyp. Bei mir hab ich oft, Tets, Polygons, Hexaeder, Pyramiden, Wedges etc. Funktioniert ohne (meistens) Probleme.
  

Danke für das Feedback des Buches. Sind einige Aspekte drin, die man so in der Literatur nicht oft findet aber im Allgemeinen ist es nur ein gutes Nachschlagewerk, da auch nichts neues erfunden worden ist  Jedoch muss ich sagen, es ist immer noch in Arbeit. Arbeite gerade an einer Kurzübersicht bezüglich den SIMPLE, PISO und PIMPLE Algorithmen für FOAM und wie man den PIMPLE verwenden sollte. Kurzum, eine Zusammenfassung und Erweiterung meines Blogs. Natürlich kommt das nicht an Moukalled et al hin  aber dafür hab ich auch nicht die Zeit und meine Freizeit ist eh schon spärlich genug (wobei ich auch nichts sonderlich großartiges in Leoben unternehmen kann).

------------------
Viele Grüße,
Tobias Holzmann

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

---

Danke für die Erläuterung, dann werde ich jetzt mal produktiv!

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

---

So, ich muss nochmal nerven. Mit Gauss upwind kommen eine ganze Menge Fehlermeldungen zum Vorschein. Verwende ich Gauss linear, läuft es wunderbar. Setze ich bei gradSchemes default Gauss upwind, kommt folgendes:

Code:

---

--> FOAM FATAL IO ERROR:
attempt to read beyond EOF

file: /media/sf_shared/rohrersatz/system/fvSchemes.gradSchemes.default at line Time = 0.005

---

-----------------------------------------------------------------

divSchemes Gauss upwind:

Code:

---

sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

fileName::stripInvalid() called for invalid fileName UntitledDocument
    For debug level (= 2) > 1 this is considered fatal
Aborted (core dumped)

---

-----------------------------------------------------------------

Bei laplacianSchemes Gauss (linear)upwind:

Code:

---

--> FOAM FATAL ERROR:

    request for surfaceScalarField corrected from objectRegistry region0 failed
    available objects of type surfaceScalarField are
1(phi)

    From function const Type& Foam: :redface:bjectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>]
    in file /home/openfoam/OpenFOAM/OpenFOAM-4.0/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 193.

FOAM aborting

#0  Foam::error: :tongue:rintStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const& Foam: :redface:bjectRegistry::lookupObject<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> >(Foam::word const&) const at ??:?
#3  Foam::surfaceInterpolationScheme<double>::addMeshConstructorToTable<Foam::linearUpwind<double> >::New(Foam::fvMesh const&, Foam::Istream&)

---

[Diese Nachricht wurde von Ingeniorator am 29. Sep. 2016 editiert.]

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

---

Für den Divergenz Term, musst du

Code:

---

div(U)  Gauss upwind grad(U);

---

Angeben... für den Laplace Term kannst du kein Upwind angeben.

------------------
Viele Grüße,
Tobias Holzmann

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

---

Ach stimmt, lesen hilft. Da hab ich die Terme durcheinander durcheinandergeworfen. Warum aber kommt bei gradSchemes Gauss upwind diese Fehlermeldung, wenn alles andere auf Gauss linear steht?

[Diese Nachricht wurde von Ingeniorator am 29. Sep. 2016 editiert.]

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

---

Zitat:

---

Original erstellt von Ingeniorator:
Ach stimmt, lesen hilft. Da hab ich die Terme durcheinander durcheinandergeworfen. Warum aber kommt bei gradSchemes Gauss upwind diese Fehlermeldung, wenn alles andere auf Gauss linear steht?

---

Bitte neuformulieren, ich versteh deine Aussage gerade nicht. Kurzes Beispiel (Forumsregeln  « schön das ich da jetzt darauf verweisen kann)

------------------
Viele Grüße,
Tobias Holzmann

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

---

Folgendes fvSchemes:

Code:

---

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  2.1.1                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      dictionary;
    location    "system";
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default        Euler;
}

gradSchemes
{
  default        Gauss upwind;
  // grad(p)        Gauss linear;
}

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

laplacianSchemes
{
    default        Gauss linear corrected;
//  laplacian(nu,U) Gauss linear corrected;
  // laplacian((1|A(U)),p) Gauss linear corrected;
}

interpolationSchemes
{
    default        linear;
  //  interpolate(HbyA) linear;
}

snGradSchemes
{
    default        corrected;
}

fluxRequired
{
    default        no;
    p              ;
}

// ************************************************************************* //

---

Dann kommt der Fehler

Code:

---

--> FOAM FATAL IO ERROR:
attempt to read beyond EOF
file: /media/sf_shared/rohrersatz/system/fvSchemes.gradSchemes.default at line Time = 0.005

---

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

---

Joa... es macht keinen Sinn upwind für die Gradienten zu verwenden. Überleg mal wie man den Gradienten bspw. an einem Face berechnet. Dazu nimmt man normalerweise den Wert am Zellmittelpunkt von Zelle 1 und den Wert von Zelle 2 und macht eine Interpolation 2.Ordnung oder wie auch immer. Also der Wert am Face wird durch die zwei Nachbarzellen berechnet (linear oder ein anderes Schemata). Bei Upwind nimmst du aber nur den Wert von einer Zelle. Die Frage ist nun welchen Wert hast du nun auf dem Face. Hmmm. ... schwer oder? Das geht nur mit Hilfe der Information bezüglich den Fluxes. Daher muss das Scheme wie folgt heißen:

Code:

---

gradSchemes
{
    default      Gauss upwind phi;
}

---

Physikalisch macht das aber wenig Sinn. Möglich aber macht man nicht. Daher nimmt man meistens Linear. Da das aber auch zu Problemen führen kann (höhere Werte an den Faces als die benachbarten Zellen), so kann man noch mit cellLimited usw. verfahren. Sprich, es gibt Limiter Verfahren, die das dann verbessern.
Upwind macht nur Sinn beim Konvektionsterm (also beim div(phi,X)), da es die Richtungsinformation mitberücksichtigt (flux -> phi). Dazu kannst du mein Sektion der numerischen Schemen mal anschauen und ich hab eine Zusammenfassung bezüglich der numerischen Methoden II auf meiner HP zum Download bereitgestellt. Vllt wäre es hilfreich da mal nachzulesen.

------------------
Viele Grüße,
Tobias Holzmann

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

---

Super, vielen Dank. Ich sehe, ich habe noch viel zu lernen.

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