Hot News:

Unser Angebot:

  Foren auf CAD.de (alle Foren)
  OpenFOAM
  Einfluss der Ergebnisse durchs Dekomposen?

Antwort erstellen  Neues Thema erstellen
CAD.de Login | Logout | Profil | Profil bearbeiten | Registrieren | Voreinstellungen | Hilfe | Suchen

Anzeige:

Darstellung des Themas zum Ausdrucken. Bitte dann die Druckfunktion des Browsers verwenden. | Suche nach Beiträgen nächster neuer Beitrag | nächster älterer Beitrag
Autor Thema:  Einfluss der Ergebnisse durchs Dekomposen? (2051 / mal gelesen)
Fred Far
Mitglied
Student

Sehen Sie sich das Profil von Fred Far an!   Senden Sie eine Private Message an Fred Far  Schreiben Sie einen Gästebucheintrag für Fred Far

Beiträge: 6
Registriert: 19.05.2016

erstellt am: 19. Mai. 2016 14:23    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities


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

Shor-ty
Moderator





Sehen Sie sich das Profil von Shor-ty an!   Senden Sie eine Private Message an Shor-ty  Schreiben Sie einen Gästebucheintrag für Shor-ty

Beiträge: 2463
Registriert: 27.08.2010

OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)

erstellt am: 23. Mai. 2016 13:44    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Fred Far 10 Unities + Antwort hilfreich

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

Fred Far
Mitglied
Student

Sehen Sie sich das Profil von Fred Far an!   Senden Sie eine Private Message an Fred Far  Schreiben Sie einen Gästebucheintrag für Fred Far

Beiträge: 6
Registriert: 19.05.2016

erstellt am: 23. Mai. 2016 16:35    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

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

Shor-ty
Moderator





Sehen Sie sich das Profil von Shor-ty an!   Senden Sie eine Private Message an Shor-ty  Schreiben Sie einen Gästebucheintrag für Shor-ty

Beiträge: 2463
Registriert: 27.08.2010

OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)

erstellt am: 23. Mai. 2016 17:02    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Fred Far 10 Unities + Antwort hilfreich

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

Fred Far
Mitglied
Student

Sehen Sie sich das Profil von Fred Far an!   Senden Sie eine Private Message an Fred Far  Schreiben Sie einen Gästebucheintrag für Fred Far

Beiträge: 6
Registriert: 19.05.2016

erstellt am: 23. Mai. 2016 17:33    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities

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

Shor-ty
Moderator





Sehen Sie sich das Profil von Shor-ty an!   Senden Sie eine Private Message an Shor-ty  Schreiben Sie einen Gästebucheintrag für Shor-ty

Beiträge: 2463
Registriert: 27.08.2010

OpenFOAM-dev (Foundation)
OpenFOAM-xxxx (ESI)

erstellt am: 23. Mai. 2016 19:05    Editieren oder löschen Sie diesen Beitrag!  <-- editieren / zitieren -->   Antwort mit Zitat in Fett Antwort mit kursivem Zitat    Unities abgeben: 1 Unity (wenig hilfreich, aber dennoch)2 Unities3 Unities4 Unities5 Unities6 Unities7 Unities8 Unities9 Unities10 Unities Nur für Fred Far 10 Unities + Antwort hilfreich

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

Anzeige.:

Anzeige: (Infos zum Werbeplatz >>)

Darstellung des Themas zum Ausdrucken. Bitte dann die Druckfunktion des Browsers verwenden. | Suche nach Beiträgen

nächster neuerer Beitrag | nächster älterer Beitrag
Antwort erstellen


Diesen Beitrag mit Lesezeichen versehen ... | Nach anderen Beiträgen suchen | CAD.de-Newsletter

Administrative Optionen: Beitrag schliessen | Archivieren/Bewegen | Beitrag melden!

Fragen und Anregungen: Kritik-Forum | Neues aus der Community: Community-Forum

(c)2023 CAD.de | Impressum | Datenschutz