This email contained a .zip file attachment. Raytheon does not allow email attachments that are considered likely to contain malicious code. For your protection this attachment has been removed.
If this email is from an unknown source, please simply delete this email. If this email was expected, and it is from a known sender, you may follow the below suggested instructions to obtain these types of attachments. + Instruct the sender to enclose the file(s) in a ".zip" compressed file, and rename the ".zip" compressed file with a different extension, such as, ".rtnzip". Password protecting the renamed ".zip" compressed file adds an additional layer of protection. When you receive the file, please rename it with the extension ".zip". Additional instructions and options on how to receive these attachments can be found at: http://security.it.ray.com/antivirus/extensions.html http://security.it.ray.com/news/2007/zipfiles.html Should you have any questions or difficulty with these instructions, please contact the Help Desk at 877.844.4712 --- I have modified the code so that all the terminal outputs are done by one executable. I have attached the source files, after compiling type "make go" and the code will execute. The previous code output was from a supercomputer cluster where the two processes resides on two different nodes. When running the same code on a regular-multiprocessor machine (mac mini in this case), I got this output: F F T 1 F T 2 F T 3 F T 4 If I'm sending a message every 2 seconds and I'm polling every 0.05 second, I would expect 39 F and 1 T between each number. At least when I ran it on the supercomputer, this is true during the very beginning; however I don't even see this when I'm running the code on my mac mini. On Sat, Jun 5, 2010 at 2:44 PM, David Zhang <solarbik...@gmail.com> wrote: > Dear all: > > I'm using mpi_iprobe to serve as a way to send signals between different > mpi executables. I'm using the following test codes (fortran): > > #1 > program send > implicit none > include 'mpif.h' > > real*8 :: vec(20000)=1.0 > integer :: ierr,i=0,request(1) > > call mpi_init(ierr) > do > call mpi_isend(vec,20000,mpi_real8, > 0,1,mpi_comm_world,request(1),ierr) > i=i+1 > print *,i > vec=-vec > call usleep_fortran(2.d0) > call mpi_wait(request(1),MPI_STATUS_IGNORE,ierr) > end do > > end program send > -------------------------------------------------- > #2 > program send > implicit none > include 'mpif.h' > > real*8 :: vec(20000) > integer :: ierr > > call mpi_init(ierr) > do > if(key_present()) then > call > mpi_recv(vec,20000,mpi_real8,1,1,mpi_comm_world,MPI_STATUS_IGNORE,ierr) > end if > call usleep_fortran(0.05d0) > > end do > > contains > > function key_present() > implicit none > logical :: key_present > > key_present = .false. > call > mpi_iprobe(1,1,mpi_comm_world,key_present,MPI_STATUS_IGNORE,ierr) > print *, key_present > > end function key_present > > end program send > ----------------------------------- > The usleep_fortran is a routine I've written to pause the program for that > amount of time (in seconds). As you can see, on the receiving end I'm > probing to see whether the message has being received every 0.05 seconds, > where each probing would result a print of the probing result; while the > sending is once every 2 seconds. > > Doing > mpirun -np 1 recv : -np 1 send > Naturally I expect the output to be something like: > > 1 > (fourty or so F) > T > 2 > (another fourty or so F) > T > 3 > > however this is the output I get: > > 1 > (fourty or so F) > T > 2 > (about a two second delay) > T > 3 > > It seems to me that after the first set of probes, once the message was > received, the non-blocking mpi probe becomes blocking for some strange > reason. I'm using mpi_iprobe for the first time, so I'm not sure if I'm > doing something blatantly wrong. > > > -- > David Zhang > University of California, San Diego > -- David Zhang University of California, San Diego ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitimate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** *****************************************************************************
