---

Zitat:

---

Original erstellt von Clinton:

Ich bin der Auffassung, dass mein Kommentar durchaus hilfreich war, zumal hier eine Arterienströmung simuliert werden sollte...
Der Allgemeingebildete Mensch weiß, dass eine Arterieströmung keine kontinuierliche ist, sondern eine pulsierende... (sic!),
und dass diese Strömung von vielen Parametern abhängig ist...

---

Und damit nicht berechenbar?

Zitat:

---

Original erstellt von Clinton:

Der Hinweis auf industrielle Strömungen ist nur ein dilettantisches Ablenkungsmanöver!

---

Ich denke nicht, dass solch eine Wortwahl in diesem Forum angemessen ist.

Thomas S.

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

Zitat:

---

Original erstellt von Bioniker:
Moin Leute,

nach Ewigkeiten melde ich mich doch wieder, natürlich mit einem Problemchen. Die Layer werden an den Kanten der Einzelflächen leider bis auf Null heruntergefahren. Die Grenzschicht wird also nicht mehr ausreichend aufgelöst. Das führt in der Simulation zu hässlichen Peaks bei Druck/Geschwindigkeit genau an diesen Kanten. Gibt es eine Möglichkeit "um die Ecke zu layern"?

---

Ja mit dem der Einstellung

Code:

---

featureAngle

---

im Layer-Setup.

------------------
Grüße Tobias H.

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

---

@Clinton: Naja, man muss halt irgendwo einen Mittelweg finden. Hängt ja auch immer davon ab, welchen Fall man betrachten möchte,
und was genau er mit der Simulation untersuchen will ist ja auch nicht ganz klar.

Insgesamt stell ich mir das auch schwer vor... vor allem weil so eine Arterie doch nicht starr ist, oder? Dehnt/zieht sich die nicht auch auseinander/zusammen mit der Pulsation, auch wenn es geringfügig ist? Sonst könnte man ja auch kaum einen Puls messen?  

Ich glaube das Medium mit den Eigenschaften nachzubilden stellt noch das geringste Übel dar, oder? Man betrachtet dann halt nur einen Blutzustand... der Patient hat grad Aspirin genommen... :-)
Und gibt es nicht schon Solver für Nichtnewtonische Fluide, die man vielleicht die diese Zwecke anpassen könnte?

Wie gesagt, da erscheint mir Pulsation in Kombination mit einem Moving Mesh schon krasser... außerdem wirds bei der Zellenanzahl ganz schön rechenintensiv :-D

Ansonsten: Wenn's um Forschung geht, muss man halt irgendwo mal anfangen, und warum nicht mit FOAM?
Wenn jeder mit der Einstellung rangehen würde .... "geht nicht" dann werden aus 100-500Jahren gleich mal 1000 Jahre :-D

Viel Erfolg! & Frohes Fest!

[Diese Nachricht wurde von bartholomew83 am 18. Dez. 2012 editiert.]

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

---

@ Clinton:

Und ja, natürlich pulsatil. Den Upload eines Videos spare ich mir...

Medium vereinfachend als newtonsch angenommen, was bei den größeren Aortenquerschnitten aufgrund nicht zu hoher Scherraten auch in Teilen zulässig ist. Das das hier keine Grundlagen-DNS-Geschichte ist sehen Sie ja wohl selbst.

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

---

@ Bioniker:
Versuch es mal mit Shorty's Variante.

Wenn das nicht das gewünschte Ergenis erzielt, kannich immernoch mein Gitter zur Verfügung stellen.

Gruß
Thomas S.

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

@Clinton:
Da hat Herr Schumacher wohl einen Nerv getroffen? Das führt doch jetzt in die falsche Richtung.

Es geht um konstruktive Kritik... und nicht um "plattlabern"!

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

---

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

Junge, Junge...

Zurück zum Thema. Leider keinen Erfolg bis jetzt.

"When not to extrude surface. 0 is flat surface, 90 is when two faces make straight angle."

featureAngle 0

featureAngle 90

Das Bild meines ersten Posts zu dem Problem war mit featureAngle 30.

Habe das Layering der Inlets/Outlets ausgestellt, da ich Layer ja nur am Mantel benötige. @Shorty: Wie würdest du den Parameter einstellen?

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

---

nimm mal einen Wert zwischen 70 - 80 !

------------------
Grüße Tobias H.

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

---

@Shorty: Leider recht ähnliches Ergebnis.

@all: Eine wichtige Sache noch. Würde nun doch gern die STLs in Meter konvertieren, damit ich mit den Einheiten nicht durcheinander komme. Die Frage ist nur: Wie? Mit welchem OpenSourceTool? Gmsh? Blender?

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

---

surfaceTransformPoints file.stl file_m.stl -scale "(0.001 0.001 0.001)"

Müsste klappen.

thomas S.

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

Ich bedauere wegen dieser Kleinigkeit nachfragen zu müssen, aber das gebe ich wo ein?

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

---

Sorry.
Das ist ein OpenFoam Utility. Also kann z.B. in deinem triSurface Ordner durchgeführt werden. (Command Line)

Thomas S.

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

Oh Gott, so einfach, so gut! Danke! Gerade eben noch ne Diskussion von dir und Shorty zum gleichen Thema hier im Forum gefunden 

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

---

Hallo Bioniker,

featureAngle

Sollte dir helfen.
Ggf. einfach mal mit dem gesnappten Mesh starten und die Netzqualitätskriterien ausschalten. Es könnte sein,
dass dir sHM deine Layer dort wieder zerstört.

------------------
Grüße Tobias H.

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

---

Dazu der Hinweis, das snappy die Layer lokal zerstört um weiter drin im Volumen die Gitterqualität zu gewährleisten.
Das Ausschalten der Qualitätskriterien sollte in der Tat zu sehr schönen Layern führen. Allerdings ist die Qualität anderswo dann schlechter.

Und OF ist SEHR zickig was schlechte Gitter anbelangt.

Trotzdem viel Erfolg.

Thomas S.

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

Da geb ich dir recht Thomas.

Noch was anderes!
Du kannst auch versuchen die Relaxfaktoren stark zu reduzieren!

In einer Verbrennungssimulation musste ich einen Wert auf 0.05 setzen!

------------------
Grüße Tobias H.

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

---

Hat sich erledigt. Vielleicht sollte ich mal weg vom Rechner....

[Diese Nachricht wurde von Bioniker am 20. Dez. 2012 editiert.]

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

---

Code:

---

keyword allBoundary is undefined in dictionary "/media/Daten/OpenFOAM/run/master/aorta/V03_20.12.2012_pulsatil_inMetern/0/p::boundaryField"

---

im Druck-File p hast du ein Fehler.

------------------
Grüße Tobias H.

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

---

Hatte in der boundary-Datei einfach noch allBoundary stehen, die ich nicht benutze und deswegen in sämtlichen 0-Datein natürlich auch nicht definiert hab. man man man

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

---

Ok, nun zu echten Problemen und ich hoffe Clinton wird am Ende nicht Recht behalten.

Habe die bisherigen Rechnungen tatsächlich mit einer 1000fach zu geringen Geschwindigkeit durchgeführt, weshalb auch die Courant-Zahl kein Problem war, was mich schon ein bisschen wunderte. Wie dem auch sei, jetzt ist sie ein Problem.

Die Geometrie ist ca. 0,27m lang (nicht mehr 270m)
Die maximale Geschwindigkeit beträgt 0,43m/s (siehe Diagramm oben)
Selbst ein tausendfach geringerer Zeitschritt (0,00001s statt vorher 0,01s) führt zügig rum Abbruch:

Time = 0.00016

Courant Number mean: 2.0885 max: 75056.9
DILUPBiCG:  Solving for Ux, Initial residual = 0.883695, Final residual = 4.36769e-06, No Iterations 67
DILUPBiCG:  Solving for Uy, Initial residual = 0.906689, Final residual = 4.74847e-06, No Iterations 71
DILUPBiCG:  Solving for Uz, Initial residual = 0.911568, Final residual = 0.000442785, No Iterations 1001
DICPCG:  Solving for p, Initial residual = 0.920162, Final residual = 0.0900877, No Iterations 346
time step continuity errors : sum local = 5.46115e+11, global = -1.54724e+10, cumulative = -1.54724e+10
DICPCG:  Solving for p, Initial residual = 0.80378, Final residual = 0.00226868, No Iterations 1001
time step continuity errors : sum local = 1.5915e+18, global = -1.98638e+17, cumulative = -1.98638e+17
DILUPBiCG:  Solving for epsilon, Initial residual = 0.999998, Final residual = 409.836, No Iterations 1001
bounding epsilon, min: -5.32188e+42 max: 4.60659e+42 average: 2.77615e+37
DILUPBiCG:  Solving for k, Initial residual = 0.122977, Final residual = 9.78284e-06, No Iterations 751
bounding k, min: -4.68602e+30 max: 5.75809e+29 average: -6.34026e+25
ExecutionTime = 126.49 s  ClockTime = 127 s

Nehme pisoFoam, da instationär und Turbulenzmodell (k-ohmega-sst?).

Was wären eure ersten Optimierungstipps neben der Netzverbresserung?

Ist so eine Rechnung überhaupt auf einem SinglePC (i7-3770K, 4Kern, 3.5GHz mit 16GB Ram) in sinnvoller Zeit durchführbar?

[Diese Nachricht wurde von Bioniker am 20. Dez. 2012 editiert.]

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

---

Versuch es mit einem noch kleinerem Zeitschritt dt=1e-5s z.B.
Alternative kannst du auch ein gröberes Gitter verwenden.

Zusätzlich könntest du versuchen zuerst staedy zu rechnen um eine vernünftige Startlösung zu erstellen.

Und 4 Cores sind in der Tat ein wenig dünn.
16-24 cores pro Mio Gitterzellen wären besser.

Thomas S.

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

Schließe mich da an. Du solltest erstmal stationär rechnen, bis Du vernünftige Werte raushast. Diese dann als Startbedingung nehmen.

Mit stationären Solvern kommst Du schneller an Erkenntnisse, weils halt nicht so lange dauert  . Mich hat das immer aufgeregt, wenn der ewig gerechnet hat, irgendwann abbrach und es dann an einem eigenen Fehler lag.

Ich habe mit transienten Solvern übrigens die Erfahrung gemacht, dass diese bei schlechten BCs für k und epsilon irgendwann kippen.
(epsilon wird bspw. negativ)
Wenn dein Zeitschrittproblem gelöst ist, vielleicht erstmal "laminar" beginnen, bzw. vernünftige Werte für kEpsilon aus der stationären Lösung nehmen.

Hast Du nicht über Deine Uni Möglichkeiten an Rechenleistung zu kommen?

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

---

aktueller Stand:

Eine stationäre Lösung macht nur bedingt Sinn, da es sich ja um eine pulsatile Strömung handelt, sich die Randbedingungen also eh in jedem Zeitschritt ändern.

Habe gestern einfach noch im internalField mal die Werte des ersten Zeitschritts vorgegeben, hatte ich bis dahin nicht beachtet. Seit 22.30 läuft nun die Rechnung (Zeitschrittweite 0.0001s) und ist exakt jetzt bei 1s angelangt. 1,1s ist ein voller Herzzyklus (wird also 15h dauern) MaxCourantZahlen schwanken um die 0.05, geht hoch bis auf 0.5 zur Zeit der PeakGeschwindigkeit. Es gibt doch sicherlich die Möglichkeit die Zeitschrittweite in der controlDict abhängig von meiner aktuellen EinstromRB variabel zu gestalten?

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

---

ohneNieren.zip mitNieren.zip

Zitat:

---

Original erstellt von t.schumacher:
@ Bioniker:
Versuch es mal mit Shorty's Variante.

Wenn das nicht das gewünschte Ergebnis erzielt, kann ich immer noch mein Gitter zur Verfügung stellen.

Gruß
Thomas S.

---

@Thomas: Da ich nach wie vor keine nennenswerte Verbesserung der Layer erreichen kann, würde ich gern auf dein Angebot zurückkommen, so es denn noch gilt - jetzt nach Ende der Weihnachtszeit? Anbei neben dem Netz ohne Nieren auch das mit Nierenabgängen. Was meinst du?

Beste Grüße,

Felix

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

---

snappyHexMeshDict.zip

Hallo Leute,

die Nieren-Geometrie stellt mich wieder vor die gleichen Probleme wie am Anfang.

Die Kantendarstellung ist miserabel.

Habe die Settings immer weiter verschärft:

// Settings for the snapping.
snapControls
{
    //- Number of patch smoothing iterations before finding correspondence
    //  to surface
    nSmoothPatch 10;

    //- Relative distance for points to be attracted by surface feature point
    //  or edge. True distance is this factor times local
    //  maximum edge length.
    tolerance 0.5;

    //- Number of mesh displacement relaxation iterations.
    nSolveIter 150;

    //- Maximum number of snapping relaxation iterations. Should stop
    //  before upon reaching a correct mesh.
    nRelaxIter 10;

    nFeatureSnapIter 20;
}

trauriges Ergebnis:

Auch das feature edge refinement scheint nicht zu helfen:

    // Explicit feature edge refinement
    // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    // Specifies a level for any cell intersected by its edges.
    // This is a featureEdgeMesh, read from constant/triSurface for now.
    features
    (
        {
            file "Inlet_ASCII.eMesh";
            level 2;
        }
        {
            file "Mantel_ASCII.eMesh";
            level 2;
        }
        {
            file "NiereLinks_ASCII.eMesh";
            level 2;
        }
        {
            file "NiereRechts_ASCII.eMesh";
            level 2;
        }
        {
            file "Outlet_ASCII.eMesh";
            level 2;
        }
    );

Anbei noch die sMH mit dem letzten Stand. Ideen?

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

---

ok, einzig relevanter Parameter scheint folgender zu sein:

nFeatureSnapIter 20;

produziert dann endlich gute Kanten:

Kann mir jemand sagen, was mit den minimalen oberflächlichen Eindellungen ist? Darstellungsfehler in Paraview oder echte Dellen?

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

---

Die "Dellen" sind beim Layern verschwunden. Die kleinen Arterien werden nicht gelayert. Ich nehme an Sie sind zu grob vernetzt, sodass durch die Verschiebung beim Layern ungünstige Zellen entstehen würden?

Da ich schon die spätere Zeitschrittweite und Rechendauer im Kopf habe, was würdet ihr tun?

1. Grundnetz feiner machen?
2. Lokale Verfeinerung über refinementBox?
3. Qualitätskriterien beim Layern ausstellen? Welche?

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

---

Ein frohes Neues allerseits.

Eine weitere Frage hätte ich noch. Um zu überprüfen, nach wie vielen Herzzyklen sich mein System "eingeschwungen" hat, würde ich gern z.B. an einem fixen Punkt im mesh die lokale Geschwindigkeit über die Zeit auswerten.

sampleDict gibt einem ja Werte entlang einer Linie, z.B. um ein U-Profil auszuwerten. Ich bräuchte aber nur einen Punkt.

Edit: Zentrale Frage: Existiert die Möglichkeit Werte verschiedener Zeitschritte in eine Datei schreiben zu lassen, sodass nicht für jeden Zeitschritt eine extra Datei angelegt wird?

Wie immer vielen Dank!

Felix

[Diese Nachricht wurde von Bioniker am 02. Jan. 2013 editiert.]

[Diese Nachricht wurde von Bioniker am 02. Jan. 2013 editiert.]

[Diese Nachricht wurde von Bioniker am 02. Jan. 2013 editiert.]

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

---

Darüber hinaus ist es mir nicht möglich den Vektor zu plotten, sondern nur die Einzelkomponenten:

interpolationScheme cellPoint;

setFormat       raw;

sets
(
    data
    {
        type    uniform;
        axis    xyz;
        start   (-0.030 -0.012 -0.110);
        end     (-0.030 -0.012 -0.120);
        nPoints 10;
    }
);

fields          (U);

Bei Eingabe von:

fields          ( magU )
fields          ( mag(U) )
fields          ( U.component(n) )

wird kein sets-Ordner erstellt. Darüber hinaus kommen am Anfang stets folgende Warnungen (auch wenn sets wie im ersten Fall erstellt wird) Was hat das zu bedeuten?

--> FOAM Warning :
    From function Foam::List<Foam::tetIndices> Foam:  polyMeshTetDecomposition::faceTetIndices(const polyMesh&, label, label)
    in file meshes/polyMesh/polyMeshTetDecomposition/polyMeshTetDecomposition.C at line 565
    No base point for face 181393, 6(80328 43369 80282 34110 80325 43370), produces a valid tet decomposition.

[Diese Nachricht wurde von Bioniker am 02. Jan. 2013 editiert.]

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

---

Hallo Leute,

entschuldigt wenn das Thema für euch schon gegessen war, aber ich habe eigentlich relativ 'lockere' Layereinstellungen:

// Settings for the layer addition.
addLayersControls
{
    // Are the thickness parameters below relative to the undistorted
    // size of the refined cell outside layer (true) or absolute sizes (false).
    relativeSizes true;

    // Per final patch (so not geometry!) the layer information
    layers
    {
        "geometrie_wall"
        {
          nSurfaceLayers 3;
        }
"geometrie_inlet"
        {
          nSurfaceLayers 3;
        }

    }

    // Expansion factor for layer mesh
    expansionRatio 1.0;

    //- Wanted thickness of final added cell layer. If multiple layers
    //  is the
    //  thickness of the layer furthest away from the wall.
    //  Relative to undistorted size of cell outside layer.
    //  is the thickness of the layer furthest away from the wall.
    //  See relativeSizes parameter.
    finalLayerThickness 0.3;

    //- Minimum thickness of cell layer. If for any reason layer
    //  cannot be above minThickness do not add layer.
    //  Relative to undistorted size of cell outside layer.
    minThickness 0.1;

    //- If points get not extruded do nGrow layers of connected faces that are
    //  also not grown. This helps convergence of the layer addition process
    //  close to features.
    // Note: changed(corrected) w.r.t 17x! (didn't do anything in 17x)
    nGrow 0;

    // Advanced settings

    //- When not to extrude surface. 0 is flat surface, 90 is when two faces
    //  make straight angle.
    featureAngle 30;

    //- Maximum number of snapping relaxation iterations. Should stop
    //  before upon reaching a correct mesh.
    nRelaxIter 3;

    // Number of smoothing iterations of surface normals
    nSmoothSurfaceNormals 1;

    // Number of smoothing iterations of interior mesh movement direction
    nSmoothNormals 3;

    // Smooth layer thickness over surface patches
    nSmoothThickness 10;

    // Stop layer growth on highly warped cells
    maxFaceThicknessRatio 0.5;

    // Reduce layer growth where ratio thickness to medial
    // distance is large
    maxThicknessToMedialRatio 0.3;

    // Angle used to pick up medial axis points
    // Note: changed(corrected) w.r.t 17x! 90 degrees corresponds to 130 in 17x.
    minMedianAxisAngle 130;

    // Create buffer region for new layer terminations
    nBufferCellsNoExtrude 0;

    // Overall max number of layer addition iterations. The mesher will exit
    // if it reaches this number of iterations; possibly with an illegal
    // mesh.
    nLayerIter 60;
}

Ich habe 60 Iterationsschritte eingestellt um ein 'besseres' Layer zu erhalten.
Aber ähnlich wie bei Shor-ty generiert er pro Interationsschritt immer weniger Layer.
Angefangen habe ich bei 27% und er geht immer weiter abwärts.
Woran liegt das? Ist meine Geometrie zu komplex? Habe ich in den Parametern etwas übersehen?
In diesem Thread hatte ich keine Antwort auf diese Frage gefunden. Hillfe 

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

---

Edit: Misverständnis

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

[Diese Nachricht wurde von t.schumacher am 18. Feb. 2013 editiert.]

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

---

Die Kanten sind die eine Sache, aber die layer werden ja nichtmal bei einfach gekrümmten Flächen generiert.

.....Moment, ich hatte die letzten Beiträge hier gar nicht gesehen

[Diese Nachricht wurde von ErikP am 18. Feb. 2013 editiert.]

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

---

Ich ersehe trotzdem nichts Brauchbares für mein Problem. Kann es sein dass meine Geometrie einfach zu ungenau ist?

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

---

Was war deine Geometrie nochmal? Ich verwechsel das wohl gerade mit der Aorta von Bioniker.

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

Hi,

noch zur Info. Die Layergenerierung kannst du vor allem mit den "quality-settings" beeinflussen.
Bei den Layer-Einstellungen kenn ich mich noch nicht so gut aus.

------------------
Grüße Tobias H.

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

---

Entschuldige, ich hatte es gar nicht erwähnt.
ich vernetze einen Einlasskanal + dem dazugehörigen Ventil
Also ziemlich genau die Hälfte von dem hier:

https://data.epo.org/publication-server/image?imageName=imgaf001&docId=4769862

Ich darf leider keine Bilder meines Cases schicken, aus Datenschutzgründen, tut mir Leid 
Aber falls es nötig ist kann ich kleinere Ausschnitte veröffentlichen.

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

---

@Shor-ty
Soweit so gut, aber die hgabe ich schon ziemlich hoch eingestellt. Oder ist grade das der fehler?
Was hast du denn z.B. für Refinment Level?
Bei mir sieht das ca so aus:

Refinment Level: (4 6)
nFeatureSnapIter: 20
tolerance: 4.0
nSmoothPatch: 20
resolveFeatureAngle: 60

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

---

Ok, mit Zylinderköpfen kenn ich mich ein wenig aus, was das Vergittern angeht.
26% Layer Coverage sind selbst für Standard OF grottig.
Ohne Bilder zu sehen, würde ich als erstes mal vermuten, dass dein Gitter generell zu grob ist. Bei feinerem Gitter sollte die Generierung der Layer mit deinen Parametern weniger Verzerrungen hervorbringen und erfolgreicher sein. Wieviel Zellen hast du den ungefähr im Spalt zwischen Ventil und Ventilsitz?

Thomas S.

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

Hallo Erik,

du bringst hier wohl einiges durcheinander.

1. Refinement gehört zu castellatedMesh und splittet deine Hexaederzellen (4 6) heißt entsprechend. Alle Zellen die die Oberfläche schneiden werden mindestens 4x gesplittet und an kannten oder Übergängen werden diese 6x gesplittet. Das sind aber dann immer noch Hexaederzellen.

2. tolerance ist was für das "snappen"
http://www.cfd-online.com/Forums/ openfoam-meshing-snappyhexmesh/104449-snappyhexmesh-failing-snap-did-not-find-surface-within.html#post404954

3. nFeatureSnapIter sind die Iterationen die snappyHexMesh durchläuft um deine Zellenpunkte auf die FeatureEdges zu ziehen.

4. nSmoothPatch ist auch was bezüglich der snapping Einstellungen

Für die Einstellungen gibts ne schöne Dokumentation auf dem OpenFOAM Wiki -> snappyHexMesh -> Slides von Eugene

Wie Thomas schon erwännt sind 26% nicht viel. An dieser Stelle gebe ich jetzt an Thomas weiter  er kennt sich mit der Layergenerierung etwas besser aus als ich.

------------------
Grüße Tobias H.

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

---

Achso, ich dachte diese Einstellungen sind evtl wichtig, da sie mein Volumennetz ja beeinflussen.
Sorry, bin Anfänger  

@Thomas
Ich habe 3 Zellen an der engsten Stelle, moment ich fertige 'mal kleinere Ausschnitte an

[Diese Nachricht wurde von ErikP am 18. Feb. 2013 editiert.]

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

---

Layer_2.jpg Layer_1.jpg

Hier sind 2 Ausschnitte. U.a. auch ein Ausschnitt der besagten Engstelle...

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

---

mesh4_small.png

Ok. 3 Zellen sind zu wenig. Zum einen ist es zu wenig für die richtige Darstellung des Strömungsfeldes in der Enge. Aber das ist ja klar, deswegen will man da ja zusätzliche Layer haben.
Für die Layer Generierung mit Standard-snappy sind diese drei Zellen aber auch zu wenig. Wenn snappy dort auf beiden Seiten noch drei Layer reinquetschen soll, dann werden diese drei bereits existierenden Zellen derart verformt, dass sie alle Quali-kriterien reissen. Das checkt snappy ja und generiert deshalb in solchen Fällen keine Layer, da die Gitterqualität oberstes Gebot ist.
Wenn ich mir deine Settings so anschaue dann willst du auf jeder Seite 3 Layer mit einer Expansion Rate von 1 erzeugen, und der letzte Layer soll 0.3* die Größe der Volumenzellen in dem Bereich haben.
Die Expansion Rate ist dort der erste Killer. Auf 1 gesetzt heisst alle drei Layer haben die gleiche Größe = 0.3=30% von der Volumenzelle. Das heisst du versuchst auf jeder Seite (wenn wir mal bei dem Spalt bleiben) fast eine ganze neue Zelle (3x0.3) reinzuzwängen. Diese Verformung macht das Volumengitter in dem Bereich nicht mal annäherungsweise mit.

Also erster Schritt: Expansion Ratio auf 1.25 oder sogar größer setzen. Das sollte deine 26% verbessern, da das heisst, das deine beiden wandnahen Layer schonmal schmaler sind als der wandferne Layer. (nämlich jeweils um den Faktor 1/1.25). Ich nehme stark an, dass das in deinem Fall (Spalt) aber auch nicht viel helfen wird. Ich würde dort auf jeden Fall noch ein Refinement Level mehr spendieren und den Expansion Ratio eventuell auf 1.35 hoch ziehen.

Und noch ein Tip zur finalLayerThickness = 0.3
Ein niedriger Wert hier hilft sicherlich bei der Layer Coverage, allerdings entspricht ein Wert von 0.3 einem Expansion Ratio (layer zum Volumengitter) von 1/0.3 = 3.33
Ich persönlich versuche finalLayerThickness immer größer als 0.5 zu wählen um einen smoothen Übergang zwischen Layern und Volumenzellen zu erhalten. Sinn der Layer ist es ja nicht einfach da zu sein (Mann kann auch wunderbar ohne Layer auskommen wenn man genügend Zellen hat) sondern eine gute Abbildung der wandnahen Strömung zu gewährleisten. Wenn man 10 wunderschöne Layer an der Wand generiert mit einem Expansion Ratio von 1.25 und dann aber vom wandfernen Layer zur ersten Volumenzelle um den Faktor 3 springt hat man gar nichts gekonnt.

Anbei ein älteres Beispiel. Der Spalt ist nicht so schmal wie bei dir, aber die Layer sind gut zu sehen. Hier habe ich unabhängig vom Refinement Level den wandnahen Layer in der Höhe festgehalten und die Expansion ratio vorgegeben (sowie die final Layer Thickness). Die Anzahl der Layer rechnet sich snappy je nach lokalem Refinement Level selbst aus. Das geht aber mit Standard snappy nicht, soweit ich weiss. (Wer ist der Träger deiner Studiarbeit, kannst du das per PM verraten?)

Noch ein Tip. Setzt dir ne kleine Excel Tabelle auf um dir die Layer mit den jeweiligen Settings zu veranschaulichen.
Ziel sollte es sein, dass man im fertigen Gitter nicht auf Anhieb sehen kann wieviele Layer eigentlich da sind, bzw. wo die Layer anfangen (siehe z.B. unten links im Bild)

Thomas S.

------------------
Helyx-OS - Frei verfügbares GUI für OPENFOAM

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

---

Dass die Layer nicht ausreichen für weitere Berechnungen ist mir durchaus bewusst. Wir haben uns die Vernetzungen der Einlasskanäle sonst immer manuell aufbereitet und die Vernetzung als auch die Layer in dem komerziellen Programm Ansa erstellt. Da haben wir 10 Layer verwendet. Aber ich wollte mich langsam an unser Optinmum herantasten und dachte, dass sich drei Layer leichter generieren lassen.
Also unser Anspruch sind 10 Layer mit einer Final Layer Thickness von 0.3, aber das hat sHM nicht auf Anhieb hinbekommen...

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

---

Kann man mein Problem vielleicht auch auf den feature angle zurückführen? Also den Winkel für die Layergenerierung. Ich stelle den 'mal auf 90° und gucke was passiert.

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