CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)
-   -   [snappyHexMesh] defining layers in snappyhexmesh (https://www.cfd-online.com/Forums/openfoam-meshing/84337-defining-layers-snappyhexmesh.html)

Leilders January 26, 2011 13:20

defining layers in snappyhexmesh
 
Hi, I've been trying to solve this problem for a while now but I'm stuck.
With Solidworks I made an airfoil, exported it as .stl and meshed it with snappyhexmesh. Flow calculations etc. work fine but now I'd like to add a suction area.

Here lies my problem as I can't figure out how to define that area in snappyhexmesh. I studied the motorbike case what is doing exactly what I want (I think) adding layer-names. Though I don't quite understand how they do it.

I would really appreciate it if someone could help me out here,
Kind Regards,

Leon

jhoepken January 28, 2011 04:23

How I understand your post is, that you would like to have a certain volume around the suction side of your airfoil to be refined? A fairly easy way is to split the STL into two parts, both stored in the same STL. Then you can use the distance refinement of the refinementRegions, where you have to specify refinement levels and distances in normal direction of the foil's surface.

Leilders January 29, 2011 21:47

Hi Jens thank you for your reply,
Let me try to explain again what my problem is;

I have a solid (volume is you wish) in .stl and I'd like to assign different value's to a part of its surface. To do that I think I have to apply a different patch(surface) name to that area (am I right?). In the Motorbike case, didn't understand how they did it.

You are suggesting I split the surface (I have done that, say I have a cilinder I've cut a pie part out of it with the area on the outside that I need). And then put them in the same STL file. Will that allow me to define two surface names?

So it should look like this then?

solid name
facet normal ni nj nk
outer loop
vertex v1x v1y v1z
vertex v2x v2y v2z
vertex v3x v3y v3z'
endloop
endfacet
endsolid name

solid name2
facet normal ni nj nk
outer loop
vertex v1x v1y v1z
vertex v2x v2y v2z
vertex v3x v3y v3z'
endloop
endfacet
endsolid name2

If this works, will the force/lift calculations still be correct as there you have to specify the surface it monitors?

Thanks in advantage,
Leon

jhoepken January 30, 2011 08:13

Your aim is to have the force calculation separated for the suction and pressure side of the airfoil? Then you really should split the stl file into a suction and pressure side part and then hand both patch names to the forces functionObject in your controlDict. You are on the correct way, by storing to parts in the ascii stl file. The naming convention in snappyHexMesh is the following:

  1. You load the stl into snappyHexMesh and give it a name, say FOIL
  2. For the surface mesh, you can access the different parts of FOIL by using FOIL_suction and FOIL_pressure, assuming that you have named the respective parts of the stl suction and pressure
  3. Adding layers works just in the same way
good luck,
Jens

Leilders January 30, 2011 08:28

For the forces I meant it the other way around, I still want the forces etc from the whole foil, not just the one surface;

Quote:

forces
{
type forces;
functionObjectLibs ("libforces.so"); //Lib to load
patches (stlSurface_name); // change to your patch name
rhoName rhoInf;
rhoInf 1.225; //Reference density for fluid
CofR (0 0 0); //Origin for moment calculations
outputControl timeStep;
outputInterval 1;
}
Can I add two patch names here ?

Thanks again, I'll try running it later on today :)
Leon

PS. While we are on the subject, I'm currently using RAS kEpsilon, but my lift coefficients are a factor 10 as high as I'd expect, do you have any suggestions on that too?
For my LiftDir I used: liftDir (-4.01 5.736 0); This vector is not 1, is that a problem?

jhoepken January 30, 2011 08:35

You can add as many patches to the forces functionObject, as you like. I usually use a version of the forces, that has been derived from the original ones, but I have never used the forceCoeffs. To investigate the your force coefficients issue, you can change the magnitude of your liftDir vector (although it should be normalized inside the code) and you could have a look into the respective sources.

Leilders February 2, 2011 14:19

The combining of the two .stl files worked perfectly. I can now add different boundary conditions to both surfaces. Now I have another problem maybe you can help me with.

My simulation fails after Time =474.5 (with 0.5 steps) everything seems to stabilize and then suddenly my bounding k, value's blow up and go through the roof! I'm not that experienced with linux so debugging is a bit hard. (http://openfoamwiki.net/index.php/HowTo_debugging) Can someone allready see what my problem is?


Quote:

#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::multiply(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 void Foam::multiply<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/opt/openfoam171/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#5 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator*<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<doub le, Foam::fvPatchField, Foam::volMesh> > const&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) in "/opt/openfoam171/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#6 Foam::incompressible::RASModels::RNGkEpsilon::corr ect() in "/opt/openfoam171/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#7
in "/opt/openfoam171/applications/bin/linux64GccDPOpt/simpleFoam"
#8 __libc_start_main in "/lib/libc.so.6"
#9
in "/opt/openfoam171/applications/bin/linux64GccDPOpt/simpleFoam"
Also, I'm not realy sure how to define my boundary's. I have this 'wing' with an area that applies suction into the 'wing'. So basically I'd say this is an outlet but I'm not really sure how to define it as all example outlets are pressure defined and I want to set a velocity. (or is this just a stupid approach) Setting a velocity almost immediately crashes the simulation.

Thanks again!

jhoepken February 2, 2011 14:21

I suppose, you've chosen your time step not to suffice the CFL condition.

Leilders February 2, 2011 14:25

I am using simpleFoam.

(using Descretizer so I get a graphic interpretation of what I'm actually doing)

jhoepken February 2, 2011 14:40

I've seen that in the meantime ;), but what is your Courant number? You'll have to provide the log of the last time steps.

Leilders February 2, 2011 15:08

Where can I find that log?

jhoepken February 2, 2011 15:11

Sorry, I haven't used the Discretizer. I usually operate from the console and pipe the output of the solvers to a file. Try to execute
Code:

simpleFoam > log &
in your case folder.

Leilders February 2, 2011 15:23

apparently paraFoam screwed up my logfile as it's empty, I will run another simulation to generate a new log file, but for that one do you have any sugestions on my boundary layer problem?

I see several options, what is the best?
- specify the boundary as a velocity
- specify it as a wall with a velocity set to it
- specify it as an outlet (but not sure how to do that with a velocity set to it)

Can I call on the simpleFoam simulation and make it write a logfile at the same time?

jhoepken February 2, 2011 16:47

Sorry but I've never used the Discretizer before and cannot give you any hints on how to use it. What I can tell you is, that if you start the solver from the command line and pipe the output into a file, you can examine it afterwards.

If you could provide some information on your case setup, we might be able to help you.

  • Boundary conditions
  • Logfile
  • Turbulence model
  • etc.

Leilders February 2, 2011 18:31

2 Attachment(s)
You misunderstood me there, Discretizer is more of an aid as it has limited functionality. For specific functions I still need to edit the filed to my wishes. My boundary problem was therefore more of a general question but I'll try to explain my setup more clearly.

I use:
Simplefoam

Code:

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model RNGkEpsilon
RNGkEpsilonCoeffs
{
    Cmu            0.0845;
    C1              1.42;
    C2              1.68;
    alphak          1.39;
    alphaEps        1.39;
    eta0            4.38;
    beta            0.012;
    sigmak          0.71942;
    sigmaEps        0.71942;
}

This is what discretizer selected, I assumed these are standard values for the k-epsilon model. Something what I still need to familiarise myself with.

I attached the log file (last part as it was too large starting with a stable out put (like the 100 before that) to the part were it escalates), and a picture of my setup (forgot to add a legend).

The flow has an AOA of 35degr to the foil and a magnitude of 10 m/s.
Boundaries are:

Code:

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

internalField  uniform (8.191 5.736 0);

boundaryField
{
    minZ
    {
        type            symmetryPlane;
    }
    maxZ
    {
        type            symmetryPlane;
    }
    maxY
    {
        type            zeroGradient;
    }
    maxX
    {
        type            zeroGradient;
    }
    minX
    {
        type            fixedValue;
        value          uniform (8.191 5.736 0);
    }
    minY
    {
        type            fixedValue;
        value          uniform (8.191 5.736 0);
    }
    stlSurface_Sail
    {
        type            fixedValue;
        value          uniform (0 0 0);
    }
    stlSurface_Suck
    {
        type            fixedValue;
        value          uniform (-1.98 -3.472 0);
    }
}

As you can see in the setup.png there's a flap, oposite of that flap is my suction area. As you can see now I applied a Velocity in its - normal direction. (into the foil, out of my flow region).

I hope this gives you a general idea of what I'm trying to do.
Hope this helps!

Leon


EDIT:
forgot to add the error part that apparently doesn't get stored in the log itself
Code:

#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#1  Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#2  in "/lib/libc.so.6"
#3  Foam::multiply(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#4  void Foam::multiply<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/opt/openfoam171/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#5  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator*<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) in "/opt/openfoam171/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#6  Foam::incompressible::RASModels::RNGkEpsilon::correct() in "/opt/openfoam171/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#7 
 in "/opt/openfoam171/applications/bin/linux64GccDPOpt/simpleFoam"
#8  __libc_start_main in "/lib/libc.so.6"
#9 
 in "/opt/openfoam171/applications/bin/linux64GccDPOpt/simpleFoam"


jhoepken February 6, 2011 09:49

Hi,

I really don't think, that your crash is a purely mesh related issue. The output of checkMesh is ok? Why do you apply this velocity to the suction side of our stl? How are your pressure and turbulent properties boundary conditions defined? What discretisations (in system/fvSchemes) do you use?

Leilders February 8, 2011 17:16

A lot of info here, to answer your question first:

I apply a velocity on my stl suction side because I want to suck air into the stl shape at a certain velocity. I'm not quite sure how else to do that. (I don't know a pressure, I'd like to get that from my simulation)

Most value's are set automatically by Discretizer after I specified my stream boundaries. First a checkMesh, what does the highly skew faces mean?

Code:

leon@ubuntu:~/OpenFOAM/leon-1.7.1/run/35degr$ checkMesh
/*---------------------------------------------------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  1.7.1                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
Build  : 1.7.1-320803922ee1
Exec  : checkMesh
Date  : Feb 08 2011
Time  : 22:01:55
Host  : ubuntu
PID    : 2875
Case  : /home/leon/OpenFOAM/leon-1.7.1/run/35degr
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:          255367
    faces:            690096
    internal faces:  664527
    cells:            217764
    boundary patches: 8
    point zones:      0
    face zones:      0
    cell zones:      0

Overall number of cells of each type:
    hexahedra:    184899
    prisms:        8696
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:    24169

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                 
    maxY                210      249      ok (non-closed singly connected) 
    minX                210      249      ok (non-closed singly connected) 
    maxX                210      249      ok (non-closed singly connected) 
    minY                210      249      ok (non-closed singly connected) 
    minZ                443      542      ok (non-closed singly connected) 
    maxZ                440      539      ok (non-closed singly connected) 
    stlSurface_Sail    22886    24107    ok (non-closed singly connected) 
    stlSurface_Suck    960      1443    ok (non-closed singly connected) 

Checking geometry...
    Overall domain bounding box (-11.75 -11.3595 -6.4365e-09) (11 11 30)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-9.4057e-17 -3.187e-16 3.47678e-16) OK.
    Max cell openness = 1.17936e-15 OK.
    Max aspect ratio = 24.6904 OK.
    Minumum face area = 0.000128757. Maximum face area = 20.3471.  Face area magnitudes OK.
    Min volume = 1.40605e-05. Max volume = 40.675.  Total volume = 15131.6.  Cell volumes OK.
    Mesh non-orthogonality Max: 63.8837 average: 8.84331
    Non-orthogonality check OK.
    Face pyramids OK.
 ***Max skewness = 6.53086, 1830 highly skew faces detected which may impair the quality of the results
  <<Writing 1830 skew faces to set skewFaces

Failed 1 mesh checks.

End




U
Code:

FoamFile
{
    version    2.0;
    format      ascii;
    class      volVectorField;
    object      U;
}

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

internalField  uniform (8.191 5.736 0);

boundaryField
{
    minZ
    {
        type            symmetryPlane;
    }
    maxZ
    {
        type            symmetryPlane;
    }
    minX
    {
        type            fixedValue;
        value          uniform (8.191 5.736 0);
    }
    minY
    {
        type            fixedValue;
        value          uniform (8.191 5.736 0);
    }
    maxY
    {
        type            zeroGradient;
    }
    maxX
    {
        type            zeroGradient;
    }
    stlSurface_Sail
    {
        type            fixedValue;
        value          uniform (0 0 0);
    }
    stlSurface_Suck
    {
        type            fixedValue;
        value          uniform (-1.98 -3.472 0);
    }
}

P
Code:

FoamFile
{
    version    2.0;
    format      ascii;
    class      volScalarField;
    object      p;
}

dimensions      [0 2 -2 0 0 0 0];

internalField  uniform 0;

boundaryField
{
    minZ
    {
        type            symmetryPlane;
    }
    maxZ
    {
        type            symmetryPlane;
    }
    minX
    {
        type            zeroGradient;
    }
    minY
    {
        type            zeroGradient;
    }
    maxY
    {
        type            fixedValue;
        value          uniform 0;
    }
    maxX
    {
        type            fixedValue;
        value          uniform 0;
    }
    stlSurface_Sail
    {
        type            zeroGradient;
    }
    stlSurface_Suck
    {
        type            zeroGradient;
    }
}

epsilon
Code:

dimensions      [0 2 -3 0 0 0 0];

internalField  uniform 34.4963;

boundaryField
{
    maxY
    {
        type            zeroGradient;
    }
    minX
    {
        type            fixedValue;
        value          uniform 34.4963;
    }
    maxX
    {
        type            zeroGradient;
    }
    minY
    {
        type            fixedValue;
        value          uniform 34.4963;
    }
    minZ
    {
        type            symmetryPlane;
    }
    maxZ
    {
        type            symmetryPlane;
    }
    stlSurface_Sail
    {
        type            epsilonWallFunction;
        Cmu            0.09;
        kappa          0.41;
        E              9.8;
        value          uniform 34.4963;
    }
    stlSurface_Suck
    {
        type            fixedValue;
        value          uniform 2.20283;
    }
}

k
Code:

dimensions      [0 2 -2 0 0 0 0];

internalField  uniform 1.49991;

boundaryField
{
    maxY
    {
        type            zeroGradient;
    }
    minX
    {
        type            fixedValue;
        value          uniform 1.49991;
    }
    maxX
    {
        type            zeroGradient;
    }
    minY
    {
        type            fixedValue;
        value          uniform 1.49991;
    }
    minZ
    {
        type            symmetryPlane;
    }
    maxZ
    {
        type            symmetryPlane;
    }
    stlSurface_Sail
    {
        type            kqRWallFunction;
        value          uniform 1.49991;
    }
    stlSurface_Suck
    {
        type            fixedValue;
        value          uniform 0.239628;
    }
}

nut
Code:

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

internalField  uniform 0;

boundaryField
{
    maxY
    {
        type            calculated;
        value          uniform 0;
    }
    minX
    {
        type            calculated;
        value          uniform 0;
    }
    maxX
    {
        type            calculated;
        value          uniform 0;
    }
    minY
    {
        type            calculated;
        value          uniform 0;
    }
    minZ
    {
        type            symmetryPlane;
    }
    maxZ
    {
        type            symmetryPlane;
    }
    stlSurface_Sail
    {
        type            nutWallFunction;
        Cmu            0.09;
        kappa          0.41;
        E              9.8;
        value          uniform 0;
    }
    stlSurface_Suck
    {
        type            calculated;
        value          uniform 0;
    }
}



FvSchemes
Code:

FoamFile
{
    version    2.0;
    format      ascii;
    class      dictionary;
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default steadyState;
}

gradSchemes
{
    default        Gauss linear;  //was 0.5
}

divSchemes
{
    default                          none;
    div(phi,U)                      Gauss GammaV 0.5; //was 0.5 1.0
    div(phi,k)                      Gauss limitedLinear 1;
    div(phi,epsilon)                Gauss limitedLinear 1;
    div((nuEff*dev(grad(U).T())))    Gauss linear;
    //div((nuEff*dev(grad(U).T())))    Gauss linear faceMDLimited Gauss linear 0.85;
    //div(phi,U)                      Gauss linearUpwindV faceMDLimited linear 0.68; //was 0.5 1.0
    //div(phi,k)                      Gauss linearUpwind faceMDLimited Gauss linear 0.2;
    //div(phi,epsilon)                Gauss linearUpwind faceMDLimited Gauss linear 0.91;
    //div((nuEff*dev(grad(U).T())))    Gauss linearUpwind faceMDLimited Gauss linear 0.85;
}

laplacianSchemes
{
    default        Gauss linear corrected;
}

interpolationSchemes
{
    default        linear;
}

snGradSchemes
{
    default        corrected;
}

fluxRequired
{
    default        no;
    p;
}

kind regards,
Leon

jhoepken February 8, 2011 17:19

You will have to spend some more work on your mesh, as checkMesh says: "Failed 1 Mesh checks" and you will not be able to obtain any valid results on such a mesh. Visualise the skewFaces and try to get rid of them.

Leilders February 8, 2011 17:23

Ok thanks, I'll look in to that! as for the velocity on my stl suction side. Do you think that my approach is valid? Can I simulate it this way?

jhoepken February 9, 2011 07:47

Should there be an outlet on the suction side of the stl in reality, or do you want to simply calculate the flow around your shape? If the latter is the case, then don't apply that velocity to your suction side.


All times are GMT -4. The time now is 07:07.