Safe MFEM Export

[jzwar]

MFEM export for multipatch systems

Using Bezman routins

In a current PR in bezman, MFEM export was restructured to only use corner vertices of the splines, and it provides functionality to identify the connectivity, the edge enumeration with identical knot vectors as well as boundary elements. The use of corner-vertices-only makes it available also for arbitrary spline types (which could be handed on the python side).

Problem with misalignment

Still, the MFEM export is not "safe", as is relies on some strong assumptions. MFEM export requires spline patches to be structured, i.e., neighboring elements need to be ordered in the same manner.
Example:

works:
3 --- 2 3 --- 2
|     | |     |
0-----1 0 --- 1
does not work (knot vectors in eta direction misaligned):
3 --- 2 1 --- 0
|     | |     |
0-----1 2 --- 3

This convention is arbitrary, as knotvectors can still be matching between two faces. Further, parametric axis can be arbitrarily changed within a spline. Starting from a random seed, we can propagate this information and permutate axis, which would allow the mfem export for all "structurable" spline patch systems.

Proposal

I would suggest solving this issue in two steps

• Use bezman's ExtractMFEMInformation routine in splinepy. This could be a fast solution to make splinepy accessible for first tests
• Implement permute functionality in splinepy and solve mfem export in two steps. If the routine succeeds in a first try, 🥳 if not, retrieve the connectivity from MFEM and use the permutation functions starting from a seed to structure mesh, let it fail if mesh non-restructurable... imo, restructuring is not super expensive, and should probably be done in python (changing and - if required - flipping knotvectors, reordering ctps).

The first step could be done very fast, the second one would be great for the next HACK DAYS ™️

@j042 I would love to hear your opinion on this...

[j042]

Great

[j042]

any updates?

[j042]

isn't this fixed by now from mfem side?