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

(no subject)
by Kyle Hartley 15 Jul '14

15 Jul '14

Hey Guys, Hopefully my last question, I'm so close. Test c code by running the example cpi.c >mpiexec -f machinefile -n 2 ~/mpich_build/examples/cpi [mpiexec@NI-myRIO-1900-03037f65] control_cb (/home/admin/mpich-3.1.1/src/pm/hydra/pm/pmiserv/pmserv_cb.c:200): assert (!closed) failed [mpiexec@NI-myRIO-1900-03037f65] HYDT_dmxu_poll_wait_for_event (/home/admin/mpich-3.1.1/src/pm/ydra/tools/demux/demux_poll.c:76): callback returned error status [mpiexec@NI-myRIO-1900-03037f65] HYD_pmci_wait_for_completion (/home/admin/mpich-3.1.1/src/pm/hdra/pm/pmiserv/pmiserv_pmci.c:198): error waiting for event [mpiexec@NI-myRIO-1900-03037f65] main (/home/admin/mpich-3.1.1/src/pm/hydra/ui/mpich/mpiexec.c:44): process manager error waiting for completion I try to recompile and run cpi.c and it still gets the above error. I tried running a simple hello world example that compiles fine in mpicc and I get the same errors. GCC and g++* compilers work fine. I can run the cpi example by ./ just fine. G++ I discovered wasn't working when I tried to configure openmpi, created a link to the library and resolved the error in openmpi. This was after I configured and installed mpich. MPIexec throws same error. mpiexec -f machinefile -n # hostname works fine. So mpiexec is working its something to do when calling c code. 1. I can try to reconfigure mpich to see if this resolves the error and its a configuration mistake. 2. It seems like this was reproduced in March. http://lists.mpich.org/pipermail/discuss/2014-March/002396.html I'm not sure if this was resolved other than modifying code but this is the example and even simple code breaks. 3. This is a dual core arm processor so I can see if disabling the second core can help since it looks like it is a timing issue. Any other ideas? Thanks, Kyle Hartley

1 0

Re: [mpich-discuss] What is the difference between MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED
by Thakur, Rajeev 15 Jul '14

15 Jul '14

> Can you please let me know the answer to the second part of the question below? Is it OK for the code to use MPI_THREAD_SINGLE for the situation described below? The MPI standard says you should not use THREAD_SINGLE in that case. Rajeev On Jul 14, 2014, at 3:05 PM, Raghu Reddy <rreddypsc(a)gmail.com> wrote: > Hi Rajeev, > > > Thank you for your prompt response. > > > I understand why it is helpful to indicate there are other threads, which was the first part of my question. > > > Can you please let me know the answer to the second part of the question below? Is it OK for the code to use MPI_THREAD_SINGLE for the situation described below? > > > Thanks, > > Raghu > > > > On Sun, Jul 13, 2014 at 2:53 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: > It is so that the MPI implementation knows that other user threads exist. It can then invoke thread-safe versions of C or Fortran library calls if necessary. > > Rajeev > > > On Jul 13, 2014, at 8:04 AM, rreddypsc(a)gmail.com wrote: > > > Sorry about resurrecting a topic that is more than a month old. > > > > I was also under the impression that as long as all MPI calls are done outside of the threaded regions, using MPI_THREAD_SINGLE was sufficient. Based on the discussion below it looks like even in those situations one has to use MPI_THREAD_FUNNELED. > > > > For my understanding is it possible to briefly explain why this is the case? Is this still required, for example, if there is no MPI activity happening at all (for example no asynchronous communication is happening when any part of the threaded code is active)? > > > > In particular, I'm thinking about: > > > > MPI comm start > > MPI comm end > > > > threaded work (OpenMP for example with no MPI of any kind) > > > > MPI comm start > > MPI comm end > > ...etc > > > > The reason for this question is that I have a feeling that a lot of other users may be of the same opinion and would benefit from clarification. > > > > TIA for clarification! > > > > Raghu > > > > > > --On Monday, June 2, 2014 12:58 AM +0000 "Balaji, Pavan" <balaji(a)anl.gov> wrote: > > > >> > >> On May 30, 2014, at 12:30 PM, Boisvert, Sebastien <boisvert(a)anl.gov> > >> wrote: > >>> On Friday, May 30, 2014 12:26 PM, discuss-bounces(a)mpich.org > >>> [discuss-bounces(a)mpich.org] on behalf of Rajeev Thakur > >>> [thakur(a)mcs.anl.gov] wrote: > >>>> To: discuss(a)mpich.org > >>>> Subject: Re: [mpich-discuss] What is the difference between > >>>> MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED > >>>> > >>>> It shouldn't, but what does it return in your program? > >>> > >>> I am currently using MPI_Init (I thought it was OK if only the main > >>> thread calls MPI functions). > >>> > >>> Code-> > >>> https://github.com/GeneAssembly/biosal/blob/master/engine/node.c#L33 > >> > >> If you initialize with MPI_INIT, the MPI implementation can choose to > >> provide whatever thread-level it likes. There are two options for you: > >> > >> Option 1: > >> > >> MPI_INIT /* tell MPI to give you what it can */ > >> MPI_QUERY_THREAD /* ask for what you got */ > >> if (less than FUNNELED) abort; > >> > >> Option 2: > >> > >> MPI_INIT_THREAD(FUNNELED, &provided); /* tell MPI to give you FUNNELED */ > >> if (provided < FUNNELED) abort; > >> > >> Option 2 is cleaner since you gave MPI a hint that you would like to have > >> FUNNELED level. > >> > >> — Pavan > >> > >> _______________________________________________ > >> 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] What is the difference between MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED
by Raghu Reddy 14 Jul '14

14 Jul '14

Hi Rajeev, Thank you for your prompt response. I understand why it is helpful to indicate there are other threads, which was the first part of my question. Can you please let me know the answer to the second part of the question below? Is it OK for the code to use MPI_THREAD_SINGLE for the situation described below? Thanks, Raghu On Sun, Jul 13, 2014 at 2:53 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: > It is so that the MPI implementation knows that other user threads exist. > It can then invoke thread-safe versions of C or Fortran library calls if > necessary. > > Rajeev > > > On Jul 13, 2014, at 8:04 AM, rreddypsc(a)gmail.com wrote: > > > Sorry about resurrecting a topic that is more than a month old. > > > > I was also under the impression that as long as all MPI calls are done > outside of the threaded regions, using MPI_THREAD_SINGLE was sufficient. > Based on the discussion below it looks like even in those situations one > has to use MPI_THREAD_FUNNELED. > > > > For my understanding is it possible to briefly explain why this is the > case? Is this still required, for example, if there is no MPI activity > happening at all (for example no asynchronous communication is happening > when any part of the threaded code is active)? > > > > In particular, I'm thinking about: > > > > MPI comm start > > MPI comm end > > > > threaded work (OpenMP for example with no MPI of any kind) > > > > MPI comm start > > MPI comm end > > ...etc > > > > The reason for this question is that I have a feeling that a lot of > other users may be of the same opinion and would benefit from clarification. > > > > TIA for clarification! > > > > Raghu > > > > > > --On Monday, June 2, 2014 12:58 AM +0000 "Balaji, Pavan" <balaji(a)anl.gov> > wrote: > > > >> > >> On May 30, 2014, at 12:30 PM, Boisvert, Sebastien <boisvert(a)anl.gov> > >> wrote: > >>> On Friday, May 30, 2014 12:26 PM, discuss-bounces(a)mpich.org > >>> [discuss-bounces(a)mpich.org] on behalf of Rajeev Thakur > >>> [thakur(a)mcs.anl.gov] wrote: > >>>> To: discuss(a)mpich.org > >>>> Subject: Re: [mpich-discuss] What is the difference > between > >>>> MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED > >>>> > >>>> It shouldn't, but what does it return in your program? > >>> > >>> I am currently using MPI_Init (I thought it was OK if only the main > >>> thread calls MPI functions). > >>> > >>> Code-> > >>> https://github.com/GeneAssembly/biosal/blob/master/engine/node.c#L33 > >> > >> If you initialize with MPI_INIT, the MPI implementation can choose to > >> provide whatever thread-level it likes. There are two options for you: > >> > >> Option 1: > >> > >> MPI_INIT /* tell MPI to give you what it can */ > >> MPI_QUERY_THREAD /* ask for what you got */ > >> if (less than FUNNELED) abort; > >> > >> Option 2: > >> > >> MPI_INIT_THREAD(FUNNELED, &provided); /* tell MPI to give you FUNNELED > */ > >> if (provided < FUNNELED) abort; > >> > >> Option 2 is cleaner since you gave MPI a hint that you would like to > have > >> FUNNELED level. > >> > >> — Pavan > >> > >> _______________________________________________ > >> 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] MPICH 3.1.1 on NI MyRIO, error at ar interface
by jt.meng＠siat.ac.cn 13 Jul '14

13 Jul '14

不，。发自我的小米手机 Kyle Hartley <k.hartster(a)gmail.com>编写： >_______________________________________________ >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] MPICH 3.1.1 on NI MyRIO, error at ar interface
by jt.meng＠siat.ac.cn 13 Jul '14

13 Jul '14

发自我的小米手机 Kyle Hartley <k.hartster(a)gmail.com>编写： >_______________________________________________ >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] MPICH 3.1.1 on NI MyRIO, error at ar interface
by jt.meng＠siat.ac.cn 13 Jul '14

13 Jul '14

Lrl .nv 发自我的小米手机

1 0

Re: [mpich-discuss] What is the difference between MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED
by Thakur, Rajeev 13 Jul '14

13 Jul '14

It is so that the MPI implementation knows that other user threads exist. It can then invoke thread-safe versions of C or Fortran library calls if necessary. Rajeev On Jul 13, 2014, at 8:04 AM, rreddypsc(a)gmail.com wrote: > Sorry about resurrecting a topic that is more than a month old. > > I was also under the impression that as long as all MPI calls are done outside of the threaded regions, using MPI_THREAD_SINGLE was sufficient. Based on the discussion below it looks like even in those situations one has to use MPI_THREAD_FUNNELED. > > For my understanding is it possible to briefly explain why this is the case? Is this still required, for example, if there is no MPI activity happening at all (for example no asynchronous communication is happening when any part of the threaded code is active)? > > In particular, I'm thinking about: > > MPI comm start > MPI comm end > > threaded work (OpenMP for example with no MPI of any kind) > > MPI comm start > MPI comm end > ...etc > > The reason for this question is that I have a feeling that a lot of other users may be of the same opinion and would benefit from clarification. > > TIA for clarification! > > Raghu > > > --On Monday, June 2, 2014 12:58 AM +0000 "Balaji, Pavan" <balaji(a)anl.gov> wrote: > >> >> On May 30, 2014, at 12:30 PM, Boisvert, Sebastien <boisvert(a)anl.gov> >> wrote: >>> On Friday, May 30, 2014 12:26 PM, discuss-bounces(a)mpich.org >>> [discuss-bounces(a)mpich.org] on behalf of Rajeev Thakur >>> [thakur(a)mcs.anl.gov] wrote: >>>> To: discuss(a)mpich.org >>>> Subject: Re: [mpich-discuss] What is the difference between >>>> MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED >>>> >>>> It shouldn't, but what does it return in your program? >>> >>> I am currently using MPI_Init (I thought it was OK if only the main >>> thread calls MPI functions). >>> >>> Code-> >>> https://github.com/GeneAssembly/biosal/blob/master/engine/node.c#L33 >> >> If you initialize with MPI_INIT, the MPI implementation can choose to >> provide whatever thread-level it likes. There are two options for you: >> >> Option 1: >> >> MPI_INIT /* tell MPI to give you what it can */ >> MPI_QUERY_THREAD /* ask for what you got */ >> if (less than FUNNELED) abort; >> >> Option 2: >> >> MPI_INIT_THREAD(FUNNELED, &provided); /* tell MPI to give you FUNNELED */ >> if (provided < FUNNELED) abort; >> >> Option 2 is cleaner since you gave MPI a hint that you would like to have >> FUNNELED level. >> >> — Pavan >> >> _______________________________________________ >> 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] What is the difference between MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED
by rreddypsc＠gmail.com 13 Jul '14

13 Jul '14

Sorry about resurrecting a topic that is more than a month old. I was also under the impression that as long as all MPI calls are done outside of the threaded regions, using MPI_THREAD_SINGLE was sufficient. Based on the discussion below it looks like even in those situations one has to use MPI_THREAD_FUNNELED. For my understanding is it possible to briefly explain why this is the case? Is this still required, for example, if there is no MPI activity happening at all (for example no asynchronous communication is happening when any part of the threaded code is active)? In particular, I'm thinking about: MPI comm start MPI comm end threaded work (OpenMP for example with no MPI of any kind) MPI comm start MPI comm end ...etc The reason for this question is that I have a feeling that a lot of other users may be of the same opinion and would benefit from clarification. TIA for clarification! Raghu --On Monday, June 2, 2014 12:58 AM +0000 "Balaji, Pavan" <balaji(a)anl.gov> wrote: > > On May 30, 2014, at 12:30 PM, Boisvert, Sebastien <boisvert(a)anl.gov> > wrote: >> On Friday, May 30, 2014 12:26 PM, discuss-bounces(a)mpich.org >> [discuss-bounces(a)mpich.org] on behalf of Rajeev Thakur >> [thakur(a)mcs.anl.gov] wrote: >>> To: discuss(a)mpich.org >>> Subject: Re: [mpich-discuss] What is the difference between >>> MPI_THREAD_SINGLE and MPI_THREAD_FUNNELED >>> >>> It shouldn't, but what does it return in your program? >> >> I am currently using MPI_Init (I thought it was OK if only the main >> thread calls MPI functions). >> >> Code-> >> https://github.com/GeneAssembly/biosal/blob/master/engine/node.c#L33 > > If you initialize with MPI_INIT, the MPI implementation can choose to > provide whatever thread-level it likes. There are two options for you: > > Option 1: > > MPI_INIT /* tell MPI to give you what it can */ > MPI_QUERY_THREAD /* ask for what you got */ > if (less than FUNNELED) abort; > > Option 2: > > MPI_INIT_THREAD(FUNNELED, &provided); /* tell MPI to give you FUNNELED */ > if (provided < FUNNELED) abort; > > Option 2 is cleaner since you gave MPI a hint that you would like to have > FUNNELED level. > > — Pavan > > _______________________________________________ > 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] mpich-3.1.1 compiling error
by Balaji, Pavan 12 Jul '14

12 Jul '14

You should get a libmpifort.dylib on the mac, not a .so file. Did you use the Intel compiler by any chance? There seems to be an issue with libtool not understanding the Intel compilers on the mac. Alternatively, you can try building mpich with the GNU compilers. — Pavan On Jul 12, 2014, at 10:56 AM, Fei <cnfyfgm(a)gmail.com> wrote: > Dear Sir/Madam: > > I have installed mpich-3.1.1 on my Mac OS 10.9.4. When I compile my fortran code, I get the following error message: > ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/mpich-3.1.1/lib/libmpifort.so' for architecture x86_64 > > Could you please give me hand on how to solve this problem? Thank you. > > Sincerely yours, > Fei > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

mpich-3.1.1 compiling error
by Fei 12 Jul '14

12 Jul '14

Dear Sir/Madam: I have installed mpich-3.1.1 on my Mac OS 10.9.4. When I compile my fortran code, I get the following error message: ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/mpich-3.1.1/lib/libmpifort.so' for architecture x86_64 Could you please give me hand on how to solve this problem? Thank you. Sincerely yours, Fei

1 0