Skip to content

Suitable handling of metrics near required entities

No due date 0% complete

Computing a metric in accordance with the lengths of required edges passing through a required point is a way to:

  • avoid mesh degeneracy near required entities
  • speed up the adaptation as mesh degeneracy and stuck edges are slowing down the process

For now, we compute a required size at required points:

  • this computation is ok for isotropic meshes
  • this co…

Computing a metric in accordance with the lengths of required edges passing through a required point is a way to:

  • avoid mesh degeneracy near required entities
  • speed up the adaptation as mesh degeneracy and stuck edges are slowing down the process

For now, we compute a required size at required points:

  • this computation is ok for isotropic meshes
  • this computation don't work for anisotropic meshes (it is computing as an isotropic metric)
  • metric computation at required points can be disabled with the noinsert option.

Then:

  • the metrics are propagated from required points toward neighbours (advancing-front like algo)
  • this propagation (called required gradation in Mmg) can be disabled or tuned using the hgradreq keyword

Issues:

  • representation of entities on which the propagation applies seems weird for both iso and aniso metrics
  • in aniso mode, we use the simultaneous reduction to evaluate the new metric: often we obtain tensors that seems to have random directions / lengths. It may be linked to collisions in the advancing-front or we may have an implementation issue.
  • how to deal with collisions in advancing front?
  • how to ensure that required gradation / sizes doesn't break the Mmg convergency?