Use MPI_Init_thread if OpenMP is enabled

[cniethammer]

If MPI is used in a multi-threaded environment the MPI implementation has to be aware of the calling context of MPI methods. Therefore, initialize the MPI environment with MPI_Init_thread requesting the desired thread support level. So far ls1 makes MPI calls only from the main thread, i.e., uses MPI_THREAD_FUNNELED. For details see the MPI standard.

[FG-TUM]

Just a bit of readability

[cniethammer]

Based on the feedback and diving deeper into the MPI standard, I refactored this PR.

Note:

• The logging infrastructure is not available at this point in the code. Therefore mardyn_exit() cannot be used, because it uses the Logger internally.
• I replaced MPI_Init() with MPI_Init_thread() entirely now. The MPI standard says here 'A call to MPI_INIT has the same effect as a call to MPI_INIT_THREAD with a required = MPI_THREAD_SINGLE." (MPI 4.1 p.486)

[cniethammer]

@HomesGH Can we merge this after the taking into account our comment and changes?

[HomesGH]

@HomesGH Can we merge this after the taking into account our comment and changes?

I am fine with this PR but please note this open conversation by @FG-TUM .

[FG-TUM]

One style suggestion and one important change.

[FG-TUM]

Suggested change

	std::cerr << "ERROR: ls1 was build with OpenMP. However, the MPI implementation does not provide the necessary thread support level." << std::endl;
	MPI_Abort(MPI_COMM_WORLD, EXIT_FAILURE);
	::exit(EXIT_FAILURE);
	MARDYN_EXIT("ERROR: ls1 was build with OpenMP. However, the MPI implementation does not provide the necessary thread support level.");

Please use the exit macro for consistent exit behavior.

[cniethammer]

We cannot use the mardyn_exit macro as it relies on the logger infrastructure, which is not initialized at this point in the program (and may also dependson the MPI part). However, IMHO, we are so early in the program, that we do not need the extensive logger.

[FG-TUM]

However, IMHO, we are so early in the program, that we do not need the extensive logger.

I respectfully disagree, especially when looking at your related PR #358. Adding exceptions to a pattern like this makes the code more confusing, prone to set bad precedent for new developers, and needs clear documentation.
I'll add a suggestion on how to tackle the issue in the mentioned PR.

[cniethammer]

OK, then I'm looking forward to your suggestion to address the Logger issues in a cleaner way

[FG-TUM]

-> here you go :)

[cniethammer]

Thanks for the inspiration!
I will update this PR when #359 is merged.