Simplify assembler implementation interfaces

[garth-wells]

Use mdspan for multi-dimensional arrays in the (private) assembler implementations. mdspan has crept into the interface in other places, so we might as well use it where it makes things simpler. This change:

• Reduces the number of arguments to assembly interfaces, which improves readability.
• Exposed an error in the Python interface for wrapping 2D arrays
• Removes code lint where data was passed that was not used.
• Has documentation improvements (still more to do).
• In simplifying the code exposed sub-performant code, which has been fixed (Fix bug in coefficient packing #3645).

[jorgensd]

Summarizing:
All 2D structures input to assembly is now an mdspan. This includes:

• integration entities (for geometry, test and trial functions for interior and exterior face integrals)
• Cell_permutations for interior and exterior facets
• Coefficients
• cell permutations for exterior and interior facets

In turn, this means that we do not need to send in the cstride or num facets per cell to the assembler.

Could you be more specific about what bugs you stumbled over, and what the redundant data was?

Finally, should we profile this before merging? This is one of the performance critical places in dolfinx, and is a real test of the performance of md span.

As a side note, should we enforce that the md spans are contiguous in memory?

[jhale]

Looks good. I would also be interested to know about performance.

On a tangential note, what's the general status of C++23 and vendored std::mdspan?

[garth-wells]

Summarizing: All 2D structures input to assembly is now an mdspan. This includes:

• integration entities (for geometry, test and trial functions for interior and exterior face integrals)
• Cell_permutations for interior and exterior facets
• Coefficients
• cell permutations for exterior and interior facets

In turn, this means that we do not need to send in the cstride or num facets per cell to the assembler.

Could you be more specific about what bugs you stumbled over, and what the redundant data was?

1. The line

   dolfinx/python/dolfinx/wrappers/dolfinx_wrappers/pycoeff.h

   Line 30 in 192222e

   e.second.shape(0)),

   should use e.second.size() in place of e.second.shape(0).
2. The redundant data was just code lint in private implementations left over from previous refactorings.

Finally, should we profile this before merging? This is one of the performance critical places in dolfinx, and is a real test of the performance of md span.

I have tested and there is no measurable performance difference.

As a side note, should we enforce that the md spans are contiguous in memory?

It is enforced (and is row-major) by the extents that have been used.

[garth-wells]

Looks good. I would also be interested to know about performance.

No measurable difference.

On a tangential note, what's the general status of C++23 and vendored std::mdspan?

It's available in all major implementations except GCC/libstdc++, see https://en.cppreference.com/w/cpp/23.

[jorgensd]

1. The line

   dolfinx/python/dolfinx/wrappers/dolfinx_wrappers/pycoeff.h

   Line 30 in 192222e

   e.second.shape(0)),

   
   should use e.second.size() in place of e.second.shape(0)

Should this be picked up in a test or is it naturally picked up now that it is an md span and not flattened?

[garth-wells]

1. The line

   dolfinx/python/dolfinx/wrappers/dolfinx_wrappers/pycoeff.h

   Line 30 in 192222e

   e.second.shape(0)),

   should use e.second.size() in place of e.second.shape(0)

Should this be picked up in a test or is it naturally picked up now that it is an md span and not flattened?

It is now picked up by an assertion.