Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • openfoam openfoam
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 426
    • Issues 426
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 8
    • Merge requests 8
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • openfoamopenfoam
  • Issues
  • #1505
Closed
Open
Issue created Nov 19, 2019 by Admin@OpenFOAM-adminMaintainer

Failed start of simulation due to non-zero "defaultFaces" in a case converted by gmshToFoam

Summary

(I think this issue can be closed. I gave my analysis in the first comment.) I intended to generate 2D mesh by Gmsh (latest version v4.4.1), and then convert it to OpenFOAM (latest version v1906) polyMesh by gmshToFoam. But I found the utility "gmshToFoam" is unreliable. Two example cases are provided here. They have nearly the same configuration but produce different states of mesh conversion. After minor adjustment of the spatial coordinate of a control point in the geometry definition ("bridgeFlow.geo"), "gmshToFoam" might find some faces that belongs to none of any defined physical groups and label them as "defaultFaces" in "constant/polyMesh/boundary". By visualizing the patches, the internal wall, which is expected to be in the same patch, is found to be divided into two patches by gmshToFoam. The non-zero "nFaces" of "defaultFaces" in "boundary" will make the following commands unable to proceed. For example, errors will be met in the operation "decomposePar".

Steps to reproduce

  1. Have Gmsh v4.4.1 and OpenFOAM v1906 in the environment.
  2. Extract zipped files in the example cases.
  3. cd example_failed or cd example_successful
  4. gmsh -3 bridgeFlow.geo
  5. gmshToFoam bridgeFlow.msh
  6. Open constant/polyMesh/boundary and check whether it has non-zero "defaultFaces".

Example case

I've uploaded two cases here. The only differences in their setup are Line 14 and Line 17 in bridgeFlow.geo in these two cases. The "failed" one will produce non-zero "defaultFaces".

example_failed.zip

example_successful.zip

What is the current bug behaviour?

The utility gmshToFoam is unreliable. Sometime it works well (as in 'example_successful'), but after a minor modification of geometry setup of mesh (as in 'example_failed'), it will generate non-zero defaultFaces in constant/polyMesh/boundary and make the workflow unable to proceed.

What is the expected correct behavior?

No defaultFaces appears in constant/polyMesh/boundary, as in 'example_successful'.

Relevant logs and/or images

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v1906                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : v1906 OPENFOAM=1906
Arch   : "LSB;label=32;scalar=64"
Exec   : gmshToFoam bridgeFlow.msh
Date   : Nov 20 2019
Time   : 01:08:37
PID    : 5532
I/O    : uncollated
Case   : /mnt/c/python/Chamorro_thermal/DRL_girder_optimization/example_failed
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

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

Starting to read mesh format at line 2
Read format version 4.1  ascii 0

Starting to read physical names at line 5
Physical names:7
    Surface 1   outlet
    Surface 2   top
    Surface 3   inlet
    Surface 4   bottom
    Surface 5   backAndFront
    Surface 6   bridgeWall
    Volume 7    bridgeFlow

Starting to read points at line 174
Vertices to be read: 14844
Vertices read: 14844

Starting to read cells at line 29989
Cells to be read:43860

Mapping region 5 to Foam patch 0
Mapping region 6 to Foam patch 1
Mapping region 1 to Foam patch 2
Mapping region 2 to Foam patch 3
Mapping region 3 to Foam patch 4
Mapping region 4 to Foam patch 5
Mapping region 7 to Foam cellZone 0
Cells:
    total: 14513
    hex  : 0
    prism: 14513
    pyr  : 0
    tet  : 0

CellZones:
Zone    Size
    0   14513

Skipping tag $Periodic at line 73888
Patch 0 gets name backAndFront
Patch 1 gets name bridgeWall
Patch 2 gets name outlet
Patch 3 gets name top
Patch 4 gets name inlet
Patch 5 gets name bottom

--> FOAM Warning :
    From function Foam::polyMesh::polyMesh(const Foam::IOobject&, Foam::pointField&&, const cellShapeList&, const faceListList&, const wordList&, const wordList&, const Foam::word&, const Foam::word&, const wordList&, bool)
    in file meshes/polyMesh/polyMeshFromShapeMesh.C at line 592
    Found 29357 undefined faces in mesh; adding to default patch.
Finding faces of patch 0
Finding faces of patch 1
Finding faces of patch 2
Finding faces of patch 3
Finding faces of patch 4
Finding faces of patch 5

FaceZones:
Zone    Size
    1   24

Writing zone 0 to cellZone bridgeFlow and cellSet
Writing zone 1 to faceZone bridgeWall and faceSet
End

For the failed case, the block in boundary says:

defaultFaces
    {
        type            patch;
        nFaces          34;
        startFace       50927;
    }

I visualized the location of the 'defaultFaces' by Tecplot. The 2D mesh layout looks like: location_of_defaultFaces The internal wall is dyed with colors for each patch. location_of_defaultFaces_2 The whole internal wall should be in the same patch bridgeWall. However, after the mesh conversion by gmshToFoam, the internal wall is divided into two patches: bridgeWall in the blue color and defaultFaces in the green color, as shown in the picture above.

Environment information

  • OpenFOAM version : v1906
  • Operating system : ubuntu
  • Compiler : pre-compiled binary for WSL of Win10
  • Gmsh version : 4.4.1

## Reattaching the author to the issue ticket: @lyupin ##

Edited Dec 11, 2019 by Kutalmış Berçin
Assignee
Assign to
Time tracking