Use cell->face_iterators() in tutorials

[bangerth]

The idiom we now use everywhere for cells is of the form

  for (const auto &cell : triangulation.active_cell_iterators())

It would be nice if we could also do this:

  for (const auto &cell : triangulation.active_cell_iterators())
    for (const auto &face : cell->face_iterators())

or similar. That should not be terribly hard to achieve, and would make a lot of code a lot simpler.

[masterleinad]

It looks like you would need to collect all the global indices of the faces, create a container storing the corresponding face iterators and implement the LegacyForwardIterator interface for using it with IteratorRange.

[peterrum]

I am currently working on a draft. What I was thinking about is to introduce a new Iterator, which stores a CellAccessor/TriaCellIterator<TriaAccessor<dim, dim, spacedim> and a counter [0,2*dim[. The new iterator could simply access the face (TriaAccessor<dim - 1, dim, spacedim>) by calling cell->face(counter).

This would be one very simple implementation. The version described by @masterleinad would be more flexible since it is not per-se connected to a single cell.

[bangerth]

I had thought that implementing it via a cell iterator and an index is the easiest way, but it is true that if one just returned a std::array<face_iterator,2*dim>, then one doesn't even need to do anything else since that can already serve as the argument to a range-based for.

[peterrum]

The version with std::array makes the implementation really short (19 added loc; see #8569)...

[masterleinad]

Yes, no need to use a customer container if std::array does the job.

[bangerth]

@peterrum fixes this in record time (thank you very much!).

We ought to also make the simplifying changes to the tutorials. (Like for the corresponding cell changes, the entire library is too large a code base to effectively change; that's ok -- but we should try to teach the current best practice in the tutorials.)