November 2018 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] _get_addr error while running application using MPICH
by Zhifeng Yang 19 Nov '18

19 Nov '18

Hi all, Thank you for helping me on this error. Actually, real.exe is a portion of a very large weather model. It is very difficult to extract it or duplicate the error in a simple fortran code, since I am not sure where the problem is. From your discussion, I barely can understand them, in fact. Even I do not know what is "_get_addr". Is it related to MPI? Best, Zhifeng On Mon, Nov 19, 2018 at 10:06 AM Zhou, Hui via discuss <discuss(a)mpich.org> wrote: > I suspect the error was something else. `real.exe: error: _get_addr: No > such file or directory` does look like a MPICH error. In fact, I suspect > mpirun probably is from other package by not hydra, then there is probably > some mis-matched assumptions. > > — > Hui Zhou > T: 630-252-3430 > > > > > > > > > On Nov 17, 2018, at 12:31 PM, William Gropp <wgropp(a)illinois.edu> wrote: > > I’m also at a loss to understand why "mpirun ./real.exe” would fail - if a > -np xx argument is required, then mpirun should issue the error; if not, > then a rational choice of default would be 1 process, and should behave as > “mpirun -np 1 ./real.exe”. > > Of course, it should be mpiexec instead of mpirun, but that shouldn’t > matter. > > Bill > > William Gropp > Director and Chief Scientist, NCSA > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > > On Nov 15, 2018, at 1:01 PM, Gropp, William D via discuss < > discuss(a)mpich.org> wrote: > > Yes, singleton is the ./real.exe below. At least that version should have > worked. > Bill > > On Nov 14, 2018 2:00 PM, "Zhou, Hui" <zhouh(a)anl.gov> wrote: > Hi Bill, > > To clarify, a singleton refers to a process started directly — such as > ./real.exe, right? For the case of `mpirun ./real.exe`, or even `mpirun -np > 1 ./real.exe`, is not technically a singleton, correct? > > — > Hui Zhou > > > On Nov 13, 2018, at 9:30 PM, William Gropp via discuss <discuss(a)mpich.org> > wrote: > > This is not quite true. From the MPI standard: > > 10.5.2 Singleton MPI_INIT > > A high-quality implementation will allow any process (including those not > started with a “parallel application” mechanism) to become an MPI process > by calling MPI_INIT. > > > There was a time when MPICH could do this, and there were features in the > original PMI to support this. > > Bill > > William Gropp > Director and Chief Scientist, NCSA > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > > On Nov 13, 2018, at 10:27 AM, Si, Min via discuss <discuss(a)mpich.org> > wrote: > > Hi Zhifeng, > > You have to always execute the MPI program by using mpirun or mpiexec with > -np <number of processes>. > > At MPI_Init, the process tries to read information (e.g., MPI rank, number > of processes) from the PMI server which is another process launched by the > mpiexec command. This information is necessary for MPI library to > initialize communication (e.g., connecting two processes). > > Best regards, > Min > > On 2018/11/04 10:27, Zhifeng Yang via discuss wrote: > > Hi > > After I installed mpich and used it in a FORTRAN code. There is an error > while running this FORTRAN code called real.exe by using the following > command > > $./real.exe > or > $mpirun ./real.exe > real.exe: error: _get_addr: No such file or directory > real.exe: error: _get_addr: No such file or directory > real.exe: error: _get_addr: No such file or directory > Fatal error in MPI_Init: Other MPI error, error stack: > MPIR_Init_thread(784).....: > MPID_Init(1323)...........: channel initialization failed > MPIDI_CH3_Init(120).......: > MPID_nem_init_ckpt(852)...: > MPIDI_CH3I_Seg_commit(364): PMI_Barrier returned -1 > > But while using mpirun with specifying number of processors. as follows > $mpirun -np 1 ./real.exe > There is no error any more. I am not sure why? do you have any > explanation? Thank you very much > > Best regards > Zhifeng > > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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] _get_addr error while running application using MPICH
by Zhou, Hui 19 Nov '18

19 Nov '18

I suspect the error was something else. `real.exe: error: _get_addr: No such file or directory` does look like a MPICH error. In fact, I suspect mpirun probably is from other package by not hydra, then there is probably some mis-matched assumptions. — Hui Zhou T: 630-252-3430 On Nov 17, 2018, at 12:31 PM, William Gropp <wgropp(a)illinois.edu<mailto:[email protected]>> wrote: I’m also at a loss to understand why "mpirun ./real.exe” would fail - if a -np xx argument is required, then mpirun should issue the error; if not, then a rational choice of default would be 1 process, and should behave as “mpirun -np 1 ./real.exe”. Of course, it should be mpiexec instead of mpirun, but that shouldn’t matter. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Nov 15, 2018, at 1:01 PM, Gropp, William D via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Yes, singleton is the ./real.exe below. At least that version should have worked. Bill On Nov 14, 2018 2:00 PM, "Zhou, Hui" <zhouh(a)anl.gov<mailto:[email protected]>> wrote: Hi Bill, To clarify, a singleton refers to a process started directly — such as ./real.exe, right? For the case of `mpirun ./real.exe`, or even `mpirun -np 1 ./real.exe`, is not technically a singleton, correct? — Hui Zhou On Nov 13, 2018, at 9:30 PM, William Gropp via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: This is not quite true. From the MPI standard: 10.5.2 Singleton MPI_INIT A high-quality implementation will allow any process (including those not started with a “parallel application” mechanism) to become an MPI process by calling MPI_INIT. There was a time when MPICH could do this, and there were features in the original PMI to support this. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Nov 13, 2018, at 10:27 AM, Si, Min via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Hi Zhifeng, You have to always execute the MPI program by using mpirun or mpiexec with -np <number of processes>. At MPI_Init, the process tries to read information (e.g., MPI rank, number of processes) from the PMI server which is another process launched by the mpiexec command. This information is necessary for MPI library to initialize communication (e.g., connecting two processes). Best regards, Min On 2018/11/04 10:27, Zhifeng Yang via discuss wrote: Hi After I installed mpich and used it in a FORTRAN code. There is an error while running this FORTRAN code called real.exe by using the following command $./real.exe or $mpirun ./real.exe real.exe: error: _get_addr: No such file or directory real.exe: error: _get_addr: No such file or directory real.exe: error: _get_addr: No such file or directory Fatal error in MPI_Init: Other MPI error, error stack: MPIR_Init_thread(784).....: MPID_Init(1323)...........: channel initialization failed MPIDI_CH3_Init(120).......: MPID_nem_init_ckpt(852)...: MPIDI_CH3I_Seg_commit(364): PMI_Barrier returned -1 But while using mpirun with specifying number of processors. as follows $mpirun -np 1 ./real.exe There is no error any more. I am not sure why? do you have any explanation? Thank you very much Best regards Zhifeng _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] how to dynamically schedule process in mpich
by Shuwei Zhao 18 Nov '18

18 Nov '18

Hi, Hui, Thanks a lot for your comments. 1. The definition of "dynamic scheduling of cpu cores" in my opinion is that when I already submit a mpi application in the farm, during the runtime, I want to add/reduce cpus of the running application. For example, I use qsub to submit a 4-process application to the farm on 4 different machines, during the runtime, I want to use 4 more process to run the application to make it run faster. The application can spawn 4 more process as I required, the old processes and the new processes can be in the same comm group or in parent-son comm group. Vice versa, if I want to reduce the the number process of 4 to 2, during runtime, the application will terminate 2 processes of 4 and keeps the other 2 of them running. 2. About the MPI_Info object, I tried to use mpi_comm_spawn on the same machine, it can work. But I don't know how to spawn processes cross machines. For example, if I have 4 processes on machine 1, and I want to spawn 4 more processes on other machines (resource managed by qsub), how do I need to declare in the MPI_Info object? Thank you very much, SHuwei On Wed, Nov 14, 2018 at 1:42 PM Zhou, Hui <zhouh(a)anl.gov> wrote: > Hi Shuwei, > > See my comments/questions between the quotes below: > > > On Nov 13, 2018, at 12:33 AM, Shuwei Zhao <shuweizhao1991(a)gmail.com> > wrote: > > Hi, Hui, > > Thanks for your response, I have already read through the docs that you > said. It's very useful. > although I did some research still have some questions: > IMHO, there are 2 possible ways to do dynamic scheduling of cpu cores: > > > Could you clarify on what do you mean by “dynamic scheduling of cpu cores”? > > 1. using mpi_comm_spawn to spawn a new hydra_pmi_proxy on a different port > or using mpi_comm_spawn_multiple to spawn new processes on the same port > > > The port — the one shown on the hydra_pmi_proxy command line — is > implementation details for the communication between proxy and control; it > has nothing to do with how the process is spawned and on which host. For > MPICH, each host (node) will have one hydra_pmi_proxy running (spawning one > or more executables). > > If you only have one single program (executable) to be run on spawned > nodes, then you only need use `mpi_comm_spawn`. `mpi_comm_spawn_multiple` > is used when you need run multiple different executables. > > To control which host to spawn the process, you pass that information > through the MPI_Info object. > > but my question is that how to start the new processes on a remote > machine, using farm resource manager(qsub,bsub,etc)? *Is there a reserved > keyword in the MPI_info that can qualify for this function?* > > > Use MPI_Info argument, which is a set of key/value hints. In particular, > you may set `host` for where to launch the new process, or `hosfile` for a > file which provide a list of hosts. You may also set `weir` to specify > working directory for the new process. Without the hints, the default is > the information you passed on the command line or set by resource manager. > > 2. using mpi_comm_connect to connect an already started mpi application to > connect to another mpi application, but I didn't find some useful testcases > yet. Do you know if this way is possible? > > > Those are a set of routines to establish new communicators. You only need > use them if the existing communicators (MPI_COMM_WORLD and the comms that > returned from mpi_comm_spawn and mpi_comm_parent) are insufficient. They > are independent of spawning processes. > > Thanks, > Shuwei > >> >> >

1 0

Re: [mpich-discuss] _get_addr error while running application using MPICH
by William Gropp 17 Nov '18

17 Nov '18

I’m also at a loss to understand why "mpirun ./real.exe” would fail - if a -np xx argument is required, then mpirun should issue the error; if not, then a rational choice of default would be 1 process, and should behave as “mpirun -np 1 ./real.exe”. Of course, it should be mpiexec instead of mpirun, but that shouldn’t matter. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign > On Nov 15, 2018, at 1:01 PM, Gropp, William D via discuss <discuss(a)mpich.org> wrote: > > Yes, singleton is the ./real.exe below. At least that version should have worked. > Bill > > On Nov 14, 2018 2:00 PM, "Zhou, Hui" <zhouh(a)anl.gov> wrote: > Hi Bill, > > To clarify, a singleton refers to a process started directly — such as ./real.exe, right? For the case of `mpirun ./real.exe`, or even `mpirun -np 1 ./real.exe`, is not technically a singleton, correct? > > — > Hui Zhou > > >> On Nov 13, 2018, at 9:30 PM, William Gropp via discuss <discuss(a)mpich.org <mailto:[email protected]>> wrote: >> >> This is not quite true. From the MPI standard: >> >>> 10.5.2 Singleton MPI_INIT >>> >>> A high-quality implementation will allow any process (including those not started with a “parallel application” mechanism) to become an MPI process by calling MPI_INIT. >>> >> >> There was a time when MPICH could do this, and there were features in the original PMI to support this. >> >> Bill >> >> William Gropp >> Director and Chief Scientist, NCSA >> Thomas M. Siebel Chair in Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> >> >>> On Nov 13, 2018, at 10:27 AM, Si, Min via discuss <discuss(a)mpich.org <mailto:[email protected]>> wrote: >>> >>> Hi Zhifeng, >>> >>> You have to always execute the MPI program by using mpirun or mpiexec with -np <number of processes>. >>> >>> At MPI_Init, the process tries to read information (e.g., MPI rank, number of processes) from the PMI server which is another process launched by the mpiexec command. This information is necessary for MPI library to initialize communication (e.g., connecting two processes). >>> >>> Best regards, >>> Min >>> >>> On 2018/11/04 10:27, Zhifeng Yang via discuss wrote: >>>> Hi >>>> >>>> After I installed mpich and used it in a FORTRAN code. There is an error while running this FORTRAN code called real.exe by using the following command >>>> >>>> $./real.exe >>>> or >>>> $mpirun ./real.exe >>>> real.exe: error: _get_addr: No such file or directory >>>> real.exe: error: _get_addr: No such file or directory >>>> real.exe: error: _get_addr: No such file or directory >>>> Fatal error in MPI_Init: Other MPI error, error stack: >>>> MPIR_Init_thread(784).....: >>>> MPID_Init(1323)...........: channel initialization failed >>>> MPIDI_CH3_Init(120).......: >>>> MPID_nem_init_ckpt(852)...: >>>> MPIDI_CH3I_Seg_commit(364): PMI_Barrier returned -1 >>>> >>>> But while using mpirun with specifying number of processors. as follows >>>> $mpirun -np 1 ./real.exe >>>> There is no error any more. I am not sure why? do you have any explanation? Thank you very much >>>> >>>> Best regards >>>> Zhifeng >>>> >>>> >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss <https://lists.mpich.org/mailman/listinfo/discuss> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss <https://lists.mpich.org/mailman/listinfo/discuss> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss <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] _get_addr error while running application using MPICH
by Gropp, William D 15 Nov '18

15 Nov '18

Yes, singleton is the ./real.exe below. At least that version should have worked. Bill On Nov 14, 2018 2:00 PM, "Zhou, Hui" <zhouh(a)anl.gov> wrote: Hi Bill, To clarify, a singleton refers to a process started directly — such as ./real.exe, right? For the case of `mpirun ./real.exe`, or even `mpirun -np 1 ./real.exe`, is not technically a singleton, correct? — Hui Zhou On Nov 13, 2018, at 9:30 PM, William Gropp via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: This is not quite true. From the MPI standard: 10.5.2 Singleton MPI_INIT A high-quality implementation will allow any process (including those not started with a “parallel application” mechanism) to become an MPI process by calling MPI_INIT. There was a time when MPICH could do this, and there were features in the original PMI to support this. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Nov 13, 2018, at 10:27 AM, Si, Min via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Hi Zhifeng, You have to always execute the MPI program by using mpirun or mpiexec with -np <number of processes>. At MPI_Init, the process tries to read information (e.g., MPI rank, number of processes) from the PMI server which is another process launched by the mpiexec command. This information is necessary for MPI library to initialize communication (e.g., connecting two processes). Best regards, Min On 2018/11/04 10:27, Zhifeng Yang via discuss wrote: Hi After I installed mpich and used it in a FORTRAN code. There is an error while running this FORTRAN code called real.exe by using the following command $./real.exe or $mpirun ./real.exe real.exe: error: _get_addr: No such file or directory real.exe: error: _get_addr: No such file or directory real.exe: error: _get_addr: No such file or directory Fatal error in MPI_Init: Other MPI error, error stack: MPIR_Init_thread(784).....: MPID_Init(1323)...........: channel initialization failed MPIDI_CH3_Init(120).......: MPID_nem_init_ckpt(852)...: MPIDI_CH3I_Seg_commit(364): PMI_Barrier returned -1 But while using mpirun with specifying number of processors. as follows $mpirun -np 1 ./real.exe There is no error any more. I am not sure why? do you have any explanation? Thank you very much Best regards Zhifeng _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Segfault in MVAPICH 3.0.4 with the Intel 15.0 compilers
by Zhou, Hui 14 Nov '18

14 Nov '18

Hi Difu, This is mpich-discuss mailing list, not for intel fortran compiler or openmpi (which seem to be implied in the link you provided). Anyway, just saying having the same issue is very ambiguous. Often it turns out every one have their own different issue. Could you detail your issues here? — Hui Zhou On Nov 13, 2018, at 7:24 PM, 孙迪夫 via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Hi, I'm having problems same with this mentioned in https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-an… as noted in the post, the problem is: "The MVAPICH2 2.0.1 build causes the bodies of a few FRTL routines to be included in the shared libraries (e.g. for_rtl_init in libmpichf90.so.12). The actual code is included, not just references to be resolved later. That code is out-of-date and so does not run correctly. The compiler legitimately puts a call to for_rtl_init, etc. into the generated code. The link step for MVAPICH2 must be resolving that to a static FRTL library which is not the actual up-to-date FRTL static library. If we are correct, then this is not a Fortran compiler problem, not a Fortran run-time library problem and not an Intel MPI problem. It is an MVAPICH2 build problem. --Patrick" But I cannot find any solution to it in that post, is there any workaround about it? Thanks in advance. Difu _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] _get_addr error while running application using MPICH
by Zhou, Hui 14 Nov '18

14 Nov '18

Hi Bill, To clarify, a singleton refers to a process started directly — such as ./real.exe, right? For the case of `mpirun ./real.exe`, or even `mpirun -np 1 ./real.exe`, is not technically a singleton, correct? — Hui Zhou On Nov 13, 2018, at 9:30 PM, William Gropp via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: This is not quite true. From the MPI standard: 10.5.2 Singleton MPI_INIT A high-quality implementation will allow any process (including those not started with a “parallel application” mechanism) to become an MPI process by calling MPI_INIT. There was a time when MPICH could do this, and there were features in the original PMI to support this. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Nov 13, 2018, at 10:27 AM, Si, Min via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Hi Zhifeng, You have to always execute the MPI program by using mpirun or mpiexec with -np <number of processes>. At MPI_Init, the process tries to read information (e.g., MPI rank, number of processes) from the PMI server which is another process launched by the mpiexec command. This information is necessary for MPI library to initialize communication (e.g., connecting two processes). Best regards, Min On 2018/11/04 10:27, Zhifeng Yang via discuss wrote: Hi After I installed mpich and used it in a FORTRAN code. There is an error while running this FORTRAN code called real.exe by using the following command $./real.exe or $mpirun ./real.exe real.exe: error: _get_addr: No such file or directory real.exe: error: _get_addr: No such file or directory real.exe: error: _get_addr: No such file or directory Fatal error in MPI_Init: Other MPI error, error stack: MPIR_Init_thread(784).....: MPID_Init(1323)...........: channel initialization failed MPIDI_CH3_Init(120).......: MPID_nem_init_ckpt(852)...: MPIDI_CH3I_Seg_commit(364): PMI_Barrier returned -1 But while using mpirun with specifying number of processors. as follows $mpirun -np 1 ./real.exe There is no error any more. I am not sure why? do you have any explanation? Thank you very much Best regards Zhifeng _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] how to dynamically schedule process in mpich
by Zhou, Hui 14 Nov '18

14 Nov '18

Hi Shuwei, See my comments/questions between the quotes below: On Nov 13, 2018, at 12:33 AM, Shuwei Zhao <shuweizhao1991(a)gmail.com<mailto:[email protected]>> wrote: Hi, Hui, Thanks for your response, I have already read through the docs that you said. It's very useful. although I did some research still have some questions: IMHO, there are 2 possible ways to do dynamic scheduling of cpu cores: Could you clarify on what do you mean by “dynamic scheduling of cpu cores”? 1. using mpi_comm_spawn to spawn a new hydra_pmi_proxy on a different port or using mpi_comm_spawn_multiple to spawn new processes on the same port The port — the one shown on the hydra_pmi_proxy command line — is implementation details for the communication between proxy and control; it has nothing to do with how the process is spawned and on which host. For MPICH, each host (node) will have one hydra_pmi_proxy running (spawning one or more executables). If you only have one single program (executable) to be run on spawned nodes, then you only need use `mpi_comm_spawn`. `mpi_comm_spawn_multiple` is used when you need run multiple different executables. To control which host to spawn the process, you pass that information through the MPI_Info object. but my question is that how to start the new processes on a remote machine, using farm resource manager(qsub,bsub,etc)? Is there a reserved keyword in the MPI_info that can qualify for this function? Use MPI_Info argument, which is a set of key/value hints. In particular, you may set `host` for where to launch the new process, or `hosfile` for a file which provide a list of hosts. You may also set `weir` to specify working directory for the new process. Without the hints, the default is the information you passed on the command line or set by resource manager. 2. using mpi_comm_connect to connect an already started mpi application to connect to another mpi application, but I didn't find some useful testcases yet. Do you know if this way is possible? Those are a set of routines to establish new communicators. You only need use them if the existing communicators (MPI_COMM_WORLD and the comms that returned from mpi_comm_spawn and mpi_comm_parent) are insufficient. They are independent of spawning processes. Thanks, Shuwei

1 0

Re: [mpich-discuss] _get_addr error while running application using MPICH
by William Gropp 13 Nov '18

13 Nov '18

This is not quite true. From the MPI standard: > 10.5.2 Singleton MPI_INIT > > A high-quality implementation will allow any process (including those not started with a “parallel application” mechanism) to become an MPI process by calling MPI_INIT. > There was a time when MPICH could do this, and there were features in the original PMI to support this. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign > On Nov 13, 2018, at 10:27 AM, Si, Min via discuss <discuss(a)mpich.org> wrote: > > Hi Zhifeng, > > You have to always execute the MPI program by using mpirun or mpiexec with -np <number of processes>. > > At MPI_Init, the process tries to read information (e.g., MPI rank, number of processes) from the PMI server which is another process launched by the mpiexec command. This information is necessary for MPI library to initialize communication (e.g., connecting two processes). > > Best regards, > Min > > On 2018/11/04 10:27, Zhifeng Yang via discuss wrote: >> Hi >> >> After I installed mpich and used it in a FORTRAN code. There is an error while running this FORTRAN code called real.exe by using the following command >> >> $./real.exe >> or >> $mpirun ./real.exe >> real.exe: error: _get_addr: No such file or directory >> real.exe: error: _get_addr: No such file or directory >> real.exe: error: _get_addr: No such file or directory >> Fatal error in MPI_Init: Other MPI error, error stack: >> MPIR_Init_thread(784).....: >> MPID_Init(1323)...........: channel initialization failed >> MPIDI_CH3_Init(120).......: >> MPID_nem_init_ckpt(852)...: >> MPIDI_CH3I_Seg_commit(364): PMI_Barrier returned -1 >> >> But while using mpirun with specifying number of processors. as follows >> $mpirun -np 1 ./real.exe >> There is no error any more. I am not sure why? do you have any explanation? Thank you very much >> >> Best regards >> Zhifeng >> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss <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

Segfault in MVAPICH 3.0.4 with the Intel 15.0 compilers
by 孙迪夫 13 Nov '18

13 Nov '18

Hi, I'm having problems same with this mentioned in https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-an… as noted in the post, the problem is: "The MVAPICH2 2.0.1 build causes the bodies of a few FRTL routines to be included in the shared libraries (e.g. for_rtl_init in libmpichf90.so.12). The actual code is included, not just references to be resolved later. That code is out-of-date and so does not run correctly. The compiler legitimately puts a call to for_rtl_init, etc. into the generated code. The link step for MVAPICH2 must be resolving that to a static FRTL library which is not the actual up-to-date FRTL static library. If we are correct, then this is not a Fortran compiler problem, not a Fortran run-time library problem and not an Intel MPI problem. It is an MVAPICH2 build problem. --Patrick" But I cannot find any solution to it in that post, is there any workaround about it? Thanks in advance. Difu

1 0