Compatibility with Boost 1.77 and upcoming Boost 1.78

[tamiko]

Opening a more detailed issue in favor of #12732 : It is currently not possible to compile against boost 1.77 and 1.78 with (at least) the following three major issues:

(a) The following code in https://github.com/dealii/dealii/blob/master/source/grid/grid_tools.cc#L5634

const auto leaf = b_tree.qbegin(bgi::nearest(points[i], 1));

triggers

.../boost/geometry/algorithms/detail/comparable_distance/interface.hpp:122:21: error: ‘apply’ is not a member of ‘boost::geometry::dispatch::distance<dealii::Point<1>, boost::geometry::model::box<boost::geometry::model::point<double, 1, boost::geometry::cs::cartesian> >, boost::geometry::strategies::distance::detail::comparable<boost::geometry::strategies::distance::cartesian<> >, boost::geometry::point_tag, boost::geometry::box_tag, boost::geometry::strategy_tag_distance_point_box, false>’

(b) Just trying to compile grid_tools.cc fails with:

[... static assert triggers because of: ...]
.../boost/geometry/algorithms/not_implemented.hpp: In instantiation of ‘struct boost::geometry::nyi::not_implemented_error<boost::geometry::point_tag
, boost::geometry::box_tag>’
[... due to: ...]
.../boost/geometry/algorithms/dispatch/distance.hpp:123:8:   required from ‘struct boost::geometry::dispatch::distance<dealii::Point<1>, boost::geometry::model::box<boost::geometry::model::point<double, 1, boost::geometry::cs::cartesian> >, boost::geometry::strategies::distance::detail::comparable<boost::geometry::strategies::distance::cartesian<> >, boost::geometry::point_tag, boost::geometry::box_tag, boost::geometry::strategy_tag_distance_point_box, false>’

So I am a bit at a loss here. Does this imply that we lost support for our bounding box implementation due to some internal restructuring? If yes, what shall we do? We will need support with newer versions of boost rather sooner than later.

[bangerth]

@luca-heltai ?

[luca-heltai]

I'll try to give a look tomorrow morning our time. It does seem like we need to change something in our box and point traits, but it should be doable.

[marcfehling]

I just tried to build dealii/master with gcc 11.1.0 and boost 1.78.0 on archlinux, and encountered the same problem. Just for your interest.

[luca-heltai]

This is still an issue. I hope I will have some time in the next few days to look into this, but the solution is non-trivial. I'm trying to build a MWE to show that this is an issue on boost side.

[drwells]

Have we made any progress on this? I'll have some time to work on it tomorrow, but if anyone else has notes on what is going wrong I would like to read them.

[luca-heltai]

@drwells , I tried building a minimal example that mimics our classes, but due to lack of time, I was not able to finish it.

The idea is that if you have a custom box type, these no longer work with native boost types. The fix could be as simple as adding some headers, but I was not able to understand exactly where the problem is.

What seems to be the problem is the distance between a point and a box. While this is implemented explicitly for boost native types, it used to be deduced naturally for any other type that implements the correct traits (see our include files deal.II/boost_adaptors/{bounding_box,point,segment}.h.

In versions up to boost 1.76, these traits are enough to guarantee complete interchangeabilty between deal.II types and boost types, including all boost algorithms. From 1.77 onwards, it looks like boost does not understand anymore how to plug things together and build geometrical operations with types that satisfy the box and point concepts, but are not boost::box and boost::point types.

I think this is a bug in boost, not on our side, but I failed in writing a MWE that shows the bug.