[gmx-developers] mpi and thread command line options

Roland Schulz roland at utk.edu
Wed Jul 11 09:36:32 CEST 2012


On Wed, Jul 11, 2012 at 3:12 AM, Berk Hess <hess at kth.se> wrote:
> Hi all,
>
> Thanks for all the feedback.
>
> What I forgot to say is that most users will not have to look and
> probably will not look
> at all these options, as we will automate things as much as possible.
> Furthermore, with the group cut-off scheme (the only scheme pre-4.6) openmp
> threads are not even supported, so there is not much option. With the
> Verlet scheme
> combining MPI processes/threads with openmp threads is slower, except at
> the scaling limit. Within a single CPU openmp threads might be faster
> than mpi.
> We can handle all these cases, except for optimization at the scaling limit,
> automatically when using all available cores.
>
> While thinking of this, and if we don't add mpi spawn, I came up with a
> new proposal:
> -nt total number of threads (effectively the same functionality as in 4.5)
> -ntmpi number of MPI threads (advanced option)
> -ntomp number of OpenMP threads (advanced option)
I like this proposal for a binary with tMPI.
What if the binary is compiled with real MPI (GMX_MPI)? Would then
"-nt" and "-ntmpi" be invalid options and "-ntomp" have the same
meaning as for tMPI? Or would "-nt" also be a valid option and would
have the same meaning as "-ntomp"? I slightly prefer making "-nt"
invalid, because it would give an error if the user thinks the mdrun
binary is compiled with tMPI and wants to use "-nt" for total number
of threads.

What about setting a different number of OpenMP threads for PME nodes?
Do we want to have a (potential hidden) command line flag for that
(e.g. ntomp_pme) or will this only be possible with environment
variables?

Roland

> In this way the user would not have to worry/know about MPI and openmp
> threads
> and would not have to set anything, or only -nt when using part of a node;
> mdrun can choose the optimal number of MPI and openmp threads.
> We might move away from openmp in the next release, but if users would
> almost
> never use -ntomp, renaming that option later is not problematic.
>
> Cheers,
>
> Berk
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
>
>
>



-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309



More information about the gromacs.org_gmx-developers mailing list