[Zibi]

Good evening Foamers! I’m rather new in terms of using OF (I’m switching from Ansys) and I don’t know why I obtain wrong results in presumably very simple simulation. To cut a long story short, I’d like to simulate a flow in the pipe (10 mm diameter, 300 mm length). On the inlet I set velocity equal to 0.97 m/s, whereas on the outlet pressure equal to 15 kPa (since the density of the fluid is 1050 kg/m3, the kinematic pressure is equal to 14.29 m2/s2). I’m using simpleFoam solver in which I assume a laminar flow - the Reynolds number is not so high – around 3000 (anyway I got a question about turbulence, but I’ll come to that later on).
Here you can see my boundary condition files and some data files:

pressure file:

dimensions      [0 2 -2 0 0 0 0];
internalField   uniform 0;
boundaryField
{
  thatIsWall
  {
      type        zeroGradient;
  }
  outletPatch
  {
      type        fixedValue;
      value       uniform 14.29;
  }
  inletPatch
  {
      type        zeroGradient;
  }
}

velocity file:

dimensions      [0 1 -1 0 0 0 0];
internalField   uniform (0 0 0);
boundaryField
{
  thatIsWall
  {
      type        fixedValue;
      value       uniform (0 0 0);
  }
  outletPatch
  {
      type        zeroGradient;
  }
  inletPatch
  {    
      type        surfaceNormalFixedValue ;
      refValue  -0.97;
  }
}

turbulence file:

simulationType laminar;
RAS
{
    RASModel        kOmegaSSTSAS;

    turbulence      off;

    printCoeffs     off;
}

controlDict file:

application     simpleFoam;
startFrom       startTime;
startTime       0;
stopAt          endTime;
endTime         2.0;
deltaT          0.005;
writeControl    runTime;
writeInterval   0.1;
purgeWrite      0;
writeFormat     ascii;
writePrecision  6;
writeCompression off;
timeFormat      general;
timePrecision   6;
runTimeModifiable false;

viscosity file:

transportModel Newtonian;
nu             [ 0 2 -1 0 0 0 0 ] 3.3e-06;

Analyzing results in paraFoam, I can see that U and p are constantly increasing – when I finish my simulation on the 2.0 s time point (with dt equal to 0.005 s), the velocity in the pipe reaches 93 m/s, while pressure 5465 m2/s2 (so 5738 kPa). Those results seem unreasonable – in Ansys the max. velocity equals to 1.151 m/s and pressure to 15.5 kPa (14.78 m2/s2). So what am I doing wrong?

The second question is connected with modeling turbulence – I’d like to use RAS kwSST model. For the simulation where I use Newtonian liquid and I know the inlet velocity, I can easily calculate the Reynolds number and some other turbulence parameters necessary to create files. What about a situation for the outlets (where I don’t know the velocity, only pressure) and what about a situation when I don’t know the viscosity (cause e.g. I’m using a power law model)? Thank you in advance for your time and help!

Zibi

[alexeym]

Hi,

It seems, you simulation is just diverging (or is not converged at 2 s, simpleFoam is steady-state solver, so 2 s do not make real sense, let's call it 400 iterations). Could you post:

1. checkMesh output.
2. Solver output just before the end of simulation. Or just whole log-file, since simulation is not long.

[Zibi]

Hello Alexeym,

I'm grateful for your fast response. Indeed, I should have written '400 iterations', thank you for making a clarification. I decided to attach a log file as a separate file, whereas checkMesh output (and also the last solver output) can be found below.

checkMesh:

Mesh stats
    points:           32832
    internal points:  21249
    faces:            332307
    internal faces:   309145
    cells:            160363
    faces per cell:   4
    boundary patches: 3
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     0
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    160363
    polyhedra:     0

Checking topology...
    Boundary definition OK.
    Cell to face addressing 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
    inletPatch          179      106      ok (non-closed singly connected)
    outletPatch         179      106      ok (non-closed singly connected)
    thatIsWall          22804    11433    ok (non-closed singly connected)

Checking geometry...
    Overall domain bounding box (-0.005 -0.005 0) (0.005 0.005 0.3)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (-8.6468e-018 1.35511e-017 7.75888e-019) OK.
    Max cell openness = 2.53749e-016 OK.
    Max aspect ratio = 6.17915 OK.
    Minimum face area = 1.64551e-007. Maximum face area = 1.69073e-006.  Face area magnitudes OK.
    Min volume = 3.26337e-011. Max volume = 7.12368e-010.  Total volume = 2.3447e-005.  Cell volumes OK.
    Mesh non-orthogonality Max: 56.5526 average: 16.2739
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.641243 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

Last solver output:

Time = 2

smoothSolver:  Solving for Ux, Initial residual = 0.0309148, Final residual = 0.00308236, No Iterations 1
smoothSolver:  Solving for Uy, Initial residual = 0.0314383, Final residual = 0.000396976, No Iterations 2
smoothSolver:  Solving for Uz, Initial residual = 0.0168423, Final residual = 0.000215721, No Iterations 2
GAMG:  Solving for p, Initial residual = 0.128034, Final residual = 0.00434386, No Iterations 2
time step continuity errors : sum local = 0.0641924, global = -0.000195599, cumulative = -0.316464
ExecutionTime = 522.224 s  ClockTime = 522 s

End

Concerning the checkMesh option, I can create finer mesh (I did it though) and check results with the use of it. Unfortunately they were the same, so it's not the mesh fault (well, I hope so).

In the log file, there is an initial warning concerning the usage of surfaceNormalFixedValue - when I use fixedValue boundary condition this warning is gone, however, results are the same. Hence, it doesn't have an impact on the simulation results. I had to remove some lines since the size of the file was too big (decided to remove results from time 1.22 to 1.59).

Zibi

[alexeym]

Hi,

Let's start with your mesh. It is tetrahedral with maximum non-orthogonality of 55 degrees. For such a mesh I would propose to use leastSquares gradient scheme and 2 non-orthogonal correctors. It is hard to figure out your schemes from log, yet it is clear, you do not have non-orthogonal corrector iterations at all.

To avoid warning with surfaceNormalFixedValue, use

refValue  uniform -0.97;

Solution is rather far from convergence, your initial residuals stuck at 0.03 from velocity and 0.12 for pressure.

[dickcruz]

Originally Posted by alexeym

Hi,

Let's start with your mesh. It is tetrahedral with maximum non-orthogonality of 55 degrees. For such a mesh I would propose to use leastSquares gradient scheme and 2 non-orthogonal correctors. It is hard to figure out your schemes from log, yet it is clear, you do not have non-orthogonal corrector iterations at all.

Hello Alexey,

Just based on your response here, I'd like to know how does one come to a conclusion on grad schemes based on the mesh.

Sincerely.

[alexeym]

Hi,

@dickcruz

There are:

1. https://ntrs.nasa.gov/archive/nasa/c...0140011550.pdf
2. https://hal.archives-ouvertes.fr/hal-01532882
3. http://www.tfd.chalmers.se/~hani/kur...stPractice.pdf

First two papers discuss order of accuracy of Gauss-Green theorem for estimation of gradients, third is just general "best practices".

In general, in tutorial cases "Gauss linear" is used, which is not quite applicable for non-orthogonal meshes.

[Zibi]

Hello,

I changed all the data you proposed, however, unfortunately I still obtain wrong results: near the inlet the pressure is the highest (3.5e+4 m2/s2) and it gradually decreases till the outlet which has -6.753+3 m2/s2 (yes, with negative sign...). Concerning velocity, the highest values are in the vicinity of the outlet (206.5 m/s), whereas the smallest near the inlet (0.0 m/s, don't know why, since the boundary condition imply that it should be constantly 0.97 m/s). I attach new log file as an attachment and some scripts below:

fvSolution:

solvers
{
    p
    {
        solver          GAMG;
        smoother        GaussSeidel;
        cacheAgglomeration on;
        agglomerator    faceAreaPair;
        nCellsInCoarsestLevel 10;
        mergeLevels     1;
        tolerance       1e-7;
        relTol          0.1;
    }   
    U
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-7;
        relTol          0.1;
    }
}
SIMPLE
{
    residualControl
    {
        p               1e-6;
        U               1e-6;
    }
    nNonOrthogonalCorrectors 2;

}
relaxationFactors
{
    fields
    {
        p               0.3;
    }
    equations
    {
        U               0.7;
    }
}

fvSchemes:

ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default leastSquares;
    //default         Gauss linear;
    //limited         cellLimited Gauss linear 1;
    //grad(U)         $limited;
    //grad(k)         $limited;
    //grad(epsilon)   $limited;
}

divSchemes
{
    default         none;
    div(phi,U)      bounded Gauss linearUpwind limited;
    //div(phi,U)      Gauss linear;
    turbulence      bounded Gauss limitedLinear 1;
    div(phi,k)      $turbulence;
    div(phi,epsilon) $turbulence;
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

I really appreciate your help and feedbacks. Concerning the leastSquares and Gauss linear gradient Schemes, what is the non-orthogonality value 'separating' them? LeastSquares one is better when non-orthogonality is higher than 50 degrees? Didn't have time to deeply look inside the publications you cited, however, will do that in my free time.

Zibi

[alexeym]

Hi,

It would be MUCH easier if you post your case, cause posts are becoming inconsistent. Initially you said, you set fixed value for pressure at the outlet and it was positive, now it is negative. You still do not reach convergence, so values are a little bit meaningless. In the log file there is no signs of convergence, so, guess, you messed up boundary conditions.

Strictly speaking "Gauss linear" is applicable only to the case of orthogonal meshes (this is what papers 1 and 2 are about). So I would use leastSquares even for 20 degrees of non-orthogonality.

[Zibi]

Hello,

My case is as follows: I want to simulate a flow of the incompressible liquid (density equal to 1050 kg/m3) in the straight pipe (0.3 m length and 0.01 m diameter). It is a steady-state simulation, so I decided to use simpleFoam solver. Boundary conditions are as follows:
inlet: velocity equal to 0.97 m/s,
outlet: pressure equal to 15 kPa (so 14.29 m2/s2).

I don't know how can I upload the entire case since all files weight too much (mainly those connected with polyMesh). Anyway, I copy all other files (boundary conditions, fvSolutions, etc.) once more.

U file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       volVectorField;
    object      U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions      [0 1 -1 0 0 0 0];
internalField   uniform (0 0 0);
boundaryField
{
  thatIsWall
  {
      type        fixedValue;
      value       uniform (0 0 0);
  }
  outletPatch
  {
      type        zeroGradient;
  }
  inletPatch
  {    
      type        surfaceNormalFixedValue ;
      refValue  uniform -0.97;
  }
}

p file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       volScalarField;
    object      p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions      [0 2 -2 0 0 0 0];
internalField   uniform 0;
boundaryField
{
  thatIsWall
  {
      type        zeroGradient;
  }
  outletPatch
  {
      type        fixedValue;
      value       uniform 14.29;
  }
  inletPatch
  {
      type        zeroGradient;
  }
}

transportProperties file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      RASProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
transportModel Newtonian;
nu             [ 0 2 -1 0 0 0 0 ] 3.3e-06;

turbulenceProperties file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      RASProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

simulationType laminar;
RAS
{
    RASModel        kOmegaSSTSAS;
    turbulence      off;
    printCoeffs     off;
}

boundary file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       polyBoundaryMesh;
    location    "constant/polyMesh";
    object      boundary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

3
(
    inletPatch
    {
        type            patch;
        nFaces          179;
        startFace       309145;
    }
    outletPatch
    {
        type            patch;
        nFaces          179;
        startFace       309324;
    }
    thatIsWall
    {
        type            wall;
        nFaces          22804;
        startFace       309503;
    }
)

controlDict file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

application     simpleFoam;
startFrom       startTime;
startTime       0;
stopAt          endTime;
endTime         2.0;
deltaT          0.005;
writeControl    runTime;
writeInterval   0.1;
purgeWrite      0;
writeFormat     ascii;
writePrecision  6;
writeCompression off;
timeFormat      general;
timePrecision   6;
runTimeModifiable false;

fvSchemes file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default leastSquares;
}

divSchemes
{
    default         none;
    div(phi,U)      bounded Gauss linearUpwind limited;
    turbulence      bounded Gauss limitedLinear 1;
    div(phi,k)      $turbulence;
    div(phi,epsilon) $turbulence;
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

fvSolution file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  3.0.x                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
    p
    {
        solver          GAMG;
        smoother        GaussSeidel;
        cacheAgglomeration on;
        agglomerator    faceAreaPair;
        nCellsInCoarsestLevel 10;
        mergeLevels     1;
        tolerance       1e-7;
        relTol          0.1;
    }   
    U
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-7;
        relTol          0.1;
    }
}
SIMPLE
{
    residualControl
    {
        p               1e-6;
        U               1e-6;
    }
    nNonOrthogonalCorrectors 2;

}
relaxationFactors
{
    fields
    {
        p               0.3;
    }
    equations
    {
        U               0.7;
    }
}

Concerning the statement 'Initially you said, you set fixed value for pressure at the outlet and it was positive, now it is negative' - indeed, as you can see in the copied file, I set pressure to some fixed value at the outlet. The same goes for velocity - I set fixed value on the inlet. However, when I analyze results, after few first iterations velocity near the vicinity of the inlet is not the value I proposed in boundary condition files, but it is equal to 0 m/s. For the pressure, it gets negative value, so underpressure is created inside the domain (near outlet). And I cannot explain what is going on and why it behaves like that...

Zibi

[alexeym]

Without mesh it would be difficult to find error in your case. Reduce order of discretisation schemes, increase number of iterations.

I have created test 2D axisymmetric case with the same geometry and boundary conditions. It needs et least 407 iterations to converge with upwind discretisation (with second order schemes it even does not converge in laminar case).

You can find archived case attached to the message.

[Zibi]

Hello,

I tried to run a case you sent and it took 418 iteration to converge - the results seem to be appropriate. Hence, unfortuanetly, constant failures are connected with my mesh...
Could I somehow provide you with my mesh file, so you could inspect whether all failures are due to it?

Zibi

[alexeym]

There are (in order of my familiarity with the service):

1. Dropbox
2. Microsoft OneDrive
3. Google Docs

With all of them you can upload your case and post a link to it.

You can even use GitHub or BitBucket to create repository with your case.

[Zibi]

Here is a link to DropBox files with that case:

https://www.dropbox.com/s/yqo58n2dac..._Case.rar?dl=0

Please have a look at those files. Thank you for your time and help.

Zibi

[alexeym]

I though RAR was dead, but no, it is second time people send me RAR archive.

If you run

checkMesh -allGeometry -allTopology

it will reveal that there is a problem with your mesh.

If you set initial conditions for velocity to (0 0 0.97) instead (0 0 0), it could possible to converge with your mesh and limited non-orthogonal correction (i.e. "limited 0.333" instead of "corrected" in laplacian and snGrad schemes). Though finally I have decided, it is a waste of time (it is 400th iteration and residuals for velocity are around 0.003).

Attached is a 3D case with the same geometry BUT with a slightly better mesh. It converges in 99 iterations with the second order spatial discretisation schemes.

[Zibi]

Hello,

Thanks for the files - your case works perfectly, apart from the noSlip condition - my OpenFOAM doesn't recognize it, hence, I switched to fixed value (0 0 0) on the walls. Forgot to mention that during the earlier case.

I checked my mesh with the more advanced checkMesh method as you proposed and you are right - mesh has some errors. That's extremely bad news for me - in my future work I've to use opensource software that creates volumetric mesh from the STL files (without named patches). It's a VMTK software: it loads STL file, performs cuts to open oulets/inlets (simultaneously user can indicate names of particular patch), generates volumetric mesh basing on the surface triangles and then tetrahedralizes it. Afterwards, it saves the Fluent file. I tested it today on a relatively simple geometry, to be precise: a bended pipe. Traditional checkMesh option says that mesh is fine, however, the more advanced one outlines several errors. And that's terrible since I cannot improve the mesh topology. Do you have any idea how to fix/overcome this obstacle or is it a dead end for me?

P.S. Sorry for the late reply, but I wanted to test VMTK output mesh (Fluent mesh) prior to posting.

Zibi

[alexeym]

Hi,

If you need to generate mesh for OpenFOAM from STL, why no use:

1. snappyHexMesh
2. foamyHexMesh
3. cfMesh

All of them will try to generate hexahedral-dominant meshes and will write them directly in OpenFOAM format.

In your algorithm of mesh generation I see to many points of failure. I do not know quality of meshes generated by VMTK; I do not know if VMTK writes Fluent files correctly; I do not know if Fluent files, written by VMTK, can be converted to OpenFOAM correctly. If VMTK is The Vascular Modeling Toolkit, then it can write meshes in other formats, it can generate meshes with boundary layers; though it generates meshes mainly for FEM software. Why not try FEniCS?

[Zibi]

I wanted to give snappyHexMesh a try some time ago, however, my program generates pure STL files - edges between inlet/outlet and adjacent wall are not always sharp (due to marching cubes algorithm), so the 'user' has to cut those areas off and create a proper boundary. Moreover, snappyHexMesh requires STLs with named patches, but STLs that I obtain are label-less. Those two arguments made me use VMTK software.

Concerning the FEniCS software, I haven't ever heard of it. Will try to figure it out - well, I guess I don't have another option anyway.

Zibi

[alexeym]

Maybe I did not get your message right, but I have looked at my cases, where I generate mesh with snappyHexMesh, and STLs there are without any labels. Background mesh defines boundaries, STL surface defines another boundary (so, it is either a hole in the mesh defined by STL or mesh outer surface defined by STL).

So, unfortunately, I do not get your problems with snappyHexMesh. Maybe you can come up with an example case?

Also VMTK can generate meshes, that are more suitable for OpenFOAM, it depends of settings, you provide to the software.

[Zibi]

I will try to explain what I'd like to achieve in my work. I'd like to perform a simulation of the blood flow inside the human cerebral arteries. Moreover, I'd like to create a software that automatically (or at least with minimal user interaction) performs meshing and generates openfoam scripts. I'm reconstructing a complex geometry of the human brain arteries and software I created (so far) can export the STL file of that geometry. To obtain flat surfaces on inlets/outlets I have to somehow cut off specific parts and recreate the flat plane (VMTK is used for that purpose). Since I'd like to simulate a flow inside those arteries, I've to create the internal volumetric mesh (like in Ansys CFX) and again VMTK is used in here. It can export numerous types of meshes, including the Fluent mesh (.MSH) that can be loaded into the Ansys Fluent, CFX and presumably OpenFOAM. Here are some other formats: vtk, ngneut, gambit, tetgen. Unfortunately, as you could observe on the simple mesh I posted several posts before, the mesh had some errors and simulation gave wrong results - so I've to abandon meshes generated by VMTK (will try gambit one though).

If there is an option to perform a simulation basing on the STL file, it could save me. However, the problem begins with the labels of the patches: in order to perform a simulation, there have to be defined boundary names, like inletPatch, outletPatch, someOtherName, etc. In such a complicated geometry, those surfaces are randomly oriented (they have different locations in 'space' and they aren't usually coplanar in the global coordinate frame) and defining them in the blockMeshDict file is rather impossible. To be honest, I have 0 experience with snappyHexMesh and I don't know whether such a complicated issue as defining those patches is even possible. In tutorial cases, everything is practically done - all files are created (so all the vertices, edges, blocks, etc. are defined) so it doesn't help me to understand how to get things done from scratch. And usually all cases I found have patches faced in particular direction (x, y or z), so they are easily defineable.

Zibi

[ashishmagar600]

Hello Zibi,

Looking at your output at final iteration, it sees that your solution is not converged.

Time = 2

smoothSolver:  Solving for Ux, Initial residual = 0.0309148, Final residual = 0.00308236, No Iterations 1
smoothSolver:  Solving for Uy, Initial residual = 0.0314383, Final residual = 0.000396976, No Iterations 2
smoothSolver:  Solving for Uz, Initial residual = 0.0168423, Final residual = 0.000215721, No Iterations 2
GAMG:  Solving for p, Initial residual = 0.128034, Final residual = 0.00434386, No Iterations 2
time step continuity errors : sum local = 0.0641924, global = -0.000195599, cumulative = -0.316464
ExecutionTime = 522.224 s  ClockTime = 522 

End

Just try increasing the endTime, and wait till the solution reaches convergence criteria (as you might have already specified in fvSolution.SIMPLE{} )


Mesh seems fine, according to orthogonality.. add a few nonOrthogonalCorrectors if you want to use the same mesh.

Cheers.