---

Hallo liebe Forum-User,

ich hätte da einige Fragen bzgl. OpenFOAM.

In meinem Simulationscase geht es um eine Innenraumdurchströmung eines Fahrzeuges (Greenhouse). Um die Simulation durchzuführen, habe ich mithilfe von Catia V5 die Geometrie in Meter erstellt. Ich habe dazu 3 STL-Dateien erstellt. Einmal die geschlossene Geometrie des Fahrzeuginnenraumes, zum anderen die Inlets (welche nicht nur in eine Richtung geöffnet sind (Defrost, Klimaanlage, etc.)) sowie Outlets.
Die In- und Outlets habe ich "aufgedickt", sodass sie 1mm in die Geometrie des vehicles einragen und ebenfalls in die andere Richtung 1mm herausragen (dieser Hinweis kam von meinem Professor, da es hierbei um eine Bachelorarbeit geht, in der ich eine Validierung der Simulationsergebnisse von OpenFOAM mit den Ergebnissen der Lizenz-Software Star CCM+ durchführen sollte).

Übrigens habe ich als Vorlage das motorBike tutorial verwendet und versuche dieses auf meinen Case umzuschreiben.

Nun aber zum eigentlichem Problem. 

Meine STL-Dateien haben folgende Namen.
inlet.stl [inlet]
outlet.stl [outlet]
motorBike.stl (= Geometrie)[motorBike_CATIASTL]

Dazu habe ich erstmals diese im Editor geöffnet und dort die Patchnamen geändert (oben in den brackets angegeben).

Im SnappyHexMeshDict habe ich folgende Änderungen durchgeführt:

geometry
{
    motorBike.stl
    {
        type triSurfaceMesh;
        name motorBike;
    }
    outlet.stl
    {
        type triSurfaceMesh;
        name outlet;
    }

    inlet.stl
    {
        type triSurfaceMesh;
        name inlet;
    }

    refinementBox
    {
        type searchableBox;
        min (0.2 -0.75 0.0);
        max ( 3.0  0.75 1.4);
    }
};

Nun zu den ersten Fragen:
# Reicht diese Angabe, um die In- und Outlets zu beschreiben?
# Muss ich nicht irgendwo angeben, ob die STL-Dateien eine "patch" oder eine "wall" ist? (U,p,.. -Files ?!)

Sobald ich meine Simulation durchführe ist der Druck und die Geschwindigkeit überall bei 0, was darauf hindeutet, dass nichts ein- bzw. ausströmt.
Der "    locationInMesh (1.71111 0.000001 1.011111); " Punkt ist in meinen Augen richtig gesetzt, da nur der Fahrzeuginnenraum vernetzt wird.

Desweiteren müsste ich mit Volumen- bzw Massenströmen arbeiten, da meine Inlets in verschiedene Richtungen geöffnet sind. Die Geschwindigkeiten würden sich ja mithilfe der Konti-Gleichung ergeben.

# Was muss ich in OpenFOAM ummodellieren damit ich mit einem Volumen- oder Massenstrom und nicht mit einer vorgegebenen Geschwindigkeit anströme?

Ich hoffe ich konnte möglichst genau mein Problem beschreiben.

Würde mich über Lösungsvorschläge freuen. 

Beste Grüße
Robert 

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

---

Hallo Robert und ein herzliches Willkommen im Forum,

deine Fragen zählen zur Sorte "FAQ" deswegen werde ich nicht auf alles detailliert eingehen (Suchfunktion im Forum benutzen oder mal auf meine Homepage schauen -> Tutorials oder andere Tutorials -> FOAM Wikipedia etc.)

Kurz noch zur Formatierung. Im Forum befindet sich ein Code-Tag, mit dem man eine schönere Formatierung hinbekommt:

Code:

---

geometry
{
    motorBike.stl
    {
        type triSurfaceMesh;
        name motorBike;
    }
    outlet.stl
    {
        type triSurfaceMesh;
        name outlet;
    }

---

Damit erleichterst du jedem das Lesen und es ist übersichtlicher. Auch Listen kannst du erstellen. Achte bitte in Zukunft darauf.

Wichtig bei den STL's ist das die Triangulation zwischen den STL's 100% identisch ist (siehe alle Beispiele auf meiner Homepage). Sollten sich die STL's auf planen Ebenen schneiden, dann machts keinen Unterschied. Wenn du die Triangulation schlecht machst, kanns durchaus sein das du bei einem bestimmten Refinementlevel ziemliche Probleme bekommst und dich frägst wieso sHM jetzt solch ein komisches Ergebnis erzeugt (wurde auch schon sehr oft durchgekaut).

Definition von patch / wall / empty / symmetryPlane / wedge etc. befindet sich in constant/polyMesh/boundary. Wall und patch sind gleich nur das für Turbulenzmodelle bei einem type wall automatisch eine RB gesetzt wird, sofern nicht anderes vorgegeben ist. Die STL sind nur Namen deiner Oberflächen die du dann noch mit bestimmten Typen belegen musst. Das machst du aber NICHT mit der STL per se.

Infos dazu sind im User-Guide zu finden (auch Basics und FAQ).

Zitat:

---

Sobald ich meine Simulation durchführe ist der Druck und die Geschwindigkeit überall bei 0, was darauf hindeutet, dass nichts ein- bzw. ausströmt.
Der "    locationInMesh (1.71111 0.000001 1.011111); " Punkt ist in meinen Augen richtig gesetzt, da nur der Fahrzeuginnenraum vernetzt wird.

---

Das hat nicht miteinander zu tun. Zuerst erstellst du dein numerisches Netz und dann simulierst du. Hast du dein numerisches Netz schon mal geprüft (paraview, checkMesh)? Was bedeutet: "Sobald ich die Simulation durchführe ist der Druck und die Geschwindigkeit überall auf 0". Ich nehme an du prüfst das visuell via Paraview, oder? Hast du schon einige Iterationen herausschreiben lassen? Ich gehe davon aus das du simpleFoam verwendest, demnach solltest du Zeitordner (in dem Fall Iterationsordner) in deinem Case haben.

In FOAM musst du nichts ummodellieren, höchstens umprogrammieren ;)
Allerdings sind diese Randbedingungen schon längst alle enthalten und du musst nur noch copy-paste verwenden. In deinem U-File muss eben dann anstatt fixedValue die Randbedingung hin, mit der du den Massenstrom einstellst. Um eine genau Liste der zur Verfügung stehenden Randbedingungen für U einzusehen gib mal anstatt fixedValue ein x-beliebiges Wort ein:

Code:

---

boundary
{
    inlet
    {
        type    foobar;
        value    uniform (0 0 0);
    }
}

---

und starte den Solver. Du wirst eine Fülle von Randbedingungen erhalten.

PS: Die Aufdickung von 1mm versteh ich nicht. Bilder sind oftmals besser als viele Worte, sofern es nicht durch diverse Geheimhaltungsvereinbarung verboten ist.

PPS: OpenFOAM sollte genauso gute Werte liefern wie CCM+ aber du kannst in FOAM eben auch unzählige Fehler machen.

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

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

---

cabin.PNG inoutlet.PNG

Hallo Tobias,

danke für deine schnelle Antwort!

Ich habe jetzt einige Tage und Studen damit verbracht mich tiefer in OpenFOAM einzuarbeiten.

Zu meinem Problem mit dem Einlesen der verschiedenen STL-Dateien. Ich habe mir den "log.SnappyHexMesh" geöffnet und bemerkt, dass nur die geschlossene Geometrie eingelesen wurde obwohl die In- und Outlet-STL-Dateien eigentlich im SnappyHexMesh.Dict korrekt implementiert wurden. Daraufhin habe ich einfach einmal die Reihenfolge geändert. Sprich die geschlossene Geometrie zuletzt und die In- und Outlets davor.

Code:

---

geometry
{
    inlet.stl
    {
        type triSurfaceMesh;
        name inlet;
    }

    outlet.stl
    {
        type triSurfaceMesh;
        name outlet;
    }

    motorBike.stl
    {
        type triSurfaceMesh;
        name motorBike;
    }

    refinementBox
    {
        type searchableBox;
        min (0.2 -0.75 0.0);
        max ( 3.0  0.75 1.4);
    }
};

---

Komischerweise wurden anschließen die In- und Outlets erkannt und es kam zu ersten Simulationsergebnissen!
Spielt die Reihenfolge des Einlesens somit eine Rolle? Nach welchem Kriterium richtet sich dies? Größe der Datei? In- & Outlets immer zuerst?

Mein derzeitiges Problem ist aber noch der gewünschte Volumenstrom.

U:

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      volVectorField;
    location    "0";
    object      U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

#include        "include/initialConditions"

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

internalField  uniform $flowRate; // vorher: $flowVelocity;

boundaryField
{
    #include "include/fixedOutlet"

    "inlet_.*"
    {
    type            flowRateInletVelocity;
    value          uniform ( 0 0 0 );
    }

//    "inlet_.*"
//    {
//        type            zeroGradient;
//       
//    }

    "motorBike_.*"
    {
        type            fixedValue;
        value          uniform (0 0 0);
    }

    #include "include/frontBackUpperPatches"
}

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

---

p:

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      volScalarField;
    object      p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

#include        "include/initialConditions"

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

internalField  uniform $pressure;

boundaryField
{
    #include "include/frontBackUpperPatches"

    "inlet_.*"
    {
        type            fixedValue;
        value          $internalField;
    }

    "outlet_.*"
    {
        type            zeroGradient;
    }

    "motorBike_.*"
    {
        type            zeroGradient;
    }

}

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

---

initialConditions:

Code:

---

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  2.1.1                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/

flowRate        (20 0 0);    // vorher: flowVelocity
pressure            0;
turbulentKE          0.24;
turbulentOmega      1.78;
#inputMode          merge

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

---

Error-Meldung beim log.simpleFoam

Code:

---

Create time

Create mesh for time = 0

Reading field p

Reading field U

--> FOAM FATAL IO ERROR:
keyword flowRate is undefined in dictionary "/home/ESPL_001/ros3124/Bachelorarbeitx/0/U::boundaryField::inlet_.*"

file: /home/ESPL_001/ros3124/Bachelorarbeitx/0/U::boundaryField::inlet_.* from line 30 to line 31.

    From function dictionary::lookupEntry(const word&, bool, bool) const
    in file db/dictionary/dictionary.C at line 400.

FOAM exiting

---

Im Anhang habe ich noch ein paar Bilder eingefügt welche die Geometrie, sowie die In- und Outlets beschreiben (Richtung etc).

Da der Error "flowRate is undefined" ausgiebt gehe ich davon aus, das ich irgendwo noch "flow Rate  x;" angeben muss. Ist dies aber hier nicht schon im File "initialConditions" getan?
Übrigens sollte der Volumenstrom am Inlet angegeben werden.

Beste Grüße,
Robert

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

---

Hallo Robert,

jetzt habe ich mal eine blöde Frage:
Wo soll da was strömen ?
Du definierst die Eingangsrandbedingungen zu null.
Über die internalField definierst du für U für alle Zellen im Simmulationsgebiet einen Startwert von 20m/s in x (wird beim ersten Durchlauf gesetzt).
Das Outlet für U definierst du garnicht.
Beim Druck gibt es auch nur die Definition für null am Eingang.
Wieso soll sich die Luft also bewegen ?
Dein Fehler mit der Definition liegt vermutlich daran, daß du in deinem Ordner 0 kein Unterverzeichnis include hast, in dem die Datei initialConditions steht (ist aber nur eine Vermutung).
Sieh dir doch nochmal deine Randbedingungen an und überlege mal, was Luft dazu bewegen könnte zu strömen.

@Tobias: Oder liege ich hier total falsch ?

Gruß

Torsten

[Diese Nachricht wurde von torty2014 am 15. Okt. 2015 editiert.]

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

---

Hallo Robert,

flowRateInletVelocity benötigt die Angabe der flowRate also direkt in der U-File:

Code:

---

    "inlet_.*"
    {
    type          flowRateInletVelocity;
    flowRate      1.0; // was eben deiner flowRate entspricht
    value        uniform ( 0 0 0 );
    }

---

du kannst dir auch die flowRateInletVelocityFvPatchVectorField.H anschauen für weitere Erklärungen.
Viel Erfolg
Tobi

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

---

Zitat:

---

Original erstellt von torty2014:

@Tobias: Oder lege ich hier total falsch ?

Gruß

Torsten

[Diese Nachricht wurde von torty2014 am 15. Okt. 2015 editiert.]

---

Hey Torsten,

du liegst in diesem Fall nicht falsch. Problem (wie auch die Fehlermeldung schon sagt) ist das das Schlüsselwort für die Flowrate fehlt. Ansonsten kann man allerdings durchaus eine Strömung erzeugen, wenn initial mit 20m/s angegeben wird und die Boundarys entsprechend gesetzt sind; ist hier aber nicht der Fall deswegen hast du Recht.

Die initialConditions sind doch eingebunden. Oberhalb von internalField.

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

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