CFD Online Logo CFD Online URL
Home > Forums > OpenFOAM Native Meshers: snappyHexMesh and Others

Working with more than one STL file

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 1 Post By wyldckat
  • 1 Post By Yuby

LinkBack Thread Tools Display Modes
Old   April 18, 2015, 08:15
Default Working with more than one STL file
Join Date: Oct 2014
Location: Madrid
Posts: 44
Rep Power: 3
Yuby is on a distinguished road
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: SnappyHexMesh with local refinement of ONE STLfile

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:                      |
|    \\/     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.

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 is offline   Reply With Quote

Old   April 19, 2015, 11:36
Join Date: Oct 2014
Location: Madrid
Posts: 44
Rep Power: 3
Yuby is on a distinguished road
Anybody can't help me? Is it possible to run a snappyhexmesh case with a STL geometry that is not closed due to that?
Yuby is offline   Reply With Quote

Old   April 19, 2015, 12:08
Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,697
Blog Entries: 34
Rep Power: 88
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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,
Yuby likes this.
wyldckat is offline   Reply With Quote

Old   April 20, 2015, 08:31
Join Date: Oct 2014
Location: Madrid
Posts: 44
Rep Power: 3
Yuby is on a distinguished road
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 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!
wyldckat likes this.
Yuby is offline   Reply With Quote


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
how to calculate mass flow rate on patches and summation of that during the run? immortality OpenFOAM Post-Processing 82 November 25, 2014 14:16
OpenFOAM Installation for navalFoam sachinlb OpenFOAM Installation 21 June 23, 2014 08:07
Trouble compiling utilities using source-built OpenFOAM Artur OpenFOAM Programming & Development 14 October 29, 2013 11:59
DxFoam reader update hjasak OpenFOAM Post-Processing 69 April 24, 2008 01:24
error while compiling the USER Sub routine CFD user CFX 3 November 25, 2002 16:16

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