---

netz.png

Das feature snapping funktioniert bei mir stellenweise nicht besonders gut. Anbei mal ein Bild. Ich hab bereits nFeatureSnapIter erhöht und explicitFeatureSnap ist auf true gestellt. Im Bild ist im Netz auch das Ergebnis des surfaceFeatureExtract dargestellt.

Noch eine andere Frage:

Mein Einlass ist ein ziemlich schmaler Spalt (Bild), sodass die Strömung hier vollständig in der Grenzschicht liegt. p_rgh wird nach wenigen Schritten ziemlich instabil. Ich habe u im Einlass als fixedValue festgelegt. Sollte ich versuchen u als Rampe zu vergrößern oder etwas anderes? Eigentlich müsste die Co-Zahl im Spalt momentan bei 0.4 liegen

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

---

Du willst mit 2 Zellen eine Strömung abbilden?

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

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

---

U-Feld_t0.002.png

Verstanden, ich habe den Spalt jetzt erstmal weggelassen und das Problem besteht noch weiterhin.

Im Bild ist das u-Feld für einen Zeitschritt zu sehen (der zweite) bevor die Simulation aussteigt. Ich habe Wandfunktionen verwendet. Die Frage ist, wieso nicht jede Zelle eine Wandfunktion aufweist. Mir ist klar dass die Netzqualität nicht besonders berauschend ist, aber woran soll ich schrauben? Ich brauche hier wirklich ein paar Tipps.

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

---

Grüß dich 

was soll das Bild darstellen. Geschwindigkeit von 0m/s bis 0m/s 
Kannst ud deinen Case mal zur Verfügnug stellen?

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

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

---

case.tar.gz

Ich bin jetzt bei der Fehlersuche systematischer vorgegangen und habe erstmal versucht das ganze inkompressibel zu lösen. Dabei habe ich gefunden, dass in der boundary Datei Einlass und Auslass als wall definiert waren. Inkompressibel mit Turbulenz und Wandfunktionen lief es dann durch. Kompressibel nur laminar. Die Meldung lautet jetzt folgendermaßen

Code:

---

Selecting thermodynamics package
{
    type            hePsiThermo;
    mixture        pureMixture;
    transport      sutherland;
    thermo          hConst;
    equationOfState PengRobinsonGas;
    specie          specie;
    energy          sensibleEnthalpy;
}

Reading field U

Reading/calculating face flux field phi

Creating turbulence model

Selecting RAS turbulence model kEpsilon
#0  Foam::error: rintStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::compressible::mutkWallFunctionFvPatchScalarField::calcMut() const at ??:?
#4  Foam::compressible::mutWallFunctionFvPatchScalarField::updateCoeffs() at ??:?
#5  Foam::fvPatchField<double>::evaluate(Foam::UPstream::commsTypes) at ??:?
#6  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() at ??:?
#7  Foam::compressible::RASModels::kEpsilon::kEpsilon(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::fluidThermo const&, Foam::word const&, Foam::word const&) at ??:?
#8  Foam::compressible::RASModel::adddictionaryConstructorToTable<Foam::compressible::RASModels::kEpsilon>::New(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::fluidThermo const&, Foam::word const&) at ??:?
#9  Foam::compressible::RASModel::New(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::fluidThermo const&, Foam::word const&) at ??:?
#10 
at ??:?
#11  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#12 
at ??:?
Gleitkomma-Ausnahme (Speicherabzug geschrieben)

---

Ich habe mal die Dateien k, epsilon und boundary in einem Archiv angefügt.

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

---

Kurze Frage.
Hast du im Ordner 0 auch eine Datei mu oder mut

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

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

---

ja mit folgendem Inhalt

Code:

---

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

internalField  uniform 0;

boundaryField
{
    fluid_default
    {
        type            mutkWallFunction;
        Cmu            0.09;
        kappa          0.41;
        E              9.8;
        value          uniform 0;
    }
    fluid_flange
    {
        type            mutkWallFunction;
        Cmu            0.09;
        kappa          0.41;
        E              9.8;
        value          uniform 0;
    }
    fluid_hot
    {
        type            mutkWallFunction;
        Cmu            0.09;
        kappa          0.41;
        E              9.8;
        value          uniform 0;
    }
    fluid_htc
    {
        type            mutkWallFunction;
        Cmu            0.09;
        kappa          0.41;
        E              9.8;
        value          uniform 0;
    }
    fluid_inlet
    {
        type            calculated;
        value          uniform 0;
    }
    fluid_outlet
    {
        type            calculated;
        value          uniform 0;
    }
}

---

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

---

Lösch mal bitte diese Datei und start die Simulation erneut.
Das sollte dein Problem beheben, sofern ich das im Code jetzt richtig gesehen hab. Ansonsten muss ihc nochmals schauen.

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

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

---

Diese Datei ist ja allein vom Solver angelegt worden. Ebenso wie alphat.

Kann es sein, dass mein Netz nicht für diese Wandfunktionen geeignet ist? Könnte das bereits an dieser Stelle Ausnahmen auslösen?

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

---

Nein das hat nix mit deinem Netz zu tun sondern durch die Funktion calcMut(), die durch die Werte an den patches von "Variable muw" teilt. Wenn das null ist, dann teilst du durch Null und du erhältst den Floating Point Exception.

Die Frage ist, hast du diese jetzt gelöscht und nochmals neu gestartet oder nicht 

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

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

---

Ja das habe ich 
Sogar die mut~ hab ich gelöscht. Ich finde es aber seltsam, dass der solver jedesmal k und epsilon überschreibt (und k.old und epsilon.old erzeugt) und beim Neustarten dann aber nochmal, also seine selbst überschriebenen Dateien nochmals überschreibt.

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

---

ich habe in mut jetzt überall calculated eingetragen und es läuft gerade erstmal. Mal schauen was daraus wird.

Eine Frage: sind für rhoMax und rhoMin relative Werte oder absolute Werte in fvSolution einzusetzen?

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

---

Wenn dein Problem gelöst ist, bitte als gelöst markieren.

PS: Relative Dichtewerte? Wenn du den Code anschaust, dann wird alles was über rhoMin und rhoMax mit diesen Werten überschrieben.

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

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

---

Danke für die Antwort.

Ich habe ein neues Problem nachdem ich jetzt versuche mit buoyantSimpleFoam parallel zu rechnen.

decomposePar erzeugt in den Prozessorpfaden keine p_rgh obwohl sie im unzerteilten Ordner 0 vorhanden ist. Starte ich den Solver nicht parallel funktioniert die Simulation doch auch. In einem anderen Case den ich mal mit einem einfachen Rohr erstellt habe, funktionierte das noch.

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

---

Das ist jetzt auch gelöst. decomposePar nimmt nur Dateien die als volScalarField im Kopf gekennzeichnet sind. In den Solvern ist es egal. Naja

Die Simulation rechnet jetzt bis zum 6. Zeitschritt und spuckt dann das aus:

Code:

---

GAMG:  Solving for h, Initial residual = 0.00805986, Final residual = 0.00023835, No Iterations 1
#0  Foam::error: rintStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::PengRobinsonGas<Foam::specie>::Z(double, double) const at ??:?
#4  Foam::heRhoThermo<Foam::rhoThermo, Foam: ureMixture<Foam::sutherlandTransport<Foam::species::thermo<Foam::hConstThermo<Foam::PengRobinsonGas<Foam::specie> >, Foam::sensibleEnthalpy> > > >::calculate() at ??:?
#5  Foam::heRhoThermo<Foam::rhoThermo, Foam: ureMixture<Foam::sutherlandTransport<Foam::species::thermo<Foam::hConstThermo<Foam::PengRobinsonGas<Foam::specie> >, Foam::sensibleEnthalpy> > > >::correct() at ??:?
#6 
at ??:?
#7  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#8 
at ??:?
Gleitkomma-Ausnahme (Speicherabzug geschrieben)

---

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

---

Hallo,

• p_rgh und auch alle anderen Files in 0 sind volScalar oder volVectorFields (sofern man andere Files wie bspw. vom dynamicMesh auser Acht lässt
  
• was hattest du denn bei p_rgh, wenn man fragen darf?
  
• Fehler sagt dir, dass du Probleme mit deiner Thermo hast, correct() und calculated() sind Funktionen die dir die Zell und Facewerte berechnen
  
• Ggf. ist es auch die Funktion Z(double, double) die eine Zahl durch null teilt
  
• Du teilst wieder durch Null (Floating Point Exception)
  

Ohne Case und ohne Netz ist das alles nich immer so einfach zu überprüfen.
Vielleicht hat auch dein Netz ein Fehler oder ist für numerische Zwecke nicht geeignet (Foam ist da sehr penibel).

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

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

---

Ich hatte den Kopf eines dictionaries für p_rgh kopiert.

Ok mal überlegen. Ich konnte heute mit rhoSimpleFoam den gleichen Case durchrechnen. Für buoyantSimpleFoam habe ich eben p geändert und p_rgh erstellt und noch den thermoType von hePsiThermo auf heRhoThermo umgestellt und jetzt teile ich nach einigen Iterationen irgendwo dort durch 0.

In Foam::PengRobinsonGas<Foam::specie>::Z(double, double) kann es denk ich nicht liegen, bzw. nicht im dort liegenden Code sondern einer der weiteren Routinen die dort aufgerufen werden. Ich schau mir mal den Unterschied zwischen hePsiThermo und heRhoThermo an, aber aus dem Code werde ich nicht so schnell schlau.

[Diese Nachricht wurde von bacengeugn am 20. Mrz. 2015 editiert.]

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

---

Die Thermolib von OpenFOAM ist nicht ganz ohne 

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

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

---

8_fluidDomainHP1_idealGas_buoyant_komp_turbulent_wallFunctions_clean.tar.gz

Ich habe mal auf perfectGas und transport const; umgestellt um hier Probleme auszuschließen. Das Ergebnis war dann, dass die Berechnung um einen Zeitschritt weiter ging und ein Fehler im GAMG-Solver angezeigt wird.

Code:

---

Time = 0.06

GAMG:  Solving for h, Initial residual = 0.000808263, Final residual = 4.0101e-05, No Iterations 1
GAMG:  Solving for p_rgh, Initial residual = 0.999939, Final residual = 179.068, No Iterations 1000
time step continuity errors : sum local = 3.82979e+13, global = 8.21366e+08, cumulative = 8.21366e+08
rho max/min : 3.99619e+06 8.38987e-13
smoothSolver:  Solving for epsilon, Initial residual = 0.0414896, Final residual = 3.49827e-08, No Iterations 2
smoothSolver:  Solving for k, Initial residual = 0.965981, Final residual = 0.013435, No Iterations 2
ExecutionTime = 939.68 s  ClockTime = 941 s

Time = 0.08

GAMG:  Solving for h, Initial residual = 0.996094, Final residual = 0.00943727, No Iterations 2
#0  Foam::error:  rintStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2   in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ??:?
#4  Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:?
#5  Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#6  Foam::fvMatrix<double>::solveSegregated(Foam::Dictionary const&) at ??:?
#7  Foam::fvMatrix<double>::solve(Foam::Dictionary const&) at ??:?
#8 
at ??:?
#9 
at ??:?
#10  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11 
at ??:?
Gleitkomma-Ausnahme (Speicherabzug geschrieben)

---

Wenn ich mit yPlusRAS -compressible die Eignung des Netzes für Wandfunktionen untersuchen will, bekomme ich immer nur an allen Patches 0 als Ergebnis.
Ich habe den Case nun mal angehängt. Allerdings ist das Netz zu groß zum Anhängen. Man muss also snappyHexMesh ausführen und die boundary-Datei für den inlet und outlet umschreiben damit es läuft. Ich habe ein Hintergrundnetz als Mesh_1.unv dabei.

[Diese Nachricht wurde von bacengeugn am 22. Mrz. 2015 editiert.]

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

---

Hi,

ajajaja... das sieht ja wild/durcheinander aus. War wohl mehr Try and Error als Wissen am Werk oder? Das kann so nicht funktionieren.

Deine STL ist übrigens auch sehr schlecht.
Ich hatte schon mal die Aussage mit den 2 Zellen erwähnt. fvSolution ist ziemlich durcheinander, GAMG auf h (kann man aber ich seh keinen Nutzen durch Multi-Grid), Boundarys (bspw. p = 0bar, p_rgh = 1bar?) und vieles mehr.

Es liegt definitiv nicht am Turbulenzmodell und an der Thermolib. Das ist einzig und allein das schlechte Netz.

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

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

---

Stimmt ich habe vieles mehrmals geändert.

Inwiefern oder an welcher Stelle ist die STL schlecht? Die Schnittstellen passen zusammen. Meinst du die Grobheit?

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

---

Die Schnittstellen passen ja, aber hast du schon mal dein gesnappted Mesh angeschaut.

• Innenkonturen sollten glaub rund sein. Sieht eher aus als wäre es 8 eckig bzw. keines Weges rund (;
  
• An den kleinen Engpässen zwischen deinem (ich nehm an Solid) und Fluidraum hast du nur 2 Zellen
  
• Die ganze Vernetzung kann wohlmöglich mit wesentlich weniger Zellen gemacht werden aber eben gewusst wie (:
  

Gleich mal aus Interesse: Wo hast du deine STL erstellt (da diese eine regionale STL darstellt).

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

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