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 gradationin Mmg) can be disabled or tuned using thehgradreq
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?