Daniel Arndt

> I am not super opposed to this, but I am also unsure if it's worth the risk to touch this given the minimal improvement in code cleanliness. The main...

> Changes look logical, but are there tests that would expose the described issue? Not easily. I found this when setting `OMP_NUM_THREADS=1` since we then don't even allocate memory for...

It might be useful to have an `OpenMP` with `OMP_NUM_THREADS=1` since we ran into multiple problems with that.

> I am not sure about this change because `get_thread_data()` should be the same as `get_thread_data(0)` in the case you describe. The real bug might be in `get_thread_data()`. It's a...

> The condition might be wrong. From my understanding the logic in `get_thread_data()` is for the case that `Kokkos` causes nested parallelism, not when we have an external OpenMP parallel...

I aam now using `execute_in_serial` inside `get_thread_data()`. The last commit also removes `m_level` but we can discuss if we want to support creating `OpenMP` execution space instances inside `OpenMP` parallel...

We discussed that we want to disallow using an OpenMP execution space instance in a OpenMP parallel region unless OMP_NESTED is set. This implies that we error out if `execute_in_serial`...

> Is this PR considered a follow up on #7417 ? > Do we want to continue working on it? I would still want to discuss disallowing creating OpenMP execution...

> std::thread::hardware_conccurency is bad I think. I thought we investigated this before. I.e. it did not seem to take into account stuff like process masks? That's what we are using...

@janciesko Do you care about this?