May 2013 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Porting MPICH
by jhonatan alves 19 May '13

19 May '13

Hello, There are some functions, but we need to talk with the OS developer to find out which are missing. But i believe that the missing of POSIX threads can be the most trouble part. So we need to port to the thread implementation in EPOS. We are trying to MPICH right now to see what breaks. We will get those information and pass on the list. Thank you for helping. 2013/5/19 Pavan Balaji <balaji(a)mcs.anl.gov> > > On 05/19/2013 01:47 PM US Central Time, jhonatan alves wrote: > > We are trying port MPICH to a new operating system, called EPOS, but our > > main problem at the moment is that this operating system is not POSIX > > compatible. > > Our question is there some way to compile MPICH setting that is free of > > platform, so then we can implement the missing functions. > > MPICH is relatively platform independent, though no POSIX is a bit > overkill. Are no POSIX functions available or are a few functions > missing? If it's the latter, which functions? > > Did you try building mpich as-is, and see what breaks? > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji >

1 0

Re: [mpich-discuss] Porting MPICH
by Jeff Hammond 19 May '13

19 May '13

What is the goal? Do you want MPICH to run trivially within a single process image, within a single node via interprocess communication, over multiple processes via TCP/IP, or something else? You might want to elaborate on what your operating system can do. Does "not POSIX" mean that it doesn't a single function defined by POSIX? Do you support the C standard library? Does your machine have GCC is some non-standard C compiler? It would also be useful to provide a make.log that shows where the compilation actually stops. I think that your best best is something along the lines of: while (1) { try to build; if (builds without errors) break; determine why it failed; implement the missing function; } The developer documentation is located at https://wiki.mpich.org/mpich/index.php/Developer_Documentation but this is almost certainly not a porting guide for porting MPICH to any system that is formally equivalent to a Turing machine. Jeff On Sun, May 19, 2013 at 1:47 PM, jhonatan alves <jhonatanalves1(a)gmail.com> wrote: > Hello, > We are trying port MPICH to a new operating system, called EPOS, but our > main problem at the moment is that this operating system is not POSIX > compatible. > Our question is there some way to compile MPICH setting that is free of > platform, so then we can implement the missing functions. > And is there a porting manual of MPICH? > > Thx > > _______________________________________________ > 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-discuss] Porting MPICH
by Pavan Balaji 19 May '13

19 May '13

On 05/19/2013 01:47 PM US Central Time, jhonatan alves wrote: > We are trying port MPICH to a new operating system, called EPOS, but our > main problem at the moment is that this operating system is not POSIX > compatible. > Our question is there some way to compile MPICH setting that is free of > platform, so then we can implement the missing functions. MPICH is relatively platform independent, though no POSIX is a bit overkill. Are no POSIX functions available or are a few functions missing? If it's the latter, which functions? Did you try building mpich as-is, and see what breaks? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Porting MPICH
by jhonatan alves 19 May '13

19 May '13

Hello, We are trying port MPICH to a new operating system, called EPOS, but our main problem at the moment is that this operating system is not POSIX compatible. Our question is there some way to compile MPICH setting that is free of platform, so then we can implement the missing functions. And is there a porting manual of MPICH? Thx

1 0

Re: [mpich-discuss] Using arrays with negative indices in MPI Fortran
by Jeff Hammond 19 May '13

19 May '13

Can you post the code? That will help a lot. Thanks, Jeff Sent from my iPhone On May 19, 2013, at 10:24 AM, Himadri Barman <hbarhbar(a)gmail.com> wrote: Hi, I have a question: If I have an array with negative indices, say defined as A(-5:5) in Fortran. Can I use that for COLLECTIVE CALL, e.g MPI_Bcast, MPI_Gather without transforming to a new array with positive indices? If I have my array defined as A(0:11), I find no issues. Hope you can help me. Thanks and best regards, - Himadri -- Himadri Barman, Research Associate, Theoretical Sciences Unit, Jawaharlal Nehru Centre for Advanced Scientific Research, Jakkur PO, Bangalore- 560 064, India. Phone: 91-80-2208-2986 Webpage: http://www.jncasr.ac.in/hbar/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Using arrays with negative indices in MPI Fortran
by Himadri Barman 19 May '13

19 May '13

Hi, I have a question: If I have an array with negative indices, say defined as A(-5:5) in Fortran. Can I use that for COLLECTIVE CALL, e.g MPI_Bcast, MPI_Gather without transforming to a new array with positive indices? If I have my array defined as A(0:11), I find no issues. Hope you can help me. Thanks and best regards, - Himadri -- Himadri Barman, Research Associate, Theoretical Sciences Unit, Jawaharlal Nehru Centre for Advanced Scientific Research, Jakkur PO, Bangalore- 560 064, India. Phone: 91-80-2208-2986 Webpage: http://www.jncasr.ac.in/hbar/

1 0

Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
by Pavan Balaji 18 May '13

18 May '13

Not intentional. Cc'ed discuss(a)mpich.org so it's archived for future users. -- Pavan On 05/18/2013 05:36 PM US Central Time, Jed Brown wrote: > [Was drifting off-list intentional?] > > Fab Tillier <ftillier(a)microsoft.com> writes: > >> Pavan Balaji wrote on Sat, 18 May 2013 at 14:39:37 >> >> Ok, that's great, I think we're saying/expecting the same thing, then. >> I'll take a look to see what it would take to fix MSMPI. >> >> Are you folks interested in testing out the fix, or is it good enough >> for us to run the unit test and call it good? > > It's likely that the unit test is enough, but we'd be happy to test with > PETSc. > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
by Pavan Balaji 18 May '13

18 May '13

On 05/18/2013 04:33 PM US Central Time, Pavan Balaji wrote: > > On 05/18/2013 04:19 PM US Central Time, Fab Tillier wrote: >> Pavan Balaji wrote on Sat, 18 May 2013 at 14:02:17 >> >>> In MPICH, here's what we do: >>> >>> 1. Run the user callback. If it returned an error, return that error to >>> the user. >> >> So you don't actually free the attribute if the callback succeeds? > > If the callback succeeds and the ref-count on the communicator is zero, > we free the attributes. ... and ref-count on the attributes (not communicator) ... Gawd! -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
by Pavan Balaji 18 May '13

18 May '13

On 05/18/2013 04:19 PM US Central Time, Fab Tillier wrote: > Pavan Balaji wrote on Sat, 18 May 2013 at 14:02:17 > >> In MPICH, here's what we do: >> >> 1. Run the user callback. If it returned an error, return that error to >> the user. > > So you don't actually free the attribute if the callback succeeds? If the callback succeeds and the ref-count on the communicator is zero, we free the attributes. > What happens if the callback fails, but some preceding attributes' > callbacks succeeded? If you wanted to provide some level of fault > tolerance (since attribute delete callbacks could be recoverable > errors), what happens on a subsequent call to MPI_COMM_FREE? Do the > attributes that had their callback called successfully get a second > delete call? Whoops, I realized my previous list had a small typo. I meant to say that the ref-count for the attribute keyval is reduced on a delete (that should not be guarded by the comm ref-count == 0). Here's the corrected version: 1. Run the user callback. If it returned an error, return that error to the user. 2. Decrement the attribute keyval ref-count. - If the ref-count has reached zero, free the keyval. 3. Decrement the communicator ref-count. - If the ref-count has reached zero, free the communicator. > It seems that once an attribute delete callback returns success, that > attribute should be deleted (that is, you don't need to delay the > deletion until the ref count of the communicator reaches zero). Yes. >> If the user did a MPI_BCAST, there's no problem since after the >> callback, the communicator ref-count does not include the BCAST. On the >> other hand, if the user did an MPI_IBCAST, then the ref-count will not >> touch zero, so the communicator is not actually deleted internally. >> >> The attribute might not actually get deleted if the ref-count didn't >> reach zero, but you can't access them anyway, since the comm handle if >> not valid. They'll eventually get freed when the ref-count reaches zero. > > Right, so why not just delete the attribute from the context of the > MPI_COMM_FREE call, rather than delaying until the ref count reaches > zero? I didn't think attributes could affect internal MPI > operations, so thought they could be freed early. We check for a ref-count on the attributes. It does decrement the ref-count and might free it. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
by Fab Tillier 18 May '13

18 May '13

Pavan Balaji wrote on Sat, 18 May 2013 at 14:02:17 > In MPICH, here's what we do: > > 1. Run the user callback. If it returned an error, return that error to > the user. So you don't actually free the attribute if the callback succeeds? What happens if the callback fails, but some preceding attributes' callbacks succeeded? If you wanted to provide some level of fault tolerance (since attribute delete callbacks could be recoverable errors), what happens on a subsequent call to MPI_COMM_FREE? Do the attributes that had their callback called successfully get a second delete call? It seems that once an attribute delete callback returns success, that attribute should be deleted (that is, you don't need to delay the deletion until the ref count of the communicator reaches zero). > 2. Decrement the communicator ref-count. > > 3. If the ref-count has reached zero, free the attributes and then free > the communicator. Delaying freeing the attributes (when the delete callback has been invoked and has freed whatever state it had) seems odd to me. Wouldn't it require extra bookkeeping? Do you see a problem with freeing the attribute immediately after the delete callback succeeds (regardless of comm ref count)? This would solve any issues with a subsequent call to MPI_COMM_FREE, in that only attributes whose delete callback failed or weren't called would get invoked. > If the user did a MPI_BCAST, there's no problem since after the > callback, the communicator ref-count does not include the BCAST. On the > other hand, if the user did an MPI_IBCAST, then the ref-count will not > touch zero, so the communicator is not actually deleted internally. > > The attribute might not actually get deleted if the ref-count didn't > reach zero, but you can't access them anyway, since the comm handle if > not valid. They'll eventually get freed when the ref-count reaches zero. Right, so why not just delete the attribute from the context of the MPI_COMM_FREE call, rather than delaying until the ref count reaches zero? I didn't think attributes could affect internal MPI operations, so thought they could be freed early. Thanks, -Fab

1 0