Task #1411

Updated by Teemu Murtola about 7 years ago

It is quite unclear what are the plans for @thread_mpi@ in the future. General plans would be good to have to know where to direct refactoring efforts and what approach to take, e.g., (e.g., when moving stuff away from @legacyheaders/@. @legacyheaders/@). Issues to discuss:
* Is there some replacement planned for some or all of its functionality? If so, on what timeframe will such a replacement realistically materialize? Generally, I think the following is the list of functionality it currently provides:
** Basic thread support (wrapping both pthreads and Win32 threads behind a pthreads-like API). Also includes some thread affinity support.
** Atomics support for several compilers/architectures.
** MPI wrappers.
* Do we want to keep it as a separate library, with no dependencies to other Gromacs code?
* Do we want to keep it under a separate license/copyright when bundled with Gromacs?
* Do we want to keep
maintaining it in a separate repository that is synced with the Gromacs code?
** Where is that separate repository, who have access to it etc.? Should the separate repository be under Gerrit?
* Is there some useful content (e.g., tests) in the current separate repository that should be merged into the main Gromacs repository if we are no longer maintaining the separate repository?
** How is code going * Do we want to get synced between the repositories? Are there some limitations on who is allowed to modify and what in the copy that resides in the Gromacs repository?
** Is there someone willing to, interested in, and time available to take the long-term maintenance responsibility for the
keep it under a separate repository? license/copyright when bundled with Gromacs?
* Should we split the basic thread support from the MPI wrappers more explicitly?
* If the plan is to at some point release the library separately, do we need to play nice and never install anything related to the library outside, e.g., @include/gromacs/@? Do we need to support linking against a thread_mpi instance already on the system?

Possible approaches forward (from the Gromacs side of things):
# Reorganize the thread_mpi code in the Gromacs source tree according to the new Gromacs approach (everything under @src/gromacs/thread_mpi/@, or possibly having a separate directory for the basic thread support and atomics).
** This is somewhat difficult to keep in sync with the external repository if we want to keep it, since that probably should not have the same layout.
** If we want to keep the code separate, this needs some explicit policy so that people don't inadvertently add unwanted dependencies.
# Move the thread_mpi code to @src/gromacs/external/thread_mpi/@, and maintain it there.
** Makes it clear that the code is not really Gromacs code, and allows keeping a layout that is closer to the external repository if we ever want to release the code.
** This requires some extra trickery to get working correctly as long as we have installed headers (most notably, @commrec.h@) that depend on @thread_mpi@ and want to keep installing the headers as @include/gromacs/thread_mpi/@ instead of @include/thread_mpi/@.
# Make the thread_mpi a submodule under @src/gromacs/external/@, like is planned for the TNG library in
** This way, the repositories automatically stay in sync.
** Probably not worth the hassle, unless there are more submodules than just thread_mpi.
** This raises the barrier for anyone except dedicated people to contribute to thread_mpi.