Element quality with matched meshes

[KennethEJansen]

When running mesh adapt with matched meshes and lion print verbose, the following line is printed:
Matched mesh: disabling snapping, and shape correction,

Is shape correction disabled throughout the entire mesh or only elements whose closure are classified on the matched model entities?

I am sure you can see where I am going with this. While I understand that there are algorithmic challenges to make quality controls like shape improvement work well when matching must be maintained, it would seem to me that existing algorithms could be applied for elements that do not contact the matched model boundaries.

In my application I am running mesh adapt every 50 steps for likely 10 or even 100,000 time steps and there is a steady degradation of element quality. While some of the problems are at the matched boundaries, the worst ones are in the interior, not even close to the boundary and it would seem to me that these would certainly benefit from shape correction.

[KennethEJansen]

Here are a few paraview->meshQuality->edgeRatio->Threshold pics. Start with the Threshold 40 to see the nearly flattened triangle. Threshold 20, 10, and then 5 show potential cavities that could be created to improve the mesh quality (e.g., presumably remove the bad elements fully contained in the cavity and remesh the cavity). Not sure if this is "available" in the shape improvement tool kit but just sharing an observation regarding the degradation of elements even though I am making isotropic size requests that are within a range of 1 to 0.25 of the original mesh generated (not that factor per adapt cylcle...sizeReq is never smaller than 0.25* size_original_mesh).

[cwsmith]

The print statement is here:

core/phasta/phAdapt.cc

Lines 42 to 48 in 28d2299

	void setupMatching(ma::Input& in) {
	if (!PCU_Comm_Self())
	lion_oprint(1,"Matched mesh: disabling"
	" snapping, and shape correction,\n");
	in.shouldSnap = false;
	in.shouldFixShape = false;
	}

In maMatch.cc the following function appears to disable collapses and swaps on cavities that span the matched boundary.

core/ma/maMatch.cc

Lines 79 to 98 in 28d2299

	void preventMatchedCavityMods(Adapt* a)
	{
	Mesh* m = a->mesh;
	if (!m->hasMatching())
	return;
	Iterator* it = m->begin(0);
	Entity* v;
	while ((v = m->iterate(it))) {
	apf::Matches matches;
	m->getMatches(v, matches);
	if (!matches.getSize())
	continue;
	apf::Up edges;
	setFlag(a, v, DONT_COLLAPSE);
	m->getUp(v, edges);
	for (int i = 0; i < edges.n; ++i)
	setFlag(a, edges.e[i], DONT_COLLAPSE | DONT_SWAP);
	}
	m->end(it);
	}

[como2099]

Hi all,

I realize the last activity in this thread was in 2018, but I wanted to briefly add context and connect it to some ongoing work on my end. Ken was my PhD advisor; I am now a postdoc at CU Boulder working under a different PI. I previously used Chef extensively with PHASTA for mesh partitioning, and I am now beginning to use PUMI’s adaptation capabilities with both PHASTA and LeMANS, another CFD code at CU.

My current focus is on 2D mixed tri/quad meshes, where adaptive refinement is producing degenerate triangles in the interior of the mesh (i.e., not adjacent to matched boundaries). In my use case, the quad boundary layer is frozen and only the triangular far-field region is adapted. Degenerate elements appear both near the quad/tri interface and well inside the triangular region.

Below are a few screenshots illustrating the issue:

From an initial investigation, this appears related to limited quality control during refinement for mixed 2D meshes. In particular:

• Refinement (maRefine.cc) does not perform any element quality checks
• New vertices are placed at edge midpoints without considering resulting element quality
• validQuality / goodQuality thresholds apply to coarsening, swaps, and shape correction, but not refinement
• 2D shape correction (LargeAngleTriFixer) is limited to edge swaps and has no smoothing fallback

I expect that addressing this may require changes that are somewhat invasive, but my goal is to do this incrementally and in a way that can be included in a future release, so that users can rely on the off-the-shelf version rather than a custom branch.

Thanks,
Connor

[como2099]

I’ve opened PR #525 which adds verbose-only diagnostics reporting how many low-quality elements exist after refinement (no behavior change). This helps quantify the issue discussed here, both for tris in the 2D mixed-element mesh case and for tets in the 3D matched mesh case.