OpenMPTarget init-join fix

[rgayatri23]

The PR adds verification for OpenMP process and initialization in init-join reducers.
This also fixes the backward_compatibility test failure with the backend.

[dalg24]

How is calling two functions that check preconditions fixing anything?

[dalg24]

If the issue is related to setting the value of MAX_ACTIVE_THREADS

kokkos/core/src/OpenMPTarget/Kokkos_OpenMPTarget_Exec.cpp

Lines 70 to 71 in 6a95b5f

	OpenMPTargetExec::MAX_ACTIVE_THREADS =
	Kokkos::Experimental::OpenMPTarget().concurrency();

why is initialization in OpenMPTargetExec::verify_initialized the proper place to do that?
Why can't it be done at initialization of the backend?

[rgayatri23]

If the issue is related to setting the value of MAX_ACTIVE_THREADS

kokkos/core/src/OpenMPTarget/Kokkos_OpenMPTarget_Exec.cpp

Lines 70 to 71 in 6a95b5f

	OpenMPTargetExec::MAX_ACTIVE_THREADS =
	Kokkos::Experimental::OpenMPTarget().concurrency();

why is initialization in OpenMPTargetExec::verify_initialized the proper place to do that?
Why can't it be done at initialization of the backend?

Yes the issue is related to MAX_ACTIVE_THREADS. That variable is used to calculate maximum in flight teams which in-turn determines the scratch space allocated.
The variable can be set during the backend initialization, which is probably where it should go I guess if we only want to do it only once.

[masterleinad]

The variable can be set during the backend initialization, which is probably where it should go I guess if we only want to do it only once.

Would there be a reason to do it more than once?

[rgayatri23]

The variable can be set during the backend initialization, which is probably where it should go I guess if we only want to do it only once.

Would there be a reason to do it more than once?

No since the arch wont change in between the kernel invocations. I moved the call into initialize.

[masterleinad]

Are these changes still necessary?

[rgayatri23]

Firstly, the message label was wrong which I fixed now.
Secondly, I think yes , we are checking for those in other similar routines too. Not having here was an oversight.

[masterleinad]

Wouldn't it be better to call these functions in execute directly before the dispatch to execute_init_join, execute_reducer,...? In that case, you could also be more precise about the policy used in the error message.

[rgayatri23]

Edited the error message.

[masterleinad]

Suggested change

	Kokkos::Impl::OpenMPTargetExec::MAX_ACTIVE_THREADS =
	Kokkos::Experimental::OpenMPTarget().concurrency();
	Kokkos::Impl::OpenMPTargetExec::MAX_ACTIVE_THREADS =
	concurrency();

[masterleinad]

OK with me.

[dalg24]

The openmptarget build passed. Not waiting on the rest

[dalg24]

@rgayatri23 make sure you add to the changelog
When was this bug introduced? Did you investigate?

[rgayatri23]

@rgayatri23 make sure you add to the changelog When was this bug introduced? Did you investigate?

Yeah this was introduced in when we did #6043