Newsgroups: comp.parallel.pvm
Path: ukc!uknet!pipex!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!col.hp.com!csn!hellgate.utah.edu!math.utah.edu!news.math.utah.edu!tim
From: tim@osiris.usi.utah.edu (Timothy Burns)
Subject: extra buffer for send/recv
Sender: news@math.utah.edu
Date: Sun, 30 Jan 1994 01:26:26 GMT
Organization: Utah Supercomputing Institute, University of Utah
Message-ID: <TIM.94Jan29182626@osiris.usi.utah.edu>
Lines: 37

Hi,

I am  once again on the net with a question.  I have spent a lot of
time today discovering that for repeated calls to PVM3, something
funny happens.  In a nutshell, I am cycling through a size n_loc[me]
vector, where n_loc[me] is either 5 for 4.  If use n_loc[me] as the
number of elements, as in the following call, I get every element for
n_loc[me] = 4, but only 4 elements for n_loc[me] = 5.

  info = pvm_initsend( PvmDataRaw );
  info = pvm_pkdouble( v.elements, (n_loc[me]), 1 );
  indx = (me+1)%nprocs;
  info = pvm_send( tids[indx], 100 );

  /* Receive from previous */
  indx = ( me == 0 ) ? (nprocs - 1) : (me % nprocs - 1);
  info = pvm_recv( tids[indx], 100 );
  info = pvm_upkdouble( v.elements, (n_loc[indx]), 1 );


I can fix this problem simply by adding an extra "buffer" element to
the PVM message, but everything I have ever seen in PVM up to this
point implies that if I specify to send n elements, I should send n
elements.  I have programmed quite a lot in PVM and PVM3, and have
never seen this behavior before.  Any explanations?

Thanks,
--
--
Tim Burns				email: tim@osiris.usi.utah.edu
USI, 85 SSB, Univ. of Utah, UT  84112  	phone: (801)581-5172
+--------------------------------------------------------------------------+
| Even the most brilliant scientific discoveries will in time change and   |
| perhaps grow obsolete, as new scientific manifestations emerge.  But Art |
| is eternal; for it reveals the inner landscape which is the soul of man. |
+----------------------------------            --Martha Graham    ---------+


