---

abweichung_dambreak_difcpu.pdf damBreak_cases.tar.gz

Hallo FOAMers,

ich schreibe gerade meine Masterarbeit und verwende OpenFOAM als Simulationstool.
Ich nutze hauptsächlich den InterFOAM solver, da ich mit einen mehrphasigen System arbeite. Meine Berechnungen sind instationär und da ist mir bei meinen Simulationen ein Fehler aufgefallen, den ich mit den damBreak Tutorial (laminar) repoduzieren kann.

Ich habe an den Tutorial nur die ControlDict geändert. Ich lasse mir mit functions eine Geschwindigkeit an einen belieben Knoten auslesen und die Simulation läuft bis 2s.

Code:

---

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

application    interFoam;

startFrom      latestTime;

startTime      0;

stopAt          endTime;

endTime        2;

deltaT          0.001;

writeControl    adjustableRunTime;

writeInterval  0.05;

purgeWrite      0;

writeFormat    ascii;

writePrecision  6;

writeCompression uncompressed;

timeFormat      general;

timePrecision  6;

runTimeModifiable yes;

adjustTimeStep  yes;

maxCo          1;
maxAlphaCo      1;

maxDeltaT      1;

functions
{
    probes
    {
        // Where to load it from
        functionObjectLibs ( "libsampling.so" );

        type            probes;

        // Name of the directory for probe data
        name            probes;

        // Write at same frequency as fields
        outputControl  timeStep;
        outputInterval  1;

        // Fields to be probed
        fields
        (
            U
        );

        probeLocations
        (
(0.414737 0.0419991 0.0146)

        );
    }
}

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

---

Jetzt starte ich die Simulation mit einen, zwei und vier Prozessoren, dabei benutze ich als Dekomposer die Scotch Methode.
Wenn ich die Geschwindigkeiten nun plotte habe ich einen abweichenden Verlauf, den es eigentlich nicht geben dürfte. Ich habe an den Modell nichts verändert. Nur die Anzahl der Kerne wurde variiert. Die Abweichung lässt sich auch in ParaView darstellen.

Die PDF mit den Geschwindigkeitsverläufen findet sich im Anhang sowie die drei Cases.

Meine Frage ist, wie es hier zu den Abweichungen kommt?

Ich habe die CFL-Zahl schon auf 0,1 gestellt und auch mal die Simple-Methode zum Dekomposen benutzt. Das hat leider nichts gebracht. Könnte das vielleicht ein Rundungsfehler sein?

Ich hoffe ihr könnt mir helfen.

Viele Grüße
Fred

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

---

Hallo Fred und willkommen im Forum,

Zitat:

---

Original erstellt von Fred Far:

Wenn ich die Geschwindigkeiten nun plotte habe ich einen abweichenden Verlauf, den es eigentlich nicht geben dürfte.

---

warum darf es solche Fehler denn nicht geben? Ein kurzer Blick in die Sourcen oder noch viel einfacher in Doxygen »Klick Mich« lässt auf die Implementierung von Mapping Funktionen schließen. Alles was Interpoliert wird hat eine gewisse Ungenauigkeit. Daher deine unterschiedlichen Ergebnisse. Die Änderung ist auch ganz klar, wenn man sich die Berechnung anschaut der Werte vergewissert (vorallem der Fluxes).

a) jeder Prozessor berechnet seinen Teil (internalField); geht Problemlos
b) die Boundary Patches sind auch noch problemlos berechenbar
c) die Processor Patches sind aber problematisch

Stell dir dein Case mit einem Prozessor vor. Intern wird phi an jedem internalFace berechnet. Dazu werden die zwei Zellen benötigt, die dieses Face teilen. Soweit ist's glaub klar. Nun kommt das Problem beim Splitten. Man erhält die sogenannten processor patches. Damit hast du also eine neue Boundary und somit ist die Info der nachbarzelle (auch wenn se noch da ist) verloren. Die Zelle ist natürlich in einem anderen Processor aber man muss jetzt eben eine Zwischenlösung finden.

Gefühlt würde ich jetzt folgendes behaupten:

- Ich interpoliere die Geschwindigkeit auf der linke Seite mittels den Infos von processorX
- Ich interpoliere die Geschwindigkeit auf der rechten Seite mittels den Infos von processorY
- Schluss endlich ist der Wert dann irgendwo dazwischen

Das geht alles recht gut solang die Strömung eine bestimmte Richtnug aufweist (Informationsaustausch von prozessor1 zu prozessor2 aber nicht andersrum). Wenn jedoch die Strömung von beiden Seiten kommt, dann muss man eben interpolieren und ein Mittelwert bilden.

Deswegen ist in deinem Fall zu beginn auch alles recht identisch (da die Wassersäule runterfällt und eine gezielte Strömungsrichtung vorgibt. Nachdem das Wasser recht ruhig wird, sich aber viele Wirbel gebildet haben (Informationen von beiden Seiten) kommen die Interpolationen und das Mappen stärker zum Tragen und dann erhältst du diese Fehler.

Apropos (ich denk du weißt das), solch einen Case teilt man nicht auf. Auch keinen Case mit 10.000 Zellen. Man verlangsamt da sowieso nur zwecks Interface-Kommunikation.

PS: Die Schritte zur Interpolation werden wahrscheinlich öfter gemacht, aber da müsste man sich die BC näher anschauen.

Hat also alles seine Richtigkeit.

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

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

---

Hallo Tobias,

vielen Dank für eine sehr ausführliche Antwort. Damit hast du mir sehr weiter geholfen.

Ich habe noch eine weitere Frage bezüglich functions in der controldict.

In meiner controldict habe ich folgende Function zum ausgeben des Volumenstroms über einer facezone die ich mit topoSet erstellt habe.

Code:

---

  Volumenstrom_Spalt
  {
    type                    faceSource;
    functionObjectLibs      ("libfieldFunctionObjects.so");
    enabled                  true;
    outputControl            timeStep;
    outputInterval          1;
    outputControlMode        timeStep;
    log                      true;
    valueOutput              false;
    source                  faceZone;
    sourceName              spalt;
    operation                sum;
   
fields
                (
      phi
                );
  }

---

Das herausgeben des Volumenstromes funktioniert soweit sehr gut und ich bekomme auch plausible Ergebnisse.

Allerdings, wenn ich mein Netz mit refineMesh verfeinere, bekomme ich einen Volumenstrom mit einen negativen Vorzeichen. Wie kann das sein? Wähle ich jetzt mal ein patch als Source, z.B. inlet oder outlet, dann ändert sich das Vorzeichen durch refineMesh nicht.

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

---

Hi,

Ich wiederhole nochmal was du machst, nicht das ich was übersehe:

• Netz erstellen
  
• TopoSet
  
• Simulation -> positiver Volumenstrom
  
• refineMesh
  
• Simulation -> negativer Volumenstrom
  

Falls das so ist, dann dreht refineMesh die normalenvektor um.

Phi negativ wenn rausfliest
Phi positiv wenn reinfliest

Das basiert auf den Normalenvektoren.
Auf patches wie immer, outlet sind se immer nach aussen gerichtet, daher agibta hier kein vorzeichenwechsel.

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

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

---

vielen Dank für deine schnelle Antwort.

Genau das mache ich.

Ich habe auch gerade herausgefunden, dass sich das Vorzeichen nicht ändert, wenn ich nach refineMesh den Befehl renumberMesh ausführe. Dreht sozusagen renumberMesh die Normalenvektoren wieder um? RenumberMesh nutze ich doch eigentlich für Simulationen in parallel oder?

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

---

Hi,

wie die Normalen verteilt sind ist egal. Wichtig ist nur das es konservativ ist. RenumberMesh hat nichts mit parallelen Rechnungen zu tun, es obligt vielleicht eher der Natur das bei parallelen Rechnungen wesentlich mehr Zellen vorliegen und demnach auch das Gleichungssystem größer ist. Ergo die Matrix wird rießiger. RenumberMesh macht nix anderes als die Gleichungen so anzuordnen, um eine möglichst kleines Band zubekommen. Das beinflusst die Suche der Zellnachbarn und somit die Schnelligkeit. Es ist nämlich ein Unterschied ob man eine Schleife 1000000x durchläuft oder nur 340200x.

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

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