Re: [AMBER] cpptraj.MPI

From: Daniel Roe <>
Date: Fri, 9 Jan 2015 11:40:17 -0700


As stated in the Amber 14 manual (section "28.2.7 MPI Parallelization
for 'ensemble'"), the MPI version of cpptraj is *only* supposed to be
used with the 'ensemble' command (so e.g. on trajectories from a REMD
simulation), wherein every member of the ensemble is assigned to a
single MPI thread. Therefore, unless you are using the 'ensemble'
command you will get zero benefit from using cpptraj.MPI (as you have
seen). Section "28.2.6 OpenMP Parallelization" has a list of all
actions and analyses that currently benefit from OpenMP, including
2drms and cluster (pair-wise distances calculation and sieved frame
restore only).

Also note that by default OpenMP will use all available threads, and
depending on the action (and various other factors) this may not be
optimal. If the OpenMP version seems slow for some reason you may need
to restrict the number of threads via the OMP_NUM_THREADS environment
variable. In such cases it is recommended that you run some short (~ 1
min in length or so) tests to find what the optimal number of threads
will be.


On Fri, Jan 9, 2015 at 11:30 AM, Jonathan Gough
<> wrote:
> Just a quick question,
> I observed that running either cluster or rms2d using cpptraj.MPI (compiled
> with mpich2) was MUCH slower (orders of magnitude) than just using the
> serial version.
> Is this an artifact of mpich2? are things faster with OpenMP?
> the trajectory is ~32GB, 432 residues, ~600,000 frames.
> I have run it on different machines (48cpu 132GB RAM vs. 8cpu 64GB RAM) and
> gotten similar time lag results.
> any insight would be appreciated.
> Thanks,
> Jonathan
> _______________________________________________
> AMBER mailing list

Daniel R. Roe, PhD
Department of Medicinal Chemistry
University of Utah
30 South 2000 East, Room 307
Salt Lake City, UT 84112-5820
(801) 587-9652
(801) 585-6208 (Fax)
AMBER mailing list
Received on Fri Jan 09 2015 - 11:00:04 PST
Custom Search