UNPACK(3PVM)

πŸ“¦ version 3.4.6, in debian bookworm, ubuntu jammy

πŸ’– UNPACK(3PVM) β€” pvm_unpack πŸ’–

okay bestie, gather round, because this is the page where your receive buffer finally gives up the goods. This is part of PVM Version 3.4, and it's literally the reverse of packing. You packed it, you sent it, now you unpack it. Slay. πŸŽ€


✨ NAME ✨

pvm_unpack β€” unpack the active message buffer into arrays of prescribed data type.

Like. It takes the bytes sitting in your active receive buffer and pours them into arrays of whatever type you asked for. That's the whole vibe. πŸ’…


🌸 SYNOPSIS 🌸

C

int info = pvm_unpackf( const char *fmt, ... )
int info = pvm_upkbyte( char *xp, int nitem, int stride)
int info = pvm_upkcplx( float *cp, int nitem, int stride)
int info = pvm_upkdcplx( double *zp, int nitem, int stride)
int info = pvm_upkdouble( double *dp, int nitem, int stride)
int info = pvm_upkfloat( float *fp, int nitem, int stride)
int info = pvm_upkint( int *ip, int nitem, int stride)
int info = pvm_upkuint( unsigned int *ip, int nitem, int stride )
int info = pvm_upkushort( unsigned short *ip, int nitem, int stride )
int info = pvm_upkulong( unsigned long *ip, int nitem, int stride )
int info = pvm_upklong( long *ip, int nitem, int stride)
int info = pvm_upkshort( short *jp, int nitem, int stride)
int info = pvm_upkstr( char *sp )

Fortran

call pvmfunpack( what, xp, nitem, stride, info )

πŸ¦‹ PARAMETERS πŸ¦‹

  • fmt β€” a printf-like format expression saying what to pack. Yeah, it says "pack", and yeah, that's the original wording, we move. (See the discussion down below πŸ‘‡)
  • nitem β€” the total number of items to be unpacked. Not the number of bytes. Items. Periodt.
  • stride β€” the stride used when packing the items. For example, if stride = 2 in pvm_upkcplx, then every other complex number gets unpacked. Every. Other. One. πŸšΆβ€β™€οΈ
  • xp β€” pointer to the beginning of a block of bytes. Can be any data type, but it must match the corresponding pack data type. no cap.
  • cp β€” complex array at least nitem*stride items long.
  • zp β€” double precision complex array at least nitem*stride items long.
  • dp β€” double precision real array at least nitem*stride items long.
  • fp β€” real array at least nitem*stride items long.
  • ip β€” integer array at least nitem*stride items long.
  • jp β€” Integer*2 array at least nitem*stride items long.
  • sp β€” pointer to a null terminated character string.
  • what β€” integer specifying the type of data being unpacked. The options are giving:
STRING         0    REAL4          4
BYTE1          1    COMPLEX8       5
INTEGER2       2    REAL8          6
INTEGER4       3    COMPLEX16      7
  • info β€” integer status code returned by the routine. Values less than zero indicate an error. 😭

πŸ‘‘ DESCRIPTION πŸ‘‘

Each of the pvm_upk* routines unpacks an array of the given data type from the active receive buffer. The arguments for each of the routines are: a pointer to the array you're unpacking into, nitem (the total number of items to unpack), and stride (the stride to use when unpacking). Simple. Iconic. πŸ’…

There is one exception, and it's pvm_upkstr(), which by definition unpacks a NULL terminated character string and therefore does not need nitem or stride arguments. She's low-maintenance, we love her. 🫢 The Fortran routine pvmfunpack( STRING, ... ) expects nitem to be the number of characters in the string and stride to be 1.

If the unpacking is successful, info will be 0. If some error occurs then info will be < 0.

Wanna unpack a single variable (not an array)? Just set nitem = 1 and stride = 1. Easy. ✨

The routine pvm_unpackf() uses a printf-like format expression to specify what and how to unpack data from the receive buffer. All variables are passed as addresses. A BNF-like description of the format syntax is:

format : null | init | format fmt
init : null | '%' '+'
fmt : '%' count stride modifiers fchar
fchar : 'c' | 'd' | 'f' | 'x' | 's'
count : null | [0-9]+ | '*'
stride : null | '.' ( [0-9]+ | '*' )
modifiers : null | modifiers mchar
mchar : 'h' | 'l' | 'u'

Formats

+  means initsend - must match an int (how) in the param list.
c  pack/unpack bytes
d  integer
f  float
x  complex float
s  string

Modifiers

h  short (int)
l  long  (int, float, complex float)
u  unsigned (int)

'*' count or stride must match an int in the param list. ⭐


🚨 future-vibes warning, bestie, listen up 🚨 Future extensions to the what argument in pvmfunpack will include 64 bit types when XDR encoding of these types is available. Meanwhile users should be aware that precision can be lost when passing data from a 64 bit machine like a Cray to a 32 bit machine like a SPARCstation. As a mnemonic the what argument name includes the number of bytes of precision to expect. By setting encoding to PVMRAW (see pvmfinitsend) data can be transferred between two 64 bit machines with full precision even if the PVM configuration is heterogeneous.

🌈 the golden rule of unpacking 🌈

Messages should be unpacked exactly like they were packed to insure data integrity. No freestyling. πŸ™…β€β™€οΈ

Packing integers and unpacking them as floats will often fail, because a type encoding will have occurred transferring the data between heterogeneous hosts. And packing 10 integers and 100 floats, then trying to unpack only 3 integers and the 100 floats? Also fails. The numbers have to line up, babe. It's giving matching energy.


πŸ”₯ EXAMPLES πŸ”₯

C

info = pvm_recv( tid, msgtag );
info = pvm_upkstr( string );
info = pvm_upkint( &size, 1, 1 );
info = pvm_upkint( array, size, 1 );
info = pvm_upkdouble( matrix, size*size, 1 );

int count, *iarry;
double darry[4];
   pvm_unpackf("%d", &count);
   pvm_unpackf("%*d %4lf", count, iarry, darry);

Fortran

CALL PVMFRECV( TID, MSGTAG, INFO );
CALL PVMFUNPACK( INTEGER4, NSIZE, 1, 1, INFO )
CALL PVMFUNPACK( STRING, STEPNAME, 8, 1, INFO )
CALL PVMFUNPACK( REAL4, A(5,1), NSIZE, NSIZE , INFO )

πŸ’€ ERRORS πŸ’€

  • PvmNoData β€” reading beyond the end of the receive buffer. Most likely cause is trying to unpack more items than were originally packed into the buffer. You're reaching for snacks that aren't in the bag. 😭
  • PvmBadMsg β€” the received message can not be decoded. Most likely because the hosts are heterogeneous and the user specified an incompatible encoding. Try setting the encoding to PvmDataDefault (see pvm_mkbuf).
  • PvmNoBuf β€” there is no active receive buffer to unpack. Nothing to unpack, bestie. There's no buffer. She's not there. πŸ™ˆ

πŸŽ€ SEE ALSO πŸŽ€

pvm_pack(3PVM) pvm_send(3PVM), pvm_recv(3PVM), pvm_pkmesg(3PVM)


and that's the whole page, angel πŸ’œ this one's from PVM Version 3.4, dated 30 August, 1993 β€” yes she's vintage, yes she still ate, we stan a legacy API. go forth and unpack responsibly πŸ¦‹βœ¨

πŸ“¦ where this page comes from