- discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7)
by Jayesh Krishna 17 Dec '12

17 Dec '12

Hi, Good to know MPICH2 is working for you. Regards, Jayesh ----- Original Message ----- From: "Seokho Son" <shsongist(a)gmail.com> To: "Jayesh Krishna" <jayesh(a)mcs.anl.gov> Sent: Monday, December 17, 2012 12:46:16 PM Subject: Re: [mpich-discuss] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7) Thank you for your prompt reply. We'v installed MPICH2 from an admin command prompt according to the instructions. The reported results in the previous email are based on the instructions. Your response for our inquiries is very informative to us. According to your advice, we'v determined to utilize 64bit-MPICH2 and ignore the error message. Currently, we can execute a 64bit parallel application on two machines with 64bit-MPICH2. Thank you very much. Best regards, Seokho Son. 2012/12/18 Jayesh Krishna < jayesh(a)mcs.anl.gov > Hi, Please make sure that you install MPICH2 on Win7 from an admin command prompt (Please follow instructions in Section 9.4, not 9.1, of the MPICH2 installers guide - http://www.mpich.org/documentation/guides/ - to install MPICH2 on Win7). Uninstall any previous versions of MPICH2 before installing a new one. Ignore the error message from wmpiconfig for 64-bit installations. This is a bug and we haven't had the developer bandwidth to fix this issue. Try running an MPI program with multiple processes to make sure MPICH2 works for you. You can install MPICH2 32-bit on a 64-bit system (However we don't test this configuration often). There shouldn't be any major performance concerns, however if you want to send huge amount of data (in your MPI program) the 64-bit version will make it easier for you. Regards, Jayesh ----- Original Message ----- From: "Seokho Son" < shsongist(a)gmail.com > To: mpich-discuss(a)mcs.anl.gov Sent: Sunday, December 16, 2012 2:00:33 PM Subject: [mpich-discuss] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7) Hello, we are trying to establish a parallel programming environment using mpich2. [Specification of our environment] OS: Windows 7 (64bit) Two workstations: Intel CPU (64bit) Programming environment: Visual studio 2008 (64bit) We have two questions regarding mpich2 installation. We have tried 64bit mpich2 (version 1.4.1p1, 1.3.2, 1.3, 1.2), but all of them give an error message ("MPICH2 not installed or unable to query the host") in the wmpiconfig program. Also, when we click scan hosts in the wmpiconfig program, the items in the list of hosts are in gray which means error occurred. However, we could successfully execute a parallel program with 64bit mpich2 (version 1.3.2) on the 64bit machine even though this version still shows the error message Q1) So, we hope to know that we may simply ignore the error message. On the other hands, we experienced that most of 32bit mpich2 versions (version 1.4.1p1, 1.3, 1.2) work in our environment without any error message. Q2) Is it fine to use 32bit mpich2 on a 64bit machine? We hope to know if there is any disadvantage on this such as performance degradation. Thank you. Best regards, Seokho Son. _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7)
by Jayesh Krishna 17 Dec '12

17 Dec '12

Hi, Please make sure that you install MPICH2 on Win7 from an admin command prompt (Please follow instructions in Section 9.4, not 9.1, of the MPICH2 installers guide - http://www.mpich.org/documentation/guides/ - to install MPICH2 on Win7). Uninstall any previous versions of MPICH2 before installing a new one. Ignore the error message from wmpiconfig for 64-bit installations. This is a bug and we haven't had the developer bandwidth to fix this issue. Try running an MPI program with multiple processes to make sure MPICH2 works for you. You can install MPICH2 32-bit on a 64-bit system (However we don't test this configuration often). There shouldn't be any major performance concerns, however if you want to send huge amount of data (in your MPI program) the 64-bit version will make it easier for you. Regards, Jayesh ----- Original Message ----- From: "Seokho Son" <shsongist(a)gmail.com> To: mpich-discuss(a)mcs.anl.gov Sent: Sunday, December 16, 2012 2:00:33 PM Subject: [mpich-discuss] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7) Hello, we are trying to establish a parallel programming environment using mpich2. [Specification of our environment] OS: Windows 7 (64bit) Two workstations: Intel CPU (64bit) Programming environment: Visual studio 2008 (64bit) We have two questions regarding mpich2 installation. We have tried 64bit mpich2 (version 1.4.1p1, 1.3.2, 1.3, 1.2), but all of them give an error message ("MPICH2 not installed or unable to query the host") in the wmpiconfig program. Also, when we click scan hosts in the wmpiconfig program, the items in the list of hosts are in gray which means error occurred. However, we could successfully execute a parallel program with 64bit mpich2 (version 1.3.2) on the 64bit machine even though this version still shows the error message Q1) So, we hope to know that we may simply ignore the error message. On the other hands, we experienced that most of 32bit mpich2 versions (version 1.4.1p1, 1.3, 1.2) work in our environment without any error message. Q2) Is it fine to use 32bit mpich2 on a 64bit machine? We hope to know if there is any disadvantage on this such as performance degradation. Thank you. Best regards, Seokho Son. _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7)
by Seokho Son 16 Dec '12

16 Dec '12

Hello, we are trying to establish a parallel programming environment using mpich2. [Specification of our environment] OS: Windows 7 (64bit) Two workstations: Intel CPU (64bit) Programming environment: Visual studio 2008 (64bit) We have two questions regarding mpich2 installation. We have tried 64bit mpich2 (version 1.4.1p1, 1.3.2, 1.3, 1.2), but all of them give an error message ("MPICH2 not installed or unable to query the host") in the wmpiconfig program. Also, when we click scan hosts in the wmpiconfig program, the items in the list of hosts are in gray which means error occurred. However, we could successfully execute a parallel program with 64bit mpich2 (version 1.3.2) on the 64bit machine even though this version still shows the error message Q1) So, we hope to know that we may simply ignore the error message. On the other hands, we experienced that most of 32bit mpich2 versions (version 1.4.1p1, 1.3, 1.2) work in our environment without any error message. Q2) Is it fine to use 32bit mpich2 on a 64bit machine? We hope to know if there is any disadvantage on this such as performance degradation. Thank you. Best regards, Seokho Son.

1 0

Re: [mpich-discuss] There is any change between mpich1 and mpich2 which make this error?
by Jim Dinan 14 Dec '12

14 Dec '12

Hi, It looks like one of your processes seg. faulted and exited with SIGSEGV (signal 11). You should be able to look at the core file or attach a debugger to get a backtrace and locate the origin of the error. Without more information, it's hard to give much help. MPICH2 1.4.1 is also a slightly older version, you could try upgrading to the latest version of MPICH and see if the seg fault goes away. I don't know of any change from MPICH1 to MPICH2 that would have resulted in a correct MPI-1 program seg faulting. ~Jim. On 12/14/12 6:51 AM, 유경완 wrote: > Hi there > > I upgraded my server computer and I also upgraded mpich program from > mpich1(1.2.7p1) to mpich2(1.4.1). > > And then there were some problems… > > The problem was > > There is no error when I run mpich2(mpiexec) with output file which > compiled at mpich1. > > But there is an error when I run mpich2(mpiexec) with output file which > compiled at mpich2 (there was no error when I compiled at mpich2). > > (All compiling which mentioned above use same code) > > The error message was > > ===================================================================================== > > = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES > > = EXIT CODE: 11 > > = CLEANING UP REMAINING PROCESSES > > = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES > > ===================================================================================== > > [proxy:0:1@n002] HYD_pmcd_pmip_control_cmd_cb > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/pm/pmiserv/pmip_cb.c:928): > assert (!closed) failed > > [proxy:0:1@n002] HYDT_dmxu_poll_wait_for_event > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/tools/demux/demux_poll.c:77): > callback returned error status > > [proxy:0:1@n002] main > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/pm/pmiserv/pmip.c:276): > demux engine error waiting for event > > [mpiexec(a)octofous2.psl] HYDT_bscu_wait_for_completion > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/tools/bootstrap/utils/bscu_wait.c:70): > one of the processes terminated badly; aborting > > [mpiexec(a)octofous2.psl] HYDT_bsci_wait_for_completion > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/tools/bootstrap/src/bsci_wait.c:23): > launcher returned error waiting for completion > > [mpiexec(a)octofous2.psl] HYD_pmci_wait_for_completion > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:191): > launcher returned error waiting for completion > > [mpiexec(a)octofous2.psl] main > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/ui/mpich/mpiexec.c:405): > process manager error waiting for completion > > 8 cpus > > So.. my quastion was that is there any language change between > mpich1(1.2.7p1) and mpich2(1.4.1) which makes problem like this? > > Or there is any clue to make this problem..? > > Thanks for read > > Best regards > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

There is any change between mpich1 and mpich2 which make this error?
by 유경완 14 Dec '12

14 Dec '12

Hi there I upgraded my server computer and I also upgraded mpich program from mpich1(1.2.7p1) to mpich2(1.4.1). And then there were some problems… The problem was There is no error when I run mpich2(mpiexec) with output file which compiled at mpich1. But there is an error when I run mpich2(mpiexec) with output file which compiled at mpich2 (there was no error when I compiled at mpich2). (All compiling which mentioned above use same code) The error message was ============================================================================ ========= = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = EXIT CODE: 11 = CLEANING UP REMAINING PROCESSES = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES ============================================================================ ========= [proxy:0:1@n002] HYD_pmcd_pmip_control_cmd_cb (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/pm/pmiserv/pmip_cb.c:928): assert (!closed) failed [proxy:0:1@n002] HYDT_dmxu_poll_wait_for_event (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/tools/demux/demux_poll.c:77): callback returned error status [proxy:0:1@n002] main (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/pm/pmiserv/pmip.c:276): demux engine error waiting for event [mpiexec(a)octofous2.psl] HYDT_bscu_wait_for_completion (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/tools/bootstrap/utils/bscu_wait.c:70): one of the processes terminated badly; aborting [mpiexec(a)octofous2.psl] HYDT_bsci_wait_for_completion (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/tools/bootstrap/src/bsci_wait.c:23): launcher returned error waiting for completion [mpiexec(a)octofous2.psl] HYD_pmci_wait_for_completion (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:191): launcher returned error waiting for completion [mpiexec(a)octofous2.psl] main (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/ui/mpich/mpiexec.c:405): process manager error waiting for completion 8 cpus So.. my quastion was that is there any language change between mpich1(1.2.7p1) and mpich2(1.4.1) which makes problem like this? Or there is any clue to make this problem..? Thanks for read Best regards

1 0

Re: [mpich-discuss] too many communicators
by Jim Dinan 13 Dec '12

13 Dec '12

How many communicators are created by the loops containing these statements? Could it be more than the limit? > psymbfact.c: MPI_Comm_dup ((*symb_comm), &(commLvls[i])); > psymbfact.c: MPI_Comm_split ((*symb_comm), col, key, &(commLvls[ind]) ); ~Jim. On 12/13/12 12:19 PM, Jeff Hammond wrote: > It's far from conclusive, but I went through the SuperLU_dist source > and it seems there is proper symmetry between communicator creation > and destruction. > > $ for f in create dup split free ; do grep MPI_Comm_$f *.c ; done > superlu_grid.c: MPI_Comm_create( Bcomm, superlu_grp, &grid->comm ); > psymbfact.c: MPI_Comm_dup ((*symb_comm), &(commLvls[i])); > pdgssvx.c: MPI_Comm_split (grid->comm, col, key, &symb_comm ); > psymbfact.c: MPI_Comm_split ((*symb_comm), col, key, &(commLvls[ind]) ); > pzgssvx.c: MPI_Comm_split (grid->comm, col, key, &symb_comm ); > superlu_grid.c: MPI_Comm_split(grid->comm, myrow, mycol, &(grid->rscp.comm)); > superlu_grid.c: MPI_Comm_split(grid->comm, mycol, myrow, &(grid->cscp.comm)); > pdgssvx.c: MPI_Comm_free (&symb_comm); > psymbfact.c: MPI_Comm_free (&(commLvls[i])); > psymbfact.c: MPI_Comm_free ( &(commLvls[ind]) ); > pzgssvx.c: MPI_Comm_free (&symb_comm); > superlu_grid.c: MPI_Comm_free( &grid->rscp.comm ); > superlu_grid.c: MPI_Comm_free( &grid->cscp.comm ); > superlu_grid.c: MPI_Comm_free( &grid->comm ); > > Jeff > > On Thu, Dec 13, 2012 at 9:40 AM, Jim Dinan <dinan(a)mcs.anl.gov> wrote: >> Hi Jack, >> >> It sounds like your application, or maybe the solver, is leaking >> communicators somewhere. If you configure with --enable-g=handlealloc (or >> --enable-g=all), MPICH will issue warnings about leaked MPI objects when >> your program exits. >> >> ~Jim. >> >> >> On 12/12/12 6:47 PM, Dave Goodell wrote: >>> >>> On Dec 13, 2012, at 5:23 AM GMT+09:00, Jack Lee wrote: >>> >>>> What I'd like to determine first is whether fault is on my side (e.g. >>>> perhaps I'm not calling the clean-up routines properly). Is there a way to >>>> find out how many context id's are in use at a given point? >>> >>> >>> If your MPICH was configured with "--enable-g=log" (or a superset thereof, >>> such as "=all"), then you can add the following prototype into your >>> application and invoke this function to get a string showing the current >>> bit-vector state on a given process: >>> >>> ----8<---- >>> static char *MPIR_ContextMaskToStr(void); >>> ----8<---- >>> >>> see src/mpi/comm/commutil.c for more insight into how this works and what >>> it's actually telling you. This wiki node also has some useful (and only >>> slightly stale) information: >>> >>> http://wiki.mpich.org/mpich/index.php/Communicators_and_Context_IDs >>> >>> I wish I had a better option for you, but without just rolling up your >>> sleeves and hacking on the MPICH code, this is about as good as you're >>> likely to get. >>> >>> The next best approach would probably be to trap all the communicator >>> creation/destruction calls that you can think of (see the MPI-2.2 standard, >>> chapter 6) via the PMPI_ profiling interface and log the invocations to look >>> for a mismatch. >>> >>> -Dave >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > >

1 0

Re: [mpich-discuss] too many communicators
by Jeff Hammond 13 Dec '12

13 Dec '12

It's far from conclusive, but I went through the SuperLU_dist source and it seems there is proper symmetry between communicator creation and destruction. $ for f in create dup split free ; do grep MPI_Comm_$f *.c ; done superlu_grid.c: MPI_Comm_create( Bcomm, superlu_grp, &grid->comm ); psymbfact.c: MPI_Comm_dup ((*symb_comm), &(commLvls[i])); pdgssvx.c: MPI_Comm_split (grid->comm, col, key, &symb_comm ); psymbfact.c: MPI_Comm_split ((*symb_comm), col, key, &(commLvls[ind]) ); pzgssvx.c: MPI_Comm_split (grid->comm, col, key, &symb_comm ); superlu_grid.c: MPI_Comm_split(grid->comm, myrow, mycol, &(grid->rscp.comm)); superlu_grid.c: MPI_Comm_split(grid->comm, mycol, myrow, &(grid->cscp.comm)); pdgssvx.c: MPI_Comm_free (&symb_comm); psymbfact.c: MPI_Comm_free (&(commLvls[i])); psymbfact.c: MPI_Comm_free ( &(commLvls[ind]) ); pzgssvx.c: MPI_Comm_free (&symb_comm); superlu_grid.c: MPI_Comm_free( &grid->rscp.comm ); superlu_grid.c: MPI_Comm_free( &grid->cscp.comm ); superlu_grid.c: MPI_Comm_free( &grid->comm ); Jeff On Thu, Dec 13, 2012 at 9:40 AM, Jim Dinan <dinan(a)mcs.anl.gov> wrote: > Hi Jack, > > It sounds like your application, or maybe the solver, is leaking > communicators somewhere. If you configure with --enable-g=handlealloc (or > --enable-g=all), MPICH will issue warnings about leaked MPI objects when > your program exits. > > ~Jim. > > > On 12/12/12 6:47 PM, Dave Goodell wrote: >> >> On Dec 13, 2012, at 5:23 AM GMT+09:00, Jack Lee wrote: >> >>> What I'd like to determine first is whether fault is on my side (e.g. >>> perhaps I'm not calling the clean-up routines properly). Is there a way to >>> find out how many context id's are in use at a given point? >> >> >> If your MPICH was configured with "--enable-g=log" (or a superset thereof, >> such as "=all"), then you can add the following prototype into your >> application and invoke this function to get a string showing the current >> bit-vector state on a given process: >> >> ----8<---- >> static char *MPIR_ContextMaskToStr(void); >> ----8<---- >> >> see src/mpi/comm/commutil.c for more insight into how this works and what >> it's actually telling you. This wiki node also has some useful (and only >> slightly stale) information: >> >> http://wiki.mpich.org/mpich/index.php/Communicators_and_Context_IDs >> >> I wish I had a better option for you, but without just rolling up your >> sleeves and hacking on the MPICH code, this is about as good as you're >> likely to get. >> >> The next best approach would probably be to trap all the communicator >> creation/destruction calls that you can think of (see the MPI-2.2 standard, >> chapter 6) via the PMPI_ profiling interface and log the invocations to look >> for a mismatch. >> >> -Dave >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-discuss] too many communicators
by Jim Dinan 13 Dec '12

13 Dec '12

Hi Jack, It sounds like your application, or maybe the solver, is leaking communicators somewhere. If you configure with --enable-g=handlealloc (or --enable-g=all), MPICH will issue warnings about leaked MPI objects when your program exits. ~Jim. On 12/12/12 6:47 PM, Dave Goodell wrote: > On Dec 13, 2012, at 5:23 AM GMT+09:00, Jack Lee wrote: > >> What I'd like to determine first is whether fault is on my side (e.g. perhaps I'm not calling the clean-up routines properly). Is there a way to find out how many context id's are in use at a given point? > > If your MPICH was configured with "--enable-g=log" (or a superset thereof, such as "=all"), then you can add the following prototype into your application and invoke this function to get a string showing the current bit-vector state on a given process: > > ----8<---- > static char *MPIR_ContextMaskToStr(void); > ----8<---- > > see src/mpi/comm/commutil.c for more insight into how this works and what it's actually telling you. This wiki node also has some useful (and only slightly stale) information: > > http://wiki.mpich.org/mpich/index.php/Communicators_and_Context_IDs > > I wish I had a better option for you, but without just rolling up your sleeves and hacking on the MPICH code, this is about as good as you're likely to get. > > The next best approach would probably be to trap all the communicator creation/destruction calls that you can think of (see the MPI-2.2 standard, chapter 6) via the PMPI_ profiling interface and log the invocations to look for a mismatch. > > -Dave > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] too many communicators
by Dave Goodell 12 Dec '12

12 Dec '12

On Dec 13, 2012, at 5:23 AM GMT+09:00, Jack Lee wrote: > What I'd like to determine first is whether fault is on my side (e.g. perhaps I'm not calling the clean-up routines properly). Is there a way to find out how many context id's are in use at a given point? If your MPICH was configured with "--enable-g=log" (or a superset thereof, such as "=all"), then you can add the following prototype into your application and invoke this function to get a string showing the current bit-vector state on a given process: ----8<---- static char *MPIR_ContextMaskToStr(void); ----8<---- see src/mpi/comm/commutil.c for more insight into how this works and what it's actually telling you. This wiki node also has some useful (and only slightly stale) information: http://wiki.mpich.org/mpich/index.php/Communicators_and_Context_IDs I wish I had a better option for you, but without just rolling up your sleeves and hacking on the MPICH code, this is about as good as you're likely to get. The next best approach would probably be to trap all the communicator creation/destruction calls that you can think of (see the MPI-2.2 standard, chapter 6) via the PMPI_ profiling interface and log the invocations to look for a mismatch. -Dave

1 0

Re: [mpich-discuss] Problems with MPI and virtual functions in C++
by Hélvio Vairinhos 12 Dec '12

12 Dec '12

Thank you again, Dries! You were extremely helpful. I will take a look at the MPI standard. Cheers, Helvio On 12/12/2012 08:22 PM, Dries Kimpe wrote: > * Hï¿½lvio Vairinhos <helvio.vairinhos(a)gmail.com> [2012-12-12 20:00:28]: > >> Thanks for your suggestion, Dries! It works if I use &p.elem[0] as the >> initial address (not &p->elem), and only if I make elem public.I guess >> that's a price to pay (well, I can always fetch the address with a getter). >> Do you know what happens to the memory layout in the presence of virtual >> functions if I have multiple components? For example: >> double a,b; >> instead of: >> double elem[2]; > When you have virtual functions (in fact, according to the <C++98 > standard, as soon as you have non-trivial constructor/destructor), you can > no longer reason about the memory layout of the struct/class. > > They are no longer PODs (plain old datatype). > >> Is it safe to assume that &p.a would give the initial address of a >> contiguous structure? Or should I play safe and use MPI_Pack and MPI_Unpack, >> for example? > Even for a 'contiguous' structure (such as POD struct) the compiler is > allowed to insert padding for alignment reasons. > The difference with non-POD is that you are allowed to copy those bytes as > well to another instance and expect everything to work. > > (i.e. memcpy (&a, &b, sizeof(a)) is allowed for POD). > > Really, this is a larger topic. If I'm not mistaken, there is some > discussion of this in the MPI standard, even though at this point, your > question is more a C/C++ question than an MPI question. > > To give you at least some practical advice: POD types will generally work > as expected. But I would strongly recommend against making similar > assumptions for non-POD types (i.e. types having public/protect/private > modifiers, non-trivial constructors/destructors, and especially virtual > functions). > > Dries > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0