`make_face_restriction` will operate without complaint on non-existent boundary tags about meshmode

[majosm]

One thing that could complicate fixing this is that I think we currently depend on this behavior when running partitioned meshes. If we project onto a boundary, say, some of the partitions may not have any faces on that boundary and thus won't have a corresponding BoundaryAdjacencyGroup in their local mesh. We could probably work around this by adding back the mesh's boundary_tags (🙁) or by adding empty adjacency groups for the remote boundaries. Not sure if either is worth it?

[inducer]

I think it makes sense to able to tell a boundary tag that was never intended to be usable (e.g. one with a typo) from one that's sensible to use but empty (such as a boundary that exists in the mesh in general but not this partition). IMO, it's a quality-of-life improvement that helps avoid unnecessary mistakes.

I agree that the current data structure doesn't do it unaided. Of the two options you describe, I think I could live with having empty adjacency groups. You?

[majosm]

I agree that the current data structure doesn't do it unaided. Of the two options you describe, I think I could live with having empty adjacency groups. You?

Would that include partition boundaries? I think that would make the facial adjacency list comprehensions in the code inefficient, having to iterate over nboundaries + nproc groups (but whether it would be noticeable in practice, I'm not sure).

[inducer]

If nproc counts all processors (instead of neighbors), then I think that would hurt. But I'm not sure that's required. Also, we could add (probably underscored) methods that cache the currently linear-time queries if the expense gets too high.

So I think those inefficiencies are likely avoidable.