---

Moin,

ich hänge gerade an der Simulation eine 2D Kreiselpumpe. Dazu habe ich alte Daten der OF Version 2.1 vorliegen und wollte die Einstellungen auf Version 2.3.1 übertragen. Es geht also um cyclicAMI Flächen bei Rotor/Stator interaktionen.

Im stationären SimpleFoam Solver entsprechen die Ergebnisse auch den Erwartungen (Verluste zwischen 0.02% und 0.06%), aber im instationären pimpleDyMFoam Solver verliere ich an den AMI Flächen etwa 2% meines Massenstromes.

zum Vergleich: Unter OF 2.1 beträgt der Verlust unter pimpleDyMFoam etwa 0,02 %

Ich verwende für die SImulationen jeweils das selbe Gitter und Einstellungen. Lediglich die Definiton der Rotationsgeschwindigkeit hat sich in der neueren Version verändert. Desweiteren scheint sich das kwSST Modell in OF 2.3.1 anders zu Verhalten, da die Residuen deutlich schneller abfallen als noch unter OF 2.1.

Frage:

Hat jemand ähnliche Beobachtungen gemacht oder weiß zufällig jemand ob sich etwas gravierendes an instationären cyclicAMI Simulationen geändert hat?

------------------
Gruß
Jens

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

---

AMI und Stationär? Kannst du mir da nen Paper nennen, oder deine Gleichungen geben. Das würde mich sehr interessieren, da ich diesbezüglich noch nichts gelesen habe.

AMI hat sich für mich seit 2.1 nicht verändert. Wie berechnest du denn deinen Massenstrom am Interface? Mit ner Function in controlDict?

------------------
Best regards,
Tobias Holzmann

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

---

Moin Tobias,

also nen paper habe ich dazu leider nicht so richtig. Dem ganzen liegt ein öffentlicher Fall zugrunde "Sig Turbomachinery / ERCOFTAC centrifugal pump with a vaned diffuser"

ERCOFTAC centrifugal pump with a vaned diffuser

Damals war es noch OF 1.5 dev  mit GGI Flächen welches in der Quelle [18] verwendet wurde. Das wurde in der mir vorliegenden Arbeit mit OF 2.1 und AMI Flächen nachgestellt. Und meine Aufgabe ist es nun eben mit 2.3.1.
Das klappt soweit auch ganz gut, bis auf den Massenstromverlust.

AMI im stationären Solver wird in der boundary Datei und bei allen Strömungsgrößen bei allen AMI Flächen festgelegt und die Informationen welche CellZone sich mit bestimmter Rotationsgeschwindigkeit dreht wird in der "fvOptions" (damals MRFZones) definiert.

Zur Ausgabe des Massenstromes habe ich die swak4Foam Bibliothek verwendet und die entsprechenden Zeilen in der controlDict angefügt. An der Bibliothek liegt es aber nich, da "patchIntegrate phi outlet" und die sum Funktion in der controlDict die gleichen Daten liefert.

Dann wird das ganze in zwei verschiedenen Bezugssystemen gerechnet und die Strömungsgrößen an den AMI Flächen interpoliert übergeben.

------------------
Gruß
Jens

Von Shor-ty bearbeitet; Grund: Formatierung

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

---

Hallo,

zur Info: also unsere Erfahrung mit AMI ist (d.h. vor allem die Stabilität betreffend, sliding meshes für rotierende Anwendungen), dass es in Version 2.1 recht gut funktionierte, in 2.2 hatten wir zeitweise (d.h. je nach git-update) erhebliche Stabilitätsprobleme, seit 2.3 läuft es dann sehr stabil. Auch die ständigen Änderungen, die im Git-Update hereinkamen, deuteten darauf hin, dass AMI in 2.2 kontinuierlich erheblich überarbeitete wurde. Ich würde zur Version 2.3 raten.
Gruß

Ulrich

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

---

Zitat:

---

Original erstellt von Ulrich Heck:
Hallo,

zur Info: also unsere Erfahrung mit AMI ist (d.h. vor allem die Stabilität betreffend, sliding meshes für rotierende Anwendungen), dass es in Version 2.1 recht gut funktionierte, in 2.2 hatten wir zeitweise (d.h. je nach git-update) erhebliche Stabilitätsprobleme, seit 2.3 läuft es dann sehr stabil. Auch die ständigen Änderungen, die im Git-Update hereinkamen, deuteten darauf hin, dass AMI in 2.2 kontinuierlich erheblich überarbeitete wurde. Ich würde zur Version 2.3 raten.
Gruß

Ulrich

---

Hallo Ulrich,
danke für die Info. Gut zu wissen, da ich mit AMI nur sporadisch arbeite.
Bitte korrigiere (da du ja mehr Erfahrung als ich habe) mich im oben genannten Beitrag, sofern ich da was falsch sehe.

------------------
Best regards,
Tobias Holzmann

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

---

also in der "fvOptions" ist es MRFSource als type. (Entsprechend der alten MRFZones Datei)

Code:

---

MRF1
{
    type            MRFSource;
    active          true;
    selectionMode   cellZone;
    cellZone        rotor;

    MRFSourceCoeffs
    {
        nonRotatingPatches (INNER_AMI_INT OUTER_AMI_INT);
        origin      (0 0 0);
        axis        (0 0 -1);
        omega      209.44;
    }
}

---

Aber bei den Definitionen der Strömungsgrößen werden alle Übergabeflächen mit dem type "cyclicAMI" definiert.

Code:

---

    "(INNER_AMI_INT|INNER_AMI_EXT|OUTER_AMI_INT|OUTER_AMI_EXT)"
    {
        type            cyclicAMI;
        value           $internalField;
    }

---

Das funktioniert soweit. Auch wenns dazu vllt kein offizielles Tutorial gibt. Mein Problem liegt ja eher beim pimpleDyMFoam Solver, bei dem eben 2% meiner Strömung verschwinden.

(Nachtrag: Also stabil laufen bei mir beide Versionen 2.1 und 2.3.1. Unterschiede sind die schneller fallenden Residuen und die Verluste im Massenstrom. Ansonsten habe ich keine weiteren Unterschiede feststellen können.)

[Diese Nachricht wurde von JensHa am 08. Apr. 2015 editiert.]

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

---

Hallo Jens,

für MRF braucht man das Interface nicht zu definieren, die Angabe der Zone reicht. D.h. hier ist auch kein AMI erforderlich.

Bzgl. des Massenverlust über AMI:
- Ist der abhängig von Co?
- Welche Schemes verwendest Du für div (phi,U)?
- Verwendest Du correctPhi im PIMPLE?

Gruß

Ulrich

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

---

Also da müsste ich nochmal schauen, da ich drei einzelne Gitter vorliegend habe. Bin ja froh, dass OF nicht meckert mit meiner cyclicAMI Definition.

Zu den weiteren Punkten:

- Die Verluste treten bei niedrigen Zeitschrittweiten und auch bei höheren auf. (Comax=0,1 und Comax=1)
- div(phi,U)      Gauss linearUpwind grad(U);
- Nein, weder bei OF 2.1 noch bei 2.3.1! Es sind auch sonst alle Einstellungen übernommen mit ausnahme von:

Code:

---

dynamicFvMesh   solidBodyMotionFvMesh;

motionSolverLibs ( "libfvMotionSolvers.so" );

solidBodyMotionFvMeshCoeffs
{
    cellZone        rotor;

    solidBodyMotionFunction  rotatingMotion;
    rotatingMotionCoeffs
    {
        origin      (0 0 0);   // Cofg (0 0 0); OF 2.1
        axis        (0 0 -1);  // kein Eintrag bei OF 2.1
        omega      209.44;     // radialVelocity (0 0 -12000);  OF 2.1
    }
}

---

Würdest du mir raten nochmal correctPhi zu testen ?

Gruß

------------------
Gruß
Jens

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

---

Hallo Jens,

hab da wohl was falsch verstanden. Du verwendest ja AMI doch im transienten Solver.
Hast du schon mal mittels pyFoam die Massenerhaltung betrachtet? Kannst auch mittels Gnuplot und einer Logdatei machen.
Hier dürftest du dann auch sehen, dass die Massenerhaltung nicht stimmt, bzw. du ein kummulativen Zuwachs oder eine Abnahme hast.

PS: Ich würde dir zu correctPhi raten, da hier die Fluxes nach einer Netzänderung neu berechnet werden.

• Faces an den Patches werden behandelt
  
• Druck wird neu berechnet
  
• Update der fluxes
  

Anderenfalls fällt das alles aus deiner Rechnung raus. Kann mir durchaus vorstellen, dass du deswegen einen Fehler in der Massenerhaltung bekommst.

------------------
Best regards,
Tobias Holzmann

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

---

Nene du hast 50% schon richtig verstanden  

Es sind zwei Simulationen. Einmal simpleFoam und einmal pimpleDyMFoam.

Ich schreibe mir die Massenströme bei jeder Iteration/Zeitschritt in einer Logdatei raus und werte das dann mit gnuplot aus. Dadurch ists mir ja erst aufgefallen, dass mir die 2% fehlen. Die allerdings relativ konstant.

Ich habe den Fehler auch auf die AMI Flächen lokalisiert. Im Strömungsraum selber (der drei einzelnen Gitter) habe ich keine Verluste. Und am Gitter kanns ja nich liegen, da diese Verluste in OF2.1 nicht auftreten.

Ich habe gerade einen Fall mit correctPhi gestartet. Scheint keinen Einfluss zu haben.

------------------
Gruß
Jens

[Diese Nachricht wurde von JensHa am 08. Apr. 2015 editiert.]

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

---

Kannst du mal eine Logdatei anhängen?

------------------
Best regards,
Tobias Holzmann

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

---

massFlow.zip

Im Anhang sind 2 Log Dateien. Aber nicht bis zum Ende. Die Tendenz sieht man aber schon.

------------------
Gruß
Jens

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

---

Hallo Jens,

ja das sieht man. Kannst du auch noch eine ganz normale Log-Datei anhängen (also der Output vom Löser?). Danke

------------------
Best regards,
Tobias Holzmann

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

---

log.pimple_OF21.zip

Ja also die Dateien sind schon ziemlich groß. Deshalb hier ein Ausschnitt aus der OF2.1 Datei. Die Log Datei von OF231 ist schon viel weiter fortgeschritten und ca 30 mb groß. Sprengt ein bisschen den Rahmen denke ich.

------------------
Gruß
Jens

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

---

Brauch ja nicht alles nur ein Teil.
Und da das Problem bei dir mit 2.3.1 ist, wäre diese Log ganz gut 

------------------
Best regards,
Tobias Holzmann

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

---

log.pimple_OF231.zip

Und hier is die Logdatei im Anhang als kleiner Ausschnitt.

Gruß

[Diese Nachricht wurde von JensHa am 08. Apr. 2015 editiert.]

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

---

mass.png

Hallo Jens,

ich fasse nochmals zusammen. Du hast einen Massendefekt von Inlet zum Outlet? Auf Grund deiner Log-Datei kann ich aber ausschließen das das so ist. Sowohl Kummulativ als auch Global scheint mir da alles sauber zu sein (siehe Anhang).

Das einzige was interessant erscheint, ist dein Residuenverlauf. Die scheinen sich wie geraden zu verhalten und  bei t=0,098s ist iwas passiert.

------------------
Best regards,
Tobias Holzmann

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

---

InstSSTEulerL_residuals.png

Moin Tobias,

Der Defekt ist eher zwischen den beiden AMI Flächen (OUTER_AMI_INT und OUTER_AMI_EXT). Bei den beiden anderen (INNER_AMI_INT und INNER_AMI_EXT) verliere ich zwar auch etwas, aber bei weitem nicht so viel. Vom INLET zu INNER_AMI_INT ist der Massenstrom ja konstant. Genauso wie von OUTER_AMI_EXT zum OUTLET und im Rotor selber vom INNER_AMI_EXT zum OUTER_AMI_INT.

Im Anhang findest du nochmal die Residuen. Ich weiß leider nich mehr wodran es noch liegen kann, ausser dass OF231 beim pimpleDyMFoam Solver nen Fehler drin hat.

------------------
Gruß
Jens

[Diese Nachricht wurde von JensHa am 08. Apr. 2015 editiert.]

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

---

Also ich habe mir auch mal beide tutorials von OF2.1 und OF2.3.1 (pimpleDyMFoam/mixerVesselAMI2D) angesehen und stelle auch dort unterschiede an den AMI Flächen und insbesondere an den Druckschwankungen fest.

Werd dann wohl dazu übergehen und OF2.1 anstatt 2.3.1 für meine Sliding Mesh Simulationen verwenden.

(Nachtrag: In der neuen 2.3.x Version wurde dieser Fehler ebenfalls behoben)

[Diese Nachricht wurde von JensHa am 24. Apr. 2015 editiert.]

[Diese Nachricht wurde von JensHa am 27. Aug. 2015 editiert.]

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