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
- Have Gmsh v4.4.1 and OpenFOAM v1906 in the environment.
- Extract zipped files in the example cases.
-
cd example_failedorcd example_successful gmsh -3 bridgeFlow.geogmshToFoam bridgeFlow.msh- Open
constant/polyMesh/boundaryand 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".
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
EndFor 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:
The internal wall is dyed with colors for each patch.
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 ##
Activity
I found the origin of the problem is from the
Gmshside, specifically from the unstable behavior of itsOpenCASCADEkernel. After I switch the kernel ofGmshfromOpenCASCADEtoBuilt-in, the behavior ofGmshoutput became more robust, andOpenFOAMworked well with those meshes fromGmsh.I think this issue can be closed now.
By Pin Lyu on 2019-11-20T03:18:21 (imported from GitLab project)
Edited by Admin@lyupin - thanks for the info re: using the 'Built-in' kernel
