Kratos and using newer C++ Standards

[philbucher]

With C++20 about to be published I think it is time that we re-evaluate the standard of C++ that we are using in Kratos.
Currently we are using C++11, which was introduced over 4 years ago (was before my time so I don't exactly know).

A nice overview of new features can be found in this repository. This is generic and of course there are many new features that can be used, but I intend this issue to be Kratos specific, i.e. how can Kratos benefit from using newer standards.
Please anyone feel free to add to this list in case I forgot something.

I am intentionally not proposing a date for when to update, this is completely up for discussion since it affects everyone.

IMO the problem with waiting too long is that we write more and more "old" code that could be written better with a newer standard. To me it is often disappointing when googling a problem and I find that I have to do some hacky solution, even though a newer standard solves this nicely.
Furthermore the sooner we update the sooner everyone will learn / make use / benefit from the new features.

Of course switching to a newer C++ standard will require newer compilers. I did a bit of research and added them to the overview to help with the decision making.

For comparison here are the versions of the current releases of the compiler:

• GCC: 9.3
• Clang: 10
• MSVC: VS 2019, 16.5
• Intel: 19.1

Personally I would go for C++17, since I think it provides a lot of new features that we could really use

Since this affects everyone and will force us to drop support for some older systems, please feel free to add your opinion @KratosMultiphysics/all

C++14

• pybinds overload_cast With this we should be able to give our python-interfaces a major cleanup!
• auto for function return types
• using std::make_unique instead of our own implementation. Minor change, it will still be used as Kratos::make_unique
• improvements in lambdas
• deprecated attribute, then we no longer need our own

Compiler support:

• GCC: 5 (released 2015)
• Clang: 3.4 (released 2014)
• MSVC: VS 2015 (mostly) (released 07/2015)
• Intel: 17 (Kratos anyway needs 18 bcs of pybind)

C++17

• parallel algorithms! this is a very important feature, see e.g. #943 or https://github.com/cpp-taskflow/cpp-taskflow
• std::filesystem. Then we could again remove what I added in #6061
• Overall more things can be done at compiletime (aka templates) which should improve the runtime

Compiler support:

• GCC: 8 (05/2018)
• Clang: 7 (released 09/2018)
• MSVC: VS 2017, 15.7 (released 05/2018)
• Intel: 19.0.1 (released 09/2018)

C++20

• From what I read it has a lot of great new features
• Not fully published yet, hence also no full compiler support yet
  => probably not feasible for us to use anytime soon

[loumalouomega]

IMO I would go to C++17, basically for the parallel and because many cool libraries that are appearing right now are C++17 compatible only. The bottleneck are the compilers used in the universities and research centers, like CentOS FYI @KratosMultiphysics/altair

[rubenzorrilla]

Would be nice to go to (at least) C++14 to have partial template specialization. I've already encountered some situations that could be resolved in a more elegant manner by using this.

[loumalouomega]

Just leaving here this feature of C++20 https://www.modernescpp.com/index.php/cpp20-a-first-module

[sunethwarna]

Hi, following code snippets also can benefit from std 14 if possible (used in gauss point evaluations). This can be further simplified with std 17 as well. For me, usage looks cleaner and faster :).

Currently, I am using this with replicated version of std::index_sequence from std 14 in std 11.

Usage:

        double tke, rho, nu;
        array_1d<double, 3> r_wall_velocity;
        RansCalculationUtilities::EvaluateInPoint(
                std::tie(tke, rho, nu, r_wall_velocity), r_geometry, gauss_shape_functions, 0,
                TURBULENT_KINETIC_ENERGY, DENSITY, KINEMATIC_VISCOSITY, VELOCITY);

Implementation detail:

template<class TDataType>
void UpdateValue(TDataType& rOutput, const TDataType& rInput);

template<class... TDataTypeArgs, std::size_t... Is>
void inline InitializePartialGaussPointValues(
    std::tuple<TDataTypeArgs&...> rValues,
    const double ShapeFunctionValue,
    const NodeType& rNode,
    const int Step,
    const std14::index_sequence<Is...>&,
    const Variable<TDataTypeArgs>&... rVariables)
{
    int dummy[sizeof...(TDataTypeArgs)] = {(
        std::get<Is>(rValues) = rNode.FastGetSolutionStepValue(rVariables, Step) * ShapeFunctionValue,
        0)...};
    // following line is used to ignore warning of unused_variable can be removed by using fold expressions in c++17
    *dummy = 0;
}

template<class... TDataTypeArgs, std::size_t... Is>
void inline UpdatePartialGaussPointValues(
    std::tuple<TDataTypeArgs&...> rValues,
    const double ShapeFunctionValue,
    const NodeType& rNode,
    const int Step,
    const std14::index_sequence<Is...>&,
    const Variable<TDataTypeArgs>&... rVariables)
{
    int dummy[sizeof...(TDataTypeArgs)] = {(
        UpdateValue<TDataTypeArgs>(std::get<Is>(rValues),
                                   rNode.FastGetSolutionStepValue(rVariables, Step) * ShapeFunctionValue),
        0)...};
    // following line is used to ignore warning of unused_variable can be removed by using fold expressions in c++17
    *dummy = 0;
}

template <class... TDataTypeArgs>
void EvaluateInPoint(
    std::tuple<TDataTypeArgs&...> rValues,
    const GeometryType& rGeometry,
    const Vector& rShapeFunction,
    const int Step,
    const Variable<TDataTypeArgs>&... rVariables)
{
    const int number_of_nodes = rGeometry.PointsNumber();
    const auto indexed_sequence = std14::make_index_sequence<sizeof...(TDataTypeArgs)>();

    InitializePartialGaussPointValues<TDataTypeArgs...>(
        rValues, rShapeFunction[0], rGeometry[0], Step, indexed_sequence, rVariables...);
    for (int c = 1; c < number_of_nodes; ++c) {
        UpdatePartialGaussPointValues<TDataTypeArgs...>(
            rValues, rShapeFunction[c], rGeometry[c], Step, indexed_sequence, rVariables...);
    }
}

[philbucher]

also to add that since we start using lambdas a lot for the ParallelUtilities, we could benefit from at least C++14 where lambda inputs can be auto

[RiccardoRossi]

structured bindings
are also cool

[roigcarlo]

Fold expressions would also be very usefull, specially while exporting interfaces overloaded on variable types etc...

[RiccardoRossi]

Blocker for this is that industrial applications of Kratos need to be backported to CentOS 7 (gcc 4.8)

@pooyan-dadvand will explore the possibility of compiling using devtools and report in the future

[loumalouomega]

Question, CentOS 7 is the final host of the compilation?, I mean, it is used for CI?, could Docker (removing the need to be compatible with gcc4.8) be run in CentOS?, or it is CentOS the OS used in order to sun the simulations? (for example is the OS of a cluster), could be Kubernetes being used on this case?

[RiccardoRossi]

CentOS 7 is currently been used as a baseline for commercial applications. MAYBE it is possible to install devtools there but it needs to be verified that code compiled that way can run on barebone CentOS 7 machines (which is the TODO)

[armingeiser]

As you are mentioining CentOS7:

We also have a project with industry where Kratos is running on CentOS7(until recently even CentOS6). In our case however we deliver a compiled version - so i am not dependent on the compilers my partners have. It was however necessary to add some system libs to the package (@roigcarlo helped us there)

BTW the wheels docker image should be CentOS7 as well if i am not completely wrong?

[oberbichler]

BTW the wheels docker image should be CentOS7 as well if i am not completely wrong?

manylinux2010 -> CentOS 6

[pooyan-dadvand]

Eventually, we move to the Centos8 which has gcc 8.3 (to be verified). So I think we can safely move to a newer standard and keep the solution of dev tools for binaries we release for older machines, (usually the clusters) as suggested by @armingeiser and @oberbichler