[Question] Using Boost

[matekelemen]

As far as I know, we're asking our users to have a complete installation of boost. However, we only use it for its old linear algebra library (and some other places sporadically but those can be refactored to be used without boost).

My question is whether we're planning to

1. continue using a full installation of boost
2. cut the boost dependency and move only its linear algebra components directly to our 3rd party libs (same as pybind for example)
3. ditch boost altogether

The reason I'm asking is because I need to implement multicolor gauss-seidel and I need a graph coloring algorithm for that. Boost's graph lib has an implementation and I'm wondering whether I should use it.

@KratosMultiphysics/technical-committee

[philbucher]

I think the long term plan is to ditch boost, but it is not clear how for the linear algebra (aka ublas).

@pooyan-dadvand tried to write a (dense) linear algebra package himself which we even started to integrate, but the effort was too large to complete it unfortunately.

Sparse matrices can already be replaced with the CSR matrices implemented by @RiccardoRossi , but again this is lots of work. This is also a replacement for large parts of our trilinos usage.

There were more discussions in the past on replacing ublas. We thought about Eigen, Blaze and others, but there was no consensus.

Meanwhile there are some efforts to standardize linear algebra in C++, but nothing concrete yet to my knowledge.

Long story short, unless you implement your stuff in the core I would go with boost. I guess you can keep in mind that it might eventually be replaced, but in the worst case your app would have an additional dependency on boost
My opinion 🤷‍♂️

[loumalouomega]

The primary goal is to transition from Boost's older linear algebra implementations to the newer STL linear algebra. However, this integration is planned for C++26 as indicated by the cppreference link on STL Linear Algebra. Given that we're currently using C++17 and the latest C++ standard is C++23, it appears that the full adoption of C++26 features could take some time, potentially not being ready on our end for another six years.

In the interim, a feasible alternative is to leverage libraries that are ahead in implementing future standards. For instance, mdspan has its roots in the Kokkos library, which closely aligns with what will likely become the standard (approximately 98% compatibility expected). This is also the case for linear algebra; many in the community are adopting implementations that will align with the std::linalg standard.

A key benefit of this approach is that once we adopt the STL version, other libraries, such as NVIDIA's linear algebra libraries, will treat the notation as standard. In my opinion, it would be prudent for us to begin adapting our codebase now. This might entail adding an abstraction layer and aligning our code with std::linalg standards, similar to our earlier transitions to smart pointers and the filesystem. This way, we can seamlessly integrate the final versions once released.

Regarding sparse matrices, we plan to utilize @RiccardoRossi's implementation, which is inherently compatible with PetSC. It's crucial that we begin implementing B&S or an equivalent framework using this methodology soon. Delaying this could significantly increase our technical debt as time progresses.

[loumalouomega]

The primary goal is to transition from Boost's older linear algebra implementations to the newer STL linear algebra. However, this integration is planned for C++26 as indicated by the cppreference link on STL Linear Algebra. Given that we're currently using C++17 and the latest C++ standard is C++23, it appears that the full adoption of C++26 features could take some time, potentially not being ready on our end for another six years.

In the interim, a feasible alternative is to leverage libraries that are ahead in implementing future standards. For instance, mdspan has its roots in the Kokkos library, which closely aligns with what will likely become the standard (approximately 98% compatibility expected). This is also the case for linear algebra; many in the community are adopting implementations that will align with the std::linalg standard.

A key benefit of this approach is that once we adopt the STL version, other libraries, such as NVIDIA's linear algebra libraries, will treat the notation as standard. In my opinion, it would be prudent for us to begin adapting our codebase now. This might entail adding an abstraction layer and aligning our code with std::linalg standards, similar to our earlier transitions to smart pointers and the filesystem. This way, we can seamlessly integrate the final versions once released.

Regarding sparse matrices, we plan to utilize @RiccardoRossi's implementation, which is inherently compatible with PetSC. It's crucial that we begin implementing B&S or an equivalent framework using this methodology soon. Delaying this could significantly increase our technical debt as time progresses.

Fenics is already using mdpan: https://github.com/FEniCS/basix/blob/441f496b1bc70fb103b719f86a2ceda211b5b10c/cpp/basix/mdspan.hpp#L1740 and implementation if the one from Kokkos, https://github.com/kokkos/mdspan

[pooyan-dadvand]

@KratosMultiphysics/technical-committee sees that in long term we want to get ride of Boost. This means that if we have an equivalent small library we would choose that one. What shall be avoided is to use the boost as compiled library to be linked to. We have done a large effort in the past to remove such a dependency.

Regarding the migration to another matrix library, we could/should introduce Kratos::mdspan and Kratos::mdarray to be eventually used as proxies to the standard when they become available.

the big problem is that operations like y+=A@x are not yet available in the standard (they are discussed in P1385 which does not seem to make big progress)

we could write our own operators using the infrastructure of AMatrix ton the top of mdspan and mdarray ...