Favor exterior_facet_indices over locate_entities_boundary for retrieving complete boundary

[schnellerhase]

This allows for the usage of locate_entities_boundary without providing a 'all true' marker to identify all boundary facets. This increases readability of the use cases, which before had to manually encode this all true function, done in different ways, and refrains from evaluating any marker in these cases altogether.

Fixes schnellerhase#16

[jorgensd]

We already have dolfinx.mesh.exterior_facet_indices that covers this case (https://docs.fenicsproject.org/dolfinx/v0.8.0/cpp/mesh.html#_CPPv4N7dolfinx4mesh22exterior_facet_indicesERK8Topology)
Is there a reason for adding a specialisation for the locate_entities_boundary function?

[schnellerhase]

Right, that is also the one used in locate_entities_boundary before - and thus we could return there already.

Wasn't really aware of that functionality to be honest - but passing that through the same interface seems like a good way to go nevertheless. So the difference between a specially marked boundary and the default whole boundary is just the marker not a different function.

[jorgensd]

Right, that is also the one used in locate_entities_boundary before - and thus we could return there already.

Wasn't really aware of that functionality to be honest - but passing that through the same interface seems like a good way to go nevertheless. So the difference between a specially marked boundary and the default whole boundary is just the marker not a different function.

I am not sure it is worth adding special case handling inside an existing function when the original function is already exposed (and used) by people.

[schnellerhase]

I see, maybe we switch to the explicit usage of exterior_facet_indices then in those instances of the here changed code? If they had been used in these demos, I probably would also have not thought about extending the interface in any way.

[jorgensd]

I see, maybe we switch to the explicit usage of exterior_facet_indices then in those instances of the here changed code? If they had been used in these demos, I probably would also have not thought about extending the interface in any way.

I would be happy with that, we should keep one demo to illustrate how to use numpy binary operators, but the rest can go I guess

[schnellerhase]

On a second thought the exterior_facet_indices only allows access to the top.dim - 1 entities on the boundary, not entities of general dimension - which the special case handling allows for. But I assume this is rather nitpicking to rectify my changes.

[jorgensd]

On a second thought the exterior_facet_indices only allows access to the top.dim - 1 entities on the boundary, not entities of general dimension - which the special case handling allows for. But I assume this is rather nitpicking to rectify my changes.

I am happy to hear what others think.

However, one can use exterior_facet indices + compute_incident_entities to get all entities of lower dimension associated with those facets.

[nate-sime]

I'm not really keen on the optional argument of entities provided to locate_entities_boundary. The philosophy of DOLFINx is to be completely explicit.

[schnellerhase]

So the optional is of the table, I changed to the usage of exterior_facet_indices where possible. This makes an explicit computation of the connectivity necessary before hand.

[schnellerhase]

Sorry for the force push, had to change the author of the commits, git was setup wrong locally.