March 2014 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Comm_spawn with win_create
by Wesley Bland 17 Mar '14

17 Mar '14

When you say that it fails, what do you mean? Are you getting an MPI error? An error from your program? Compile error? > On Mar 17, 2014, at 5:44 PM, Ramesh Vinayagam <rvinayagam.85(a)gmail.com> wrote: > > Hi, > > Can comm_spawn be used with win_create. > For ex: > Master process: > MPI_Comm_spawn(worker_program,MPI_ARGV_NULL, world_size-1, > info, 0, MPI_COMM_SELF, &everyone, > MPI_ERRCODES_IGNORE); > > MPI_Win_create(&testval, sizeof(double), 1, > MPI_INFO_NULL, everyone, > &nwin); > > Worker process: > MPI_Comm_get_parent(&parent); > if (parent == MPI_COMM_NULL) error("No parent!"); > MPI_Comm_remote_size(parent, &size); > if (size != 1) error("Something's wrong with the parent"); > > fprintf (stdout,"Size: %zd\n", size); > system("echo $NUM_THREADS"); > > MPI_Win_create(MPI_BOTTOM, 0, > 1, MPI_INFO_NULL, > parent, &nwin); > > > > This one fails currently. Am I doing something wrong. It would be great if someone could help me. > > Thanks > Ramesh > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Comm_spawn with win_create
by Ramesh Vinayagam 17 Mar '14

17 Mar '14

Hi, Can comm_spawn be used with win_create. For ex: Master process: MPI_Comm_spawn(worker_program,MPI_ARGV_NULL, world_size-1, info, 0, MPI_COMM_SELF, &everyone, MPI_ERRCODES_IGNORE); MPI_Win_create(&testval, sizeof(double), 1, MPI_INFO_NULL, everyone, &nwin); Worker process: MPI_Comm_get_parent(&parent); if (parent == MPI_COMM_NULL) error("No parent!"); MPI_Comm_remote_size(parent, &size); if (size != 1) error("Something's wrong with the parent"); fprintf (stdout,"Size: %zd\n", size); system("echo $NUM_THREADS"); MPI_Win_create(MPI_BOTTOM, 0, 1, MPI_INFO_NULL, parent, &nwin); This one fails currently. Am I doing something wrong. It would be great if someone could help me. Thanks Ramesh

1 0

Re: [mpich-discuss] MPIDI_CH3U_Buffer_copy(64): Message truncated; 16 bytes received but buffer size is 16
by Balaji, Pavan 15 Mar '14

15 Mar '14

Jeff, Did you mean to send this email to the MVAPICH mailing list instead of the MPICH mailing list? http://mvapich.cse.ohio-state.edu/ — Pavan On Mar 15, 2014, at 11:14 AM, Daily, Jeff A <jeff.daily(a)pnnl.gov> wrote: > I’m running mvapich2 1.9 compiled with thread multiple enabled. I was hoping someone might be able to explain the following error message I’m receiving. Based on the error message alone, seems like it should’ve been ok? Thanks. > > In: PMI_Abort(1, Fatal error in PMPI_Test: > Message truncated, error stack: > MPIDI_CH3U_Buffer_copy(64): Message truncated; 16 bytes received but buffer size is 16 > ) > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPIDI_CH3U_Buffer_copy(64): Message truncated; 16 bytes received but buffer size is 16
by Daily, Jeff A 15 Mar '14

15 Mar '14

I’m running mvapich2 1.9 compiled with thread multiple enabled. I was hoping someone might be able to explain the following error message I’m receiving. Based on the error message alone, seems like it should’ve been ok? Thanks. In: PMI_Abort(1, Fatal error in PMPI_Test: Message truncated, error stack: MPIDI_CH3U_Buffer_copy(64): Message truncated; 16 bytes received but buffer size is 16 )

1 0

Re: [mpich-discuss] ROMIO filesystem check during MPI_File_open
by Rob Latham 14 Mar '14

14 Mar '14

On 03/13/2014 04:28 PM, Jeff Squyres (jsquyres) wrote: > We had a user run into a situation with ROMIO that caused a bunch of head-scratching before we figured it out. > > The user was running a trivial C MPI program that failed with a truncation error in MPI_Bcast. After much poking around, we finally figured out that it was actually failing deep within MPI_File_open. The reason it was getting a truncation error is because of the user's setup: > > - the cluster head node is *also* a compute node > - the cluster head node is the NFS server > - in MPI_COMM_WORLD rank 0 (on the head node), ROMIO saw a UFS filesystem > - all other MCW process ranks saw an NFS filesystem > - hence, during ROMIO's MPI_File_open, MCW rank 0 chose to do a UFS file open and everyone else chose to do an NFS file open > > Things go downhill from there, eventually resulting in a MPI_Bcast mismatch. > > Is there any thought to supporting this kind of scenario? All MPI processes are accessing the same filesystem; it's just that some of the MPI processes happen to see that filesystem as local, and some see it as NFS. > I thought we handled this? we certianly seem to have made an effort: https://trac.mpich.org/projects/mpich/browser/src/mpi/romio/adio/common/ad_… If someone configured ROMIO without NFS (good for them!), then we will do a "scalable stat" from one process, instead of from all zillion processes (be nice to your file system...) If nfs is enabled, then we have no choice. everyone must stat the file system. So everyone goes and stats the file system to see what kind of driver to use. Did everyone agree? Check out line 709: 708 /* ensure everyone came up with the same file system type */ 709 MPI_Allreduce(&file_system, &min_code, 1, MPI_INT, 710 MPI_MIN, comm); 711 if (min_code == ADIO_NFS) file_system = ADIO_NFS; And yes, ADIO_NFS is ROMIO's first parallel file system -- despite it being evil and we hates it. Now, you know as well as I the old adage about tested code and broken code. I can't imagine the last time this code was exercised... ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-discuss] MPI_Send MPI_recv
by Lu, Huiwei 14 Mar '14

14 Mar '14

Hi, Chen, Read the source code. It’s not about redundancy. You have to invest your time on it to understand all the details. To help you start with, you can read section 4 “Architecture of MPICH” of paper “A High-Performance, Portable Implementation of the MPI Message Passing Interface Standard”. It helps you understand the overall architecture of MPICH better. p.s. It’s an English list. You may want to asking questions in English only. Best, — Huiwei Lu Postdoc Appointee Mathematics and Computer Science Division, Argonne National Laboratory http://www.mcs.anl.gov/~huiweilu/ On Mar 14, 2014, at 8:21 AM, 陈涛 <volkanchen(a)gmail.com> wrote: > 请问各位大神，谁有自己实现过这两个函数啊？标准通信的就行！MPICH的源码冗余的太多，我是做硬件的，C/C++学的不好也，我只需要这两个函数发送和接收部分的代码，其他的检错什么的不需要！请问谁能提供一部分代码或资料？谢谢！ > > Hi! Who has done the work of implementing some part of MPI standard by himself or herself? I need the source code on the mechanism of sending and receiving data of MPI_Send and MPI_Recv. Just the standard mode of blocking communication is OK, and the error checking part is not necessary and I do not need it. I cannot understand the code of MPICH very well as there is much redundancy and I work on hardware and do not know much about C/C++. Could you please provide me with some code or materials? Many thanks! > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPI_Send MPI_recv
by 陈涛 14 Mar '14

14 Mar '14

请问各位大神，谁有自己实现过这两个函数啊？标准通信的就行！MPICH的源码冗余的太多，我是做硬件的，C/C++学的不好也，我只需要这两个函数发送和接收部分的代码，其他的检错什么的不需要！请问谁能提供一部分代码或资料？谢谢！ Hi! Who has done the work of implementing some part of MPI standard by himself or herself? I need the source code on the mechanism of sending and receiving data of MPI_Send and MPI_Recv. Just the standard mode of blocking communication is OK, and the error checking part is not necessary and I do not need it. I cannot understand the code of MPICH very well as there is much redundancy and I work on hardware and do not know much about C/C++. Could you please provide me with some code or materials? Many thanks!

1 0

Re: [mpich-discuss] ROMIO filesystem check during MPI_File_open
by Jeff Squyres (jsquyres) 13 Mar '14

13 Mar '14

Good to know. Is it easy to get error detection during MPI_File_open to know that there is a mismatch? On Mar 13, 2014, at 5:33 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > In such cases, if the user prepends the file name with "nfs:" it should work. > > Rajeev > > On Mar 13, 2014, at 4:28 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> We had a user run into a situation with ROMIO that caused a bunch of head-scratching before we figured it out. >> >> The user was running a trivial C MPI program that failed with a truncation error in MPI_Bcast. After much poking around, we finally figured out that it was actually failing deep within MPI_File_open. The reason it was getting a truncation error is because of the user's setup: >> >> - the cluster head node is *also* a compute node >> - the cluster head node is the NFS server >> - in MPI_COMM_WORLD rank 0 (on the head node), ROMIO saw a UFS filesystem >> - all other MCW process ranks saw an NFS filesystem >> - hence, during ROMIO's MPI_File_open, MCW rank 0 chose to do a UFS file open and everyone else chose to do an NFS file open >> >> Things go downhill from there, eventually resulting in a MPI_Bcast mismatch. >> >> Is there any thought to supporting this kind of scenario? All MPI processes are accessing the same filesystem; it's just that some of the MPI processes happen to see that filesystem as local, and some see it as NFS. >> >> Regardless, if this can't/won't be supported, can there be some kind of Allreduce before calling ADIOI_Open that determines, "Hey, we're not viewing this as the same filesystem -- we should throw an error (and possibly print a helpful error message)." Such cluster configurations are not entirely uncommon; being able to error out with a user-helpful reason would be most helpful. >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> 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 Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpich-discuss] ROMIO filesystem check during MPI_File_open
by Rajeev Thakur 13 Mar '14

13 Mar '14

In such cases, if the user prepends the file name with "nfs:" it should work. Rajeev On Mar 13, 2014, at 4:28 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > We had a user run into a situation with ROMIO that caused a bunch of head-scratching before we figured it out. > > The user was running a trivial C MPI program that failed with a truncation error in MPI_Bcast. After much poking around, we finally figured out that it was actually failing deep within MPI_File_open. The reason it was getting a truncation error is because of the user's setup: > > - the cluster head node is *also* a compute node > - the cluster head node is the NFS server > - in MPI_COMM_WORLD rank 0 (on the head node), ROMIO saw a UFS filesystem > - all other MCW process ranks saw an NFS filesystem > - hence, during ROMIO's MPI_File_open, MCW rank 0 chose to do a UFS file open and everyone else chose to do an NFS file open > > Things go downhill from there, eventually resulting in a MPI_Bcast mismatch. > > Is there any thought to supporting this kind of scenario? All MPI processes are accessing the same filesystem; it's just that some of the MPI processes happen to see that filesystem as local, and some see it as NFS. > > Regardless, if this can't/won't be supported, can there be some kind of Allreduce before calling ADIOI_Open that determines, "Hey, we're not viewing this as the same filesystem -- we should throw an error (and possibly print a helpful error message)." Such cluster configurations are not entirely uncommon; being able to error out with a user-helpful reason would be most helpful. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

ROMIO filesystem check during MPI_File_open
by Jeff Squyres (jsquyres) 13 Mar '14

13 Mar '14

We had a user run into a situation with ROMIO that caused a bunch of head-scratching before we figured it out. The user was running a trivial C MPI program that failed with a truncation error in MPI_Bcast. After much poking around, we finally figured out that it was actually failing deep within MPI_File_open. The reason it was getting a truncation error is because of the user's setup: - the cluster head node is *also* a compute node - the cluster head node is the NFS server - in MPI_COMM_WORLD rank 0 (on the head node), ROMIO saw a UFS filesystem - all other MCW process ranks saw an NFS filesystem - hence, during ROMIO's MPI_File_open, MCW rank 0 chose to do a UFS file open and everyone else chose to do an NFS file open Things go downhill from there, eventually resulting in a MPI_Bcast mismatch. Is there any thought to supporting this kind of scenario? All MPI processes are accessing the same filesystem; it's just that some of the MPI processes happen to see that filesystem as local, and some see it as NFS. Regardless, if this can't/won't be supported, can there be some kind of Allreduce before calling ADIOI_Open that determines, "Hey, we're not viewing this as the same filesystem -- we should throw an error (and possibly print a helpful error message)." Such cluster configurations are not entirely uncommon; being able to error out with a user-helpful reason would be most helpful. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0