[Core] Add parallel try catch to remaining raw omp loops in builder and solver

[rfaasse]

📝 Description
In a previous PR #14193, one of the raw omp loops was provided with error handling. We have found that the other raw OpenMP loops in the same class, the ResidualBasedBlockBuilderAndSolver, result in similar hard crashes on windows.

In the aforementioned PR it was proven that adding these try-catch macros don't have a significant impact on runtime.

There is one small discussion point here about the loop index i, for which I'll add a clarifying comment close to the concerning code.

[rfaasse]

The macro KRATOS_CATCH_THREAD_EXCEPTION expects i to be in scope to report on the thread number (see the following snippet). This is why I renamed the loop variable to i in multiple occasions in this PR. I know that the loop variable technically doesn't represent the thread number. I would like to have your opinions on how to solve this (e.g. do we leave it as is, change the macro, get the thread number in some other way, or some other solution?).

    #define KRATOS_CATCH_THREAD_EXCEPTION \
    } catch(Exception& e) { \
        KRATOS_CRITICAL_SECTION \
        err_stream << "Thread #" << i << " caught exception: " << e.what(); \
    } catch(std::exception& e) { \
        KRATOS_CRITICAL_SECTION \
        err_stream << "Thread #" << i << " caught exception: " << e.what(); \
    } catch(...) { \
        KRATOS_CRITICAL_SECTION \
        err_stream << "Thread #" << i << " caught unknown exception:"; \
    }

[loumalouomega]

LGTM, I guess the performance penalty will be similar to the previous one. Can you run the benchmark again to verify?

[rfaasse]

LGTM, I guess the performance penalty will be similar to the previous one. Can you run the benchmark again to verify?

Thanks for the review! The benchmark only checks the BuildRHS function. In that benchmark we use in a simplified case with 'empty' elements, so it's almost testing an empty loop, so since we found that even with an almost empty loop body the try-catch does not impact performance in any meaningful way, that means that for these other functions, it also can't have a significant impact (since for non-empty loop bodies in a realistic case, the effect will be even less) 👍

[matekelemen]

I would like to have your opinions on how to solve this (e.g. do we leave it as is, change the macro, get the thread number in some other way, or some other solution?).

Since KRATOS_CATCH_THREAD_EXCEPTION is only used in parallel_utilities.h and here, I'd change the macro such that it expects the thread index as an argument.

Otherwise, looks fine.

[rfaasse]

I would like to have your opinions on how to solve this (e.g. do we leave it as is, change the macro, get the thread number in some other way, or some other solution?).

Since KRATOS_CATCH_THREAD_EXCEPTION is only used in parallel_utilities.h and here, I'd change the macro such that it expects the thread index as an argument.

Otherwise, looks fine.

Nice suggestion, implemented! This did mean I needed to create some way of getting the current thread ID from OpenMP in the builder and solver. Curious what you and the @KratosMultiphysics/technical-committee think!

[matekelemen]

Thanks @rfaasse, looks good.

Before someone mentions performance issues related to omp_get_thread_num, I'll note that it only gets called once an exception is thrown and caught, so no overhead on the happy path.

I'll leave the approval to the @KratosMultiphysics/technical-committee @RiccardoRossi @pooyan-dadvand @sunethwarna @roigcarlo @rubenzorrilla.