Hot News:

Unser Angebot:

  Foren auf CAD.de (alle Foren)
  OpenFOAM
  unglaublich große Courant-Zahl

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:  unglaublich große Courant-Zahl (6660 mal gelesen)
bephi
Mitglied
Student


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

Beiträge: 56
Registriert: 21.04.2010

OpenFoam 1.70

erstellt am: 21. Apr. 2010 11: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

Hallo an alle!

Ich habe folgendes Problem: Ich möchte mit OpenFoam die Strömung durch ein Kolbenventil simulieren und habe mit ANSA ein Volumennetz generiert. checkMesh sagt mir, dass das Netz okay ist und da ich erst vor einer Woche mit OF angefangen habe, wollte ich zunächst eine laminare Rechnung mit icoFoam durchführen, um dann später, wenn das funktioniert hat, immer etwas genauer zu werden. Dafür habe ich die fvSchemes, fvSolution und transportProperties vom "icoFoam->cavity-Tutorial" genommen.

Leider bricht meine Rechnung aber mit dem icoFoam solver nach ca. 10 Schritten ab, da die Courant-Zahl auf einen Wert über 1e+100 angestiegen ist... Ich habe gelesen, dass sie unter 1 bleiben sollte für stabile Rechnungen und das ist ja leider nicht der Fall.
Also habe ich zunächst die Schrittweite auf 3.5e-6 gesenkt, doch die Co-Zahl stieg weiter bis zum Abbruch!

Danach habe writeControl auf "adjustableRunTime" geändert und die Co-Zahl mit "maxCo 1" eingeschränkt, damit die Schrittweite selbst angepasst wird, aber in der runlog sah ich, dass delta t weiterhin konstant blieb. Funktioniert adjustableRunTime also nicht für icoFoam, sondern nur für komplexere solver?

Jedenfalls weiß ich nicht so recht weiter, was ich machen kann, damit meine Rechnung zumindestens für den laminaren Fall durchläuft... Habt ihr eine Idee?

Viele Grüße!

PS: meine Startwerte für U und p

Code:

dimensions [0 1 -1 0 0 0 0];
internalField uniform ( 0.000000 0.000000 -1.000000 );
boundaryField
{
symmetry
{
type symmetryPlane;
}
inlet
{
type fixedValue;
value uniform ( 0.000000 0.000000 -1.000000 );
}
outlet
{
type zeroGradient;
}

}

dimensions [0 2 -2 0 0 0 0];
internalField uniform 0.000000;
boundaryField
{
symmetry
{
type symmetryPlane;
}
inlet
{
type fixedValue;
value uniform 452.38;
}
outlet
{
type fixedValue;
value uniform 0.000000;
}


controlDict

Code:

application icoFoam;
startFrom       startTime;
startTime       0;
stopAt          endTime;
endTime         1e-3;
deltaT          3.5e-6;
writeControl    adjustableRunTime;
writeInterval   10;
purgeWrite      0;
writeFormat     ascii;
writePrecision  6;
writeCompression uncompressed;
timeFormat      general;
timePrecision   6;
runTimeModifiable yes;
adjustTimeStep yes;
maxCo 1.0;


fvSchemes

Code:

ddtSchemes
{
    default         Euler;
}
gradSchemes
{
    default         Gauss linear;
    grad(p)         Gauss linear;
}
divSchemes
{
    default         none;
    div(phi,U)      Gauss linear;
}
laplacianSchemes
{
    default         none;
    laplacian(nu,U) Gauss linear corrected;
    laplacian((1|A(U)),p) Gauss linear corrected;
}
interpolationSchemes
{
    default         linear;
    interpolate(HbyA) linear;
}
snGradSchemes
{
    default         corrected;
}
fluxRequired
{
    default         no;
    p;
}

fvSolution

Code:

olvers
{
    p PCG
    {
        preconditioner   DIC;
        tolerance        1e-06;
        relTol           0;
    };

    U PBiCG
    {
        preconditioner   DILU;
        tolerance        1e-05;
        relTol           0;
    };
}
PISO
{
    nCorrectors     2;
    nNonOrthogonalCorrectors 0;
    pRefCell        0;
    pRefValue       0;
}



EDIT: okay ich hab bei divSchemes Gausslinear auf GaussUpwind gesetzt und jetzt steigt die maximal Co-Nr bis zum 20. Zeitschritt nicht über 7! Aber danach gehts wieder hoch und bricht dann irgendwann ab, wenn die Zahl zu groß wird... 

Reicht es denn, wenn die gemittelte Co-Nr <1 ist oder sollte auch die maximale unter 1 sein?
------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

[Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.]

[Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.]

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

StudentMax
Mitglied
Student Maschinenbau


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

Beiträge: 73
Registriert: 03.12.2009

SuseLinux 11.2
OpenFoam 1.6
Salome 5.1.3

erstellt am: 21. Apr. 2010 13:30    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 bephi 10 Unities + Antwort hilfreich

Hi bephi,
ich bin mir nicht hundertprozentig sicher, da ich selbst noch Anfänger bin, aber ich glaube dein Problem liegt bei den Randbedingungen für p:
Versuche mal den outlet auf "type   zeroGradient;" anstatt auf "fixedValue" zu setzen. Ich denke icoFoam hat ein Problem, weil du zweimal fixedValue verwendet hast.
Achtung: der Druck wird bei inkompressiblen Solvern wie icoFoam als sog. "density normalized pressure" angegeben, also Druck/Dichte. Der Druck ist damit relativ. Es werden keine Absolutwerte in Pascal angegeben (siehe die Einheiten bei "Dimensions": m^2/s^2).
Schaue dir mal die p-Datei in verschiedenen inkompressiblen tutorials an. Es wird eigentlich immer nur eine Randbedingung für den Druck auf "fixedValue" gesetzt, der Rest ist "zeroGradient". Die festen Werte sind eigentlich immer mit Null angegeben, weil sie eben relativ sind. Also denke ich der Wert von 452 beim Inlet sollte auf 0 gesetzt werden.

Ich hoffe dass das jetzt richtig war und ich dir keinen Schmarrn erzählt habe, evtl kann ein Profi wie Thomas oder Ulrich mehr dazu sagen, 
Grüße
Max

[Diese Nachricht wurde von StudentMax am 21. Apr. 2010 editiert.]

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

bephi
Mitglied
Student


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

Beiträge: 56
Registriert: 21.04.2010

OpenFoam 1.70

erstellt am: 21. Apr. 2010 13:41    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 Max,
hab vielen Dank für deine nette Antwort!
Also ich werd es gleich mal mit zeroGradient am outlet versuchen...
Danke auch für den Tipp mit dem spezifischen Druck! Das ist allerdings schon berücksichtigt. Ich habe am Einlass 3,8 bar also ca. 380000 Pa und bezogen auf eine Dichte von 840 kg/m³ ergeben sich dann 452,4 m²/s².

Viele Grüße!
Phil


EDIT: Ich hab jetzt den type fixvalue gegen zeroGradient am outlet getauscht und leider ist das Resultat, dass die Co-Zahl wieder etwas schneller anwächst als vorher, bis die Rechnung dann abbricht.
------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

[Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.]

[Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.]

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

StudentMax
Mitglied
Student Maschinenbau


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

Beiträge: 73
Registriert: 03.12.2009

SuseLinux 11.2
OpenFoam 1.6
Salome 5.1.3

erstellt am: 21. Apr. 2010 13:58    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 bephi 10 Unities + Antwort hilfreich

Hi bephi,
ich habe was übersehen: du hast am inlet sowohl die geschwindigkeit als auch den druck auf fixedValue gesetzt. Probier mal, den Druck am outlet auf fixedValue und am inlet auf zeroGradient. Wenn an einer Fläche Druck und Geschwindigkeit auf fixedValue stehen, mag das der Solver auch nicht.
Also inlet-->U=fixedValue und p=zeroGradient
outlet -->U=zeroGradient und p=fixedValue
Könnte auch was bringen, einfach mal probieren,
Grüße
Max

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

bephi
Mitglied
Student


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

Beiträge: 56
Registriert: 21.04.2010

OpenFoam 1.70

erstellt am: 21. Apr. 2010 14:08    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

 
Zitat:
Original erstellt von StudentMax:
Hi bephi,
ich habe was übersehen: du hast am inlet sowohl die geschwindigkeit als auch den druck auf fixedValue gesetzt. Probier mal, den Druck am outlet auf fixedValue und am inlet auf zeroGradient. Wenn an einer Fläche Druck und Geschwindigkeit auf fixedValue stehen, mag das der Solver auch nicht.
Also inlet-->U=fixedValue und p=zeroGradient
outlet -->U=zeroGradient und p=fixedValue
Könnte auch was bringen, einfach mal probieren,
Grüße
Max


Hey, aber ich möchte doch die Anfangsbedingung geben, dass der Druck am inlet einen bestimmten Wert besitzt. Warum sollte ich ihn dann auf zeroGradient stellen? Dann würde er ja mit falschen Eingangswerten rechnen?!
Gruß!
------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

[Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.]

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

StudentMax
Mitglied
Student Maschinenbau


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

Beiträge: 73
Registriert: 03.12.2009

SuseLinux 11.2
OpenFoam 1.6
Salome 5.1.3

erstellt am: 21. Apr. 2010 14:20    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 bephi 10 Unities + Antwort hilfreich

Hi phil,
das gleiche Problem habe ich auch gerade.
Der Solver verträgt es nicht, wenn Druck und Geschw. an der gleichen Fläche fixed sind.
Jedoch habe ich bei mir beide Werte für den Outlet gegeben, ich müsste also am outlet u und p auf fixed setzen. Das führt jedoch immer zu einem Solverabsturz.
Ich habe von Thomas Hilfe bekommen, und nun habe ich am Inlet einen Volumenstrom angegeben, den ich mir aus der Outlet-Geschwindigkeit und der outlet-Fläche berechnet habe. Evtl. kannst du in ähnlicher Weise die Randbedingungen auf Inlet und outlet aufteilen. (Evtl. am outlet die Geschwindigkeit definieren?)
Ansonsten würde ich dir empfehlen, auch wenns erstmal falsch ist, die Bedingungen zu verändern, damit der Solver erstmal läuft--> Einschränken des Problems. So habe ich bei mir manchmal die Solver-Absturz Probleme eingrenzen können.
Hoffe geholfen zu haben,
Grüße,
Max

[Diese Nachricht wurde von StudentMax am 21. Apr. 2010 editiert.]

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

bephi
Mitglied
Student


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

Beiträge: 56
Registriert: 21.04.2010

OpenFoam 1.70

erstellt am: 21. Apr. 2010 14:48    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

hey max, also die idee ist auf jeden fall nicht verkehrt, dass man immer ein paar vereinfachungen macht und es zum laufen kriegt und dann stück für stück korrekter wird.
leider ist auch bei der maßnahme der anstieg der Co-Zahl nicht verhindert und sie steigt relativ schnell, sodass die rechnung nach ein paar minuten abbricht... 

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

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

StudentMax
Mitglied
Student Maschinenbau


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

Beiträge: 73
Registriert: 03.12.2009

SuseLinux 11.2
OpenFoam 1.6
Salome 5.1.3

erstellt am: 21. Apr. 2010 15: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 bephi 10 Unities + Antwort hilfreich

Hi Phil,
was gibt denn checkMesh aus wie viele nicht-orthogonale Zellen du im Netz hast?
Weil du in deiner fvSolution keine nNonOrthogonalCorrectors hast. Keine Ahnung, ob dein Fehler daran liegen kann, aber prinzipiell gilt je mehr nicht-orthogonale Zellen im Netz, desto mehr nNonOrthogonalCorrectors sind nötig. Kannst ja mal probieren diese auf 2 oder 5 oder so zu setzen, evtl hilfts was. Ich habe z.B. laut checkMesh 13 von ca. 250.000 Zellen, die nicht-orthogonal sind und habe 2 nNonOrthogonalCorrectors.
Im cavity tutorial sind keine nNonOrthogonalCorrectors nötig, da dort ja ein simples 2D-Hexa Mesh verwendet wird.
Grüße,
Max

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

Ulrich Heck
Mitglied
OpenFOAM Tool Entwicklung


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

Beiträge: 291
Registriert: 08.09.2003

CastNet (DHCAE Tools)
OpenFOAM
CalculiX

erstellt am: 21. Apr. 2010 15:11    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 bephi 10 Unities + Antwort hilfreich

Hallo Bephi,

Druckwert am Ein- und Austritt und Geschwindigkeit macht definitiv keinen Sinn, da dann der Strömung die Lösung bereits aufgezwungen wird. Das kann nicht funktionieren. Das Druck- bzw. Geschwindigsfeld ergeben sich gegenseitig aus den Randbedingungen, d.h. man darf nur eins von vorschreiben, entweder ein treibendes Druckgefälle oder einen Fluss, der ein Druckgefälle (Druckverlust) verursacht.

Weiterhin ist folgendes zu beachten: Bei Problemen sollte man am besten die stabilsten Schemes verwenden, d.h. div(phi,U) Gauss upwind.

Bei Piso sollte der nonorthogonal Corrector größer als "0" sein (z.B. 2), wenn das Gitter nicht wirklich orthogonal ist (also z.B. tet-Gitter).

Dann ist es am besten auch den Zeitschritt entsprechend des Tutorials "icoFOAM" im OF user guide abzuschätzen. Kleinere Zeitschritte bringen mehr Stabilität (Piso).

Viele Grüße

Ulli

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

bephi
Mitglied
Student


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

Beiträge: 56
Registriert: 21.04.2010

OpenFoam 1.70

erstellt am: 21. Apr. 2010 15:25    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

Also Ulli und Max,
habt auf jeden Fall vielen Dank, dass ihr mir helft! Ohne euch wüsst ich nicht wo vorn und hinten ist  
Also das mit den nonorthogonal Correctors klingt gut und werd ich gleich mal ausprobieren. Ich weiß, dass mein Netz noch nicht so gut ist, aber ich dachte mir, weil checkMesh das OK gegeben hat, setz ich wenigstens mal meine erste Rechnung auf, um zu schauen, wie so ein ganzer Prozess abläuft.
Die Schrittweite habe ich bereits mit Co=1 und delta x abgeschätzt.
Anbei das Ergebnis von checkMesh. Habe ich 67.4637 nichtorthogonale Elemente und Max nur 13?   Oder welcher Wert ist das?
Zu den Randbedingungen: Reicht es denn, wenn ich den Druck am Ausgang nur auf zeroGradient stelle? Oder muss der Druck am Inlet wirklich weg?

Code:

Mesh stats
    points:           224517
    faces:            1780738
    internal faces:   1704400
    cells:            821567
    boundary patches: 12
    point zones:      0
    face zones:       0
    cell zones:       2

Number of cells of each type:
    hexahedra:     0
    prisms:        198870
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    622697
    polyhedra:     0

Checking topology...
    Boundary definition OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
    Patch               Faces    Points   Surface topology
    symmetry            13976    8782     ok (non-closed singly connected)
    inlet               36       28       ok (non-closed singly connected)
    outlet              39       30       ok (non-closed singly connected)
    drosselbohrungen    11632    5973     ok (non-closed singly connected)
    steuerkanten_unten  15622    7988     ok (non-closed singly connected)
    kolbenstange        9945     5563     ok (non-closed singly connected)
    schliessscheibe     11254    6000     ok (non-closed singly connected)
    steuerkanten_oben   8919     4617     ok (non-closed singly connected)
    zylinderrohr        741      439      ok (non-closed singly connected)
    fenster             3373     1766     ok (non-closed singly connected)
    auslauf_oben        228      137      ok (non-closed singly connected)
    auslauf_unten       573      366      ok (non-closed singly connected)

Checking geometry...
    Overall domain bounding box (-0.0275 -0.0238157 -0.2) (-7.62939e-10 6.62893e-10 0.175)
    Mesh (non-empty) directions (1 1 1)
    Mesh (non-empty, non-wedge) dimensions 3
    Boundary openness (-9.11091e-17 1.52805e-15 -1.40072e-16) OK.
    Max cell openness = 6.37195e-16 OK.
    Max aspect ratio = 40.8671 OK.
    Minumum face area = 9.05593e-11. Maximum face area = 2.08965e-05.  Face area magnitudes OK.
    Min volume = 3.33263e-16. Max volume = 2.92178e-08.  Total volume = 9.0315e-05.  Cell volumes OK.
    Mesh non-orthogonality Max: 67.4637 average: 16.3796
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 2.45156 OK.

Mesh OK.


------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

[Diese Nachricht wurde von bephi am 21. Apr. 2010 editiert.]

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

StudentMax
Mitglied
Student Maschinenbau


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

Beiträge: 73
Registriert: 03.12.2009

SuseLinux 11.2
OpenFoam 1.6
Salome 5.1.3

erstellt am: 21. Apr. 2010 15: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 bephi 10 Unities + Antwort hilfreich

Hi Phil,
hmm das sieht eigentlich gut aus. Wenn schlechte Zellen drinn sind, ist nach Mesh non-orthogonality Max:.........  eine weitere Zeile mit z.B.:
*Number of severly non-orthogonal faces: 13
Also denke ich dass dein Netz gut ist. 
Evtl. kannst du ja mal in paraView die Netzqualität (paraFoam -->Filter:MeshQuality) anschauen, aber ich glaube nicht dass bei dir das Netz das Problem ist.

Wenn du am Inlet die Geschw. auf fixedValue hast, muss der Druck am Inlet weg, soweit ich weiss, sonst crasht der Solver. Dann muss am Inlet der Druck auf zeroGradient sein.
Dafür kannst du am outlet den Druck auf fixedValue setzen.

Grüße,
Max

[Diese Nachricht wurde von StudentMax am 21. Apr. 2010 editiert.]

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

Ulrich Heck
Mitglied
OpenFOAM Tool Entwicklung


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

Beiträge: 291
Registriert: 08.09.2003

CastNet (DHCAE Tools)
OpenFOAM
CalculiX

erstellt am: 21. Apr. 2010 15:51    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 bephi 10 Unities + Antwort hilfreich

Hallo Phil,
Schließe mich Max an, der ist irgendwie schneller: Dein Gitter ist absolut okay. Der maximale Winkel ist 67.4 Grad. Da sollte es keine Probleme geben. Meines Wissens passt icoFOAM aber nicht den Zeitschritt an die CFL-Zahl an, es sei denn, dies wurde in einer der letzten Versionen geändert. D.h. maxCo wird dort nicht benutzt. Würde ich mal kontrollieren. Meines Wissens muss man vür IcoFoam den Zeitschritt von Hand ausrechnen.

Gruß
Ulli

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

bephi
Mitglied
Student


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

Beiträge: 56
Registriert: 21.04.2010

OpenFoam 1.70

erstellt am: 21. Apr. 2010 15:51    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

ah alles klar! ich hab nämlich garnicht gefunden, wo die anzahl der nicht-orthogonalen elemente angegeben wird.
also ich hab den faktor aber trotzdem mal auf 2 gesetzt und bisher läuft die rechnung ganz gut durch und die Co-zahl bleibt weit unter 1! mal sehen, obs durchgehalten wird...
ich werd die rechnung laufen lassen, muss mich jetzt aber auf den weg machen und schau dann morgen früh, was drauß geworden ist 
ich wünsche euch noch einen schönen feierabend und habt nochmal vielen herzlichen dank!!!

------------------
Maschinenbau-Student mit Vertiefungsrichtung "Angewandte Mechanik"

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