[Yuby]

Hi FOAMers! How are you?

Thank you for being there! You have helped me a lot with my thesis.

I have several problems with OpenFOAM. I am studying a external incompressible and turbulent flow around a rotating solid, and I created different regions in order to have different surface refinement as said in this thread: http://www.cfd-online.com/Forums/ope...e-stlfile.html

If I execute the surfaceCheck utility, it says to me that the surface is not closed. Is it correct? I mean, there are two STL in one, because I copied the text from one to another in order to create the patches. Should it be closed or non closed? I'm confused, because snappyhexmesh works with closed surfaces, doesn't it?

Apart from that, if I ran the checkMesh utility after creating the mesh, it gives to me this code:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.3.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.3.0-f5222ca19ce6
Exec   : checkMesh
Date   : Apr 18 2015
Time   : 14:12:02
Host   : "usuario-SATELLITE-P50-A-14G"
PID    : 11020
Case   : /home/usuario/UltraStar/UltraStar2
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

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

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:           5590751
    faces:            16070256
    internal faces:   15907992
    cells:            5248232
    faces per cell:   6.09315
    boundary patches: 7
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     4953182
    prisms:        20105
    wedges:        3
    pyramids:      0
    tet wedges:    320
    tetrahedra:    18
    polyhedra:     274604
    Breakdown of polyhedra by number of faces:
        faces   number of cells
            4   14843
            5   10504
            6   27960
            7   93719
            8   33053
            9   67083
           10   1357
           11   427
           12   16517
           13   91
           14   79
           15   8942
           16   3
           17   1
           18   25

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
                   inlet       64       81  ok (non-closed singly connected)
                  outlet       64       81  ok (non-closed singly connected)
                     top       96      117  ok (non-closed singly connected)
                  bottom       96      117  ok (non-closed singly connected)
            frontandback      192      234  ok (non-closed singly connected)
                   disco   143962   159636  ok (non-closed singly connected)
                   borde    17790    23446  ok (non-closed singly connected)

Checking geometry...
    Overall domain bounding box (-1.5 -2 -2) (4.5 2 2)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-7.13842e-17 -9.7482e-19 1.71727e-17) OK.
    Max cell openness = 4.32984e-16 OK.
    Max aspect ratio = 11.6759 OK.
    Minimum face area = 1.75439e-09. Maximum face area = 0.250366.  Face area magnitudes OK.
    Min volume = 9.42071e-13. Max volume = 0.12522.  Total volume = 95.9998.  Cell volumes OK.
    Mesh non-orthogonality Max: 64.9667 average: 6.00776
    Non-orthogonality check OK.
    Face pyramids OK.
 ***Max skewness = 4.7363, 4 highly skew faces detected which may impair the quality of the results
  <<Writing 4 skew faces to set skewFaces
    Coupled point location match (average 0) OK.

Failed 1 mesh checks.

End

This skewness is due to both STL files, if I join them in one STL this warning doesn't appear. Can I work with this problem? Is it an high value of skewness?

Thank you very much in advance!

[Yuby]

Anybody can't help me? Is it possible to run a snappyhexmesh case with a STL geometry that is not closed due to that?

[wyldckat]

Greetings Rubén,

Since you didn't provide the output given by surfaceCheck, it implies you're asking us to guess what could be wrong with your geometry, if anything at all. And guessing takes longer to both think about and explaining...

Anyway, merging one or more STL files into a single STL file does not guaranteed that the single STL file is closed. It could have enough flaws in the geometry for it to mean that the geometry is not closed.
Another detail is that STL format requires the geometries to be defined by triangles. Furthermore, for a surface to be fully closed, all vertices in the triangle list should be connected to other vertices. If there is a vertex that is only nearby an edge of another triangle, that automatically means that those two triangles are not connected, since they are not connected by a common vertex. This is probably why surfaceCheck is complaining.

Now comes the answer to the other part of your question: when a single STL file is used, it helps snappyHexMesh to decide how to treat the geometry, namely if it's a single geometry that is composed by one or more named solids that are to be interpreted as boundaries (aka patches). This is probably why the skewed faces don't appear when you have a single STL file.
Because when you give 2 independent STL files, you're implying that they are independent and that any overlapping should be considered an accident and not something intentional... which is why the mesher then gets confused as to why those two geometries are overlapping or near each other and isn't certain how the mesh vertices should relate to each surface.

Does this explain your questions?

Oh, another detail: technically, the geometries in the STL files don't need to be perfectly sane (all triangles must be connected to other triangles), but it does help the mesher to not make any unwanted mistakes

Best regards,
Bruno

[Yuby]

Oh Bruno, thank you for that complete answer!

I don't have such deep knowledge in CAD, so this explanation has showed to me many things. In fact, I though that every geometrry should be perfect in order to be computed

In this tutorial https://www.youtube.com/watch?v=ObsFQUiVi1U he attachs the whole solid in one STL and the parts in other independent STL files. He includes every STL (included the entire solid) in snappyhexmesh and it works!

I haven't tried this way, but I think that it prevents holes for being created. I had joined every part of the STL in one STL file as I said, with a text editor.

Thank you for your help!