[Question] Using Boost

[matekelemen]

[Question] Using Boost

[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 ...

[matekelemen]

Alright, I implemented my stuff without boost and will open a PR when I come back from my holidays.