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., when moving stuff away from @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 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 separate repository?
* Should we split the basic thread support from the MPI wrappers more explicitly?
** How do we do this if the code is in a separate repository? Have subdirectories in that separate repository, and copy them to the Gromacs repository directly under @src/gromacs/@? Or just have separate subdirectories under @src/gromacs/thread_mpi/@ or similar?
* 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.