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