Hello,
On Mon, Feb 22, 2010 at 7:04 PM, Trevor Gokey <tgokey.sfsu.edu> wrote:
>
> Hello,
>
> First I want to say that I am excited abou t the upcoming GPU support in
> AMBER 11. Thanks for the information Ross Wal ker.
>
> I have since moved on to ptraj,MPI while I wa it for AMBER 11. Both OpenMPI
> 1.4.1, Ambertools 1.3, and parallel ptraj com piled without error on my
> Ubuntu system. I used the GNU compilers, gcc 4.4. However, when running
> <mpirun -np 4 ptraj.MPI> command, top shows al l of the processes are in
> the "D" state. The processes seem to randomly go in the "R" state for no
> more than a second, and I've never seen all process es running at the same
> time. Furthermore, running <mpirun -np 4 ptraj.MP I> on a trajectory takes
> longer than -np 2, which takes longer than seri al ptraj. OpenMPI seems to
> be creating the overhead to mulithread, but no u suable multithreading is
> occuring. Running just regular <mpirun ptraj.MP I> produces no "D" state in
> the single process.
I do not have much experience on this part. To my knowledge,
ptraj.MPI is (presently) aimed primarily at parallelizing file
reading. I'm not sure that many of the actual manipulations are done
in parallel yet as of AT 1.3. Someone please correct me if I'm
mistaken. If your trajectory files are not very big, I don't see how
helpful ptraj.MPI will be...
>
> This is probably more of a OpenMPI issue perhaps, but I thought I'd post m y experience on the AMBER board to see if anyone has had this experience. I 've been trying to figure out how to go about debugging OpenMPI, and it see ms like a bear.
>
> On a side note about ptraj.MPI (bu t perhaps pertinent)--the traditional
> ptraj command [ptraj prmtop < infi le] does not work for me with mpirun -np
> 4 ptraj.MPI. It exits with the err or "MULTIPTRAJ must be run with <TOP>
> and <INPUT>". My fix to t his problem is leaving out the < sign, and
> ptraj.MPI worked.
This is subtle, but it's a different way of providing input. The <
sign dumps the input file into the program as stdin (it does not
register as a command-line argument), so ptraj reads the file lines as
standard input rather than opening the file and reading them that way.
Leaving that sign out makes ptraj read it as a file (and now it DOES
count as a command-line argument). I'm guessing it's easier to ignore
stdin streams in a multi-threaded environment and just read files, but
again I may be mistaken here. In any case, ptraj.MPI will quit with
less than 3 arguments (the first being ptraj, second being prmtop,
third being input file).
Thus, taking < out certainly makes it work, and that's all that needs
to be done, and the above is the reason. So here was just a
long-winded explanation for something you figured out how to do easily
enough, though hopefully it'll be at least slightly helpful to
someone.
All the best,
Jason
--
---------------------------------------
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Feb 22 2010 - 17:00:03 PST
