Element sizing for different meshing schemes

[pmarty]

Coreform Cubit Version: 2025.8
Platform: Ubuntu (Docker; latest)

Toy Problem

I’m trying to better understand how the input element size in Cubit translates to the edge lengths of the quad elements for different 2D meshing schemes.

Let’s use the following example:

create surface circle radius 0.5 zplane
surface all size 0.05

I’d ideally like the edge lengths of the elements to be as uniform as possible, which is why I apply the following mesh smoothing after constructing the mesh:

surface all smooth scheme edge length
smooth surface all

There are three strategies I can think of that would give us a quad mesh with relatively uniform element sizes:

Option 1: Circle scheme

surface 1 scheme circle
mesh surface 1

Option 2: Pave scheme

surface 1 scheme pave
mesh surface 1

Option 3: Webcut the circle into quadrants and use Polyhedron scheme

webcut body all with plane xplane
webcut body all with plane yplane
merge curve all

surface all size 0.05
mesh surface all

---

Despite the element size being the same across all three schemes, the number of elements is dramatically different:

	Circle	Pave	Polyhedron
Number of Elements	674	384	354

The elements in the polyhedral and circular meshes deviate quite a bit from the 0.05m input as the element size:

Most of the elements in the paved mesh are pretty close to the desired 0.05m though:

However, I’ve found that the paved meshes start to have inconsistent element sizes when the element size is very small relative to the geometry. Here’s what the mesh looks like with an element size of 0.0025m:

I realize I could webcut the domain and then pave each subdomain, but this feels a bit inefficient, given that the circle and polyhedron schemes would be able to mesh the domain much more quickly.

This brings me to a few questions:

1. How does the input element size translate to the size of the elements for the Circle and Polyhedron meshing schemes?
2. Is there some additional setting I can use to achieve a more uniform element size in my mesh using these two schemes?
3. Is there a way of mitigating the above discrepancy in element size when trying to pave surfaces where the element is very small relative to the size of the paving surface?

[kgmerkley]

There are some fairly technical reasons that mesh edge length is not consistent as well as some that are just decisions that the Cubit development team has made over the years in response to user requirements.

Any all-quadrilateral mesh requires an even number of nodes around the boundary. This means that the edge lengths on the curves typically vary from the requested size to accommodate the required number of nodes on the boundary.

The paving algorithm is an advancing front algorithm. The goal is to create the highest quality quadrilaterals, not necessarily elements with the same edge size. The front will advance based on the average edge lengths at a node. Once again this will typically vary from the requested edge length.

When the front converges to a closure condition, quadrilaterals are created to form the closed mesh. These closures will frequently require creating nodes with more or less than four attached edges. You can see that 5-valent nodes (nodes with 5 attached edges) tend to have longer edge lengths than the mean. The 3-valent nodes tend to have shorter edge lengths that the mean. This is primarily a consequence of the closed geometry and the requirement for overall element quality not based on the scaled Jacobian metric and no requirement for a consistent edge length.

The circle schemes are based on pre-determined set of heuristics. Obviously, the edge length was not the fundamental requirement when those schemes were implemented.

I had hopes that edge length smoothing might have some impact. But it appears that once again the element quality requirement overrides the edge length requirement.

Taking your denser mesh as an example,

reset
create surface circle radius 0.5 zplane
surface all size 0.0025
mesh surf 1
quality edge all 1 length

We see that the mean is not exactly .0025, but it is close. There are edges that are more than 3 times than the desired edge length. Note that the standard deviation about the mean is quite small.

   Function Name    Average      Std Dev      Minimum   (id)        Maximum   (id)    
 ---------------    ---------    ---------    ------------------    ------------------
          Length    2.584e-03    4.754e-04    1.165e-03 (229287)    8.386e-03 (228192)

Running successive edge length smooth passes slightly decreases the maximum edge length, but not enough to make the process worthwhile.

surface 1 smooth scheme edge length
smooth surface 1
smooth surface 1
smooth surface 1
smooth surface 1
smooth surface 1
quality edge all length

The edge minimum length and maximum length both decrease.

   Function Name    Average      Std Dev      Minimum   (id)        Maximum   (id)    
 ---------------    ---------    ---------    ------------------    ------------------
          Length    2.585e-03    4.584e-04    1.014e-03 (229287)    8.271e-03 (222864)

Even decomposing the surface won’t create edges with all exactly length of .025. If you set edges of the square so that they are exactly .0025, the length will have to grow out to the circular edge. If I set the outer surfaces as pave, it is better but still not exact.

reset
create surface circle radius 0.5 zplane
create surf rect width .5
body 2 rotate 45 about z
subtract body 2 from body 1 keep_tool
webcut body 1 plane yplane
webcut body 1 3 plane xplane
merge all
surf all size .0025
curve in surf 2 int 200
surf 6 to 9 scheme pave
mesh surf all
quality edge all length global low 0.003 draw mesh

Hope this is helpful,
Karl

[pmarty]

Thank you so much for that very detailed explanation Karl, that has been extremely helpful!

I hope you have a great rest of your week