Re: [AMBER] cpptraj.MPI

From: Daniel Roe <daniel.r.roe.gmail.com>
Date: Fri, 9 Jan 2015 13:45:05 -0700

It will use all available unless OMP_NUM_THREADS is set. You can check
using 'top' or 'ps' on the node its running on. Certain actions like
'radial' will explicitly report the number of threads used.

-Dan

On Friday, January 9, 2015, Jonathan Gough <jonathan.d.gough.gmail.com>
wrote:

> Is there a way to tell how many threads cpptraj.OMP is using?
>
> On Fri, Jan 9, 2015 at 2:10 PM, Jonathan Gough <jonathan.d.gough.gmail.com
> <javascript:;>>
> wrote:
>
> > ahhhhhh
> >
> > my bad. I just realized that OpenMP and MPI are different and not
> > interchangeable (synonymous-different programs that do the same thing).
> >
> > compiling using -openmp now...
> >
> > sorry.
> >
> > On Fri, Jan 9, 2015 at 1:40 PM, Daniel Roe <daniel.r.roe.gmail.com
> <javascript:;>> wrote:
> >
> >> Hi,
> >>
> >> 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.
> >>
> >> -Dan
> >>
> >>
> >> On Fri, Jan 9, 2015 at 11:30 AM, Jonathan Gough
> >> <jonathan.d.gough.gmail.com <javascript:;>> 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
> >> > AMBER.ambermd.org <javascript:;>
> >> > http://lists.ambermd.org/mailman/listinfo/amber
> >>
> >>
> >>
> >> --
> >> -------------------------
> >> Daniel R. Roe, PhD
> >> Department of Medicinal Chemistry
> >> University of Utah
> >> 30 South 2000 East, Room 307
> >> Salt Lake City, UT 84112-5820
> >> http://home.chpc.utah.edu/~cheatham/
> >> (801) 587-9652
> >> (801) 585-6208 (Fax)
> >>
> >> _______________________________________________
> >> AMBER mailing list
> >> AMBER.ambermd.org <javascript:;>
> >> http://lists.ambermd.org/mailman/listinfo/amber
> >>
> >
> >
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org <javascript:;>
> http://lists.ambermd.org/mailman/listinfo/amber
>


-- 
-------------------------
Daniel R. Roe, PhD
Department of Medicinal Chemistry
University of Utah
30 South 2000 East, Room 307
Salt Lake City, UT 84112-5820
http://home.chpc.utah.edu/~cheatham/
(801) 587-9652
(801) 585-6208 (Fax)
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Jan 09 2015 - 13:00:03 PST
Custom Search