Problem when importing a Gmsh file

Dear all,

I generated an approximately ideal plate mesh of about 14,500 eles combining triangles and quadrangles. Since the height of the plate is close to zero, I had to pull the first layer as close as to the boundary wall, which made the whole domain a bit strange. My initial thought was to generate a mesh only containing quadrangles to get a better behavior of numerical dissipation and dispersion in later 3d simulations (See the paper). However, limited by the minimal size, I couldn’t generate a pure unstructured mesh with quadrangles.

When I imported the mesh file into .pyfrm format, an error came out accidentally as follows

/usr/proj_tf/pyfr-env/lib/python3.9/site-packages/pyfr/readers/base.py:252: 
RuntimeWarning: invalid value encountered in true_divide
  lin = lidx[petype] = np.all(num / den < lintol, axis=1)

But a .pyfrm file was built in the folder, so does it make any sense to keep running? The origin .msh file and the .pyfrm file are attached below.

Regards, Thatcher
Mesh Files

This error implies that an element in your mesh has zero volume and is hence invalid. I am also unsure why you are even getting close to minimum size limits for elements; this indicates that your problem may not be well normalised.

Regards, Freddie.

I had a look at your mesh, and when you transition from the structured near-wall region to the unstructured mesh, there is at least one place where there are hanging nodes. These are not supported in PyFR, so you might want to do a bit of re-meshing.

Hi @fdw @WillT ,

Thanks for your kind replies. I rechecked my mesh file carefully, and found two places where the hanging nodes existed. I refined my mesh by creating fields at the corner, but the absence between nodes remained the same. I tried to change a different 2D mesh algorithm in the Mesh-General options, and the MeshAdapt algorithm can solve the problem in a finer mesh.

I looked up the Gmsh docs, and found that different algorithms had its applicable occasions, which was of great help and offered a direction before meshing.

For very complex curved surfaces the “MeshAdapt” algorithm is the most robust. When high element quality is important, the “Frontal-Delaunay” algorithm should be tried. For very large meshes of plane surfaces the “Delaunay” algorithm is the fastest; it usually also handles complex mesh size fields better than the “Frontal-Delaunay”. When the “Delaunay” or “Frontal-Delaunay” algorithms fail, “MeshAdapt” is automatically triggered. The “Automatic” algorithm uses “Delaunay” for plane surfaces and “MeshAdapt” for all other surfaces.

PS. The unusual hanging mesh looks like this:

Regards. Thatcher