April 2015 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] patches for createf90types.c to test DP
by Junchao Zhang 30 Apr '15

30 Apr '15

On Thu, Apr 23, 2015 at 2:39 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Thanks. Please also apply the attached patch (0004) to fix a trivial bug. > > The other patch (0003) will make this test XFAIL. You should not > apply it yet, but that's where I'm going... > Jeff, I applied your 0001, 0002, 0004 patches and pushed them to mpich/master. > > Jeff > > > On Thu, Apr 23, 2015 at 10:44 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> > wrote: > > I will add your patch. Thanks. > > > > --Junchao Zhang > > > > On Thu, Apr 23, 2015 at 12:31 PM, Jeff Hammond <jeff.science(a)gmail.com> > > wrote: > >> > >> Patches for test/mpi/f90/f90types/createf90types.c that test > >> MPI_Type_create_f90_complex for 64b floats are attached. > >> > >> If these patches are accepted, I want to extend them to support the > >> case of REAL128 (http://fortranwiki.org/fortran/show/Real+precision) > >> which is part of Fortran 2008 and therefore should be supported by > >> MPICH. Tests for REAL128 will fail since MPICH does not support it > >> yet, but I'm hoping to inspire this to change. And I might end up > >> doing it myself if I have to. > >> > >> Thanks, > >> > >> Jeff > >> > >> -- > >> Jeff Hammond > >> jeff.science(a)gmail.com > >> http://jeffhammond.github.io/ > >> > >> _______________________________________________ > >> To manage subscription options or unsubscribe: > >> https://lists.mpich.org/mailman/listinfo/devel > > > > > > > > _______________________________________________ > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/devel > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] call PMI before MPI_Init_thread?
by Jeff Hammond 25 Apr '15

25 Apr '15

Sorry, I meant "change the PMI spec" instead of "implement", but I guess it doesn't matter if it works everywhere. Jeff On Sat, Apr 25, 2015 at 4:23 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > It works in the implementation, so I’m not sure what you mean. I just mean it’s not allowed per the “spec” (or whatever sparse documentation we have that others use for implementing PMI). > > — Pavan > >> On Apr 24, 2015, at 7:22 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> Why not implement the equivalent of the ref-counting init proposal or >> at least the simple things that allows multiple inits but only one >> finalize? Is it that you don't see the effort being worthwhile or >> because there is a principled reason (PMI semantics should match MPI)? >> >> Given that e.g. PGAS runtimes may want to use PMI for bootstrapping (I >> do this with DMAPP code on Cray, for example), it seems to benefit >> user experience to support this behavior. >> >> Thanks, >> >> Jeff >> >> On Fri, Apr 24, 2015 at 1:12 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>> >>> Multiple PMI Inits are not allowed. It might work in the current >>> implementation within MPICH, but is not safe. >>> >>> If you are looking for MPICH specific behavior, you can look for the PMI_ID >>> and PMI_RANK environment variables instead to get your rank. >>> >>> — Pavan >>> >>> On Apr 21, 2015, at 11:17 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> >>> So MPICH doesn't fail when I try this on my Mac, but it would be good >>> to know if I have a reasonable expectation of doing this in general. >>> >>> Thanks, >>> >>> Jeff >>> >>> jrhammon-mac01:ENDPOINTS jrhammon$ mpiexec -n 4 ./a.out >>> PMI says I am 2 of 4 >>> PMI says I am 0 of 4 >>> PMI says I am 1 of 4 >>> PMI says I am 3 of 4 >>> MPI says I am 0 of 4 (provided=1) >>> MPI says I am 2 of 4 (provided=1) >>> MPI says I am 3 of 4 (provided=3) >>> MPI says I am 1 of 4 (provided=3) >>> >>> jrhammon-mac01:ENDPOINTS jrhammon$ cat pmi.c >>> #include <stdio.h> >>> #include <stdlib.h> >>> >>> /*#include <pmi.h>*/ >>> int PMI_Init( int *spawned ); >>> int PMI_Finalize( void ); >>> int PMI_Get_size( int *size ); >>> int PMI_Get_rank( int *rank ); >>> >>> #include <mpi.h> >>> >>> int main(int argc, char * argv[]) >>> { >>> int has_parent; >>> PMI_Init(&has_parent); >>> >>> int rank, size; >>> PMI_Get_size(&size); >>> PMI_Get_rank(&rank); >>> >>> printf("PMI says I am %d of %d \n", rank, size); >>> fflush(stdout); >>> >>> int requested = (rank%2==0) ? MPI_THREAD_FUNNELED : MPI_THREAD_MULTIPLE; >>> int provided; >>> MPI_Init_thread(&argc, &argv, requested, &provided); >>> >>> int wsize, wrank; >>> MPI_Comm_size(MPI_COMM_WORLD, &wsize); >>> MPI_Comm_rank(MPI_COMM_WORLD, &wrank); >>> >>> printf("MPI says I am %d of %d (provided=%d)\n", wrank, wsize, provided); >>> fflush(stdout); >>> >>> MPI_Finalize(); >>> //PMI_Finalize(); /* required? */ >>> >>> return 0; >>> } >>> >>> On Tue, Apr 21, 2015 at 9:09 PM, Jeff Hammond <jeff.science(a)gmail.com> >>> wrote: >>> >>> Is it valid in _MPICH_ to make calls to PMI before MPI is initialized? >>> I am interested in PMI_Init, PMI_Get_size and PMI_Get_rank. >>> >>> The motivating use case is to initialize e.g. half my ranks with >>> MPI_THREAD_FUNNELED and the other half with MPI_THREAD_MULTIPLE but >>> not use MPMD launching. >>> >>> I have two reasons for wanting to do it this way. First, it is >>> otherwise unnecessary to use MPMD since I can branch at the top of my >>> code and meet the requirements of FUNNELED and MULTIPLE. Second, I >>> might be interested in running my code on a supercomputer with an >>> MPICH-based MPI implementation that does not support MPMD launching in >>> an unrestricted manner. >>> >>> If MPICH can handle this, then I will worry about whether or not the >>> aforementioned supercomputer can. It is my assumption that, if MPICH >>> cannot handle this, then the MPICH derivative in question cannot >>> either. >>> >>> Thanks, >>> >>> Jeff >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> >>> >>> >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/devel >>> >>> >>> >>> _______________________________________________ >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/devel >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] call PMI before MPI_Init_thread?
by Balaji, Pavan 25 Apr '15

25 Apr '15

It works in the implementation, so I’m not sure what you mean. I just mean it’s not allowed per the “spec” (or whatever sparse documentation we have that others use for implementing PMI). — Pavan > On Apr 24, 2015, at 7:22 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > Why not implement the equivalent of the ref-counting init proposal or > at least the simple things that allows multiple inits but only one > finalize? Is it that you don't see the effort being worthwhile or > because there is a principled reason (PMI semantics should match MPI)? > > Given that e.g. PGAS runtimes may want to use PMI for bootstrapping (I > do this with DMAPP code on Cray, for example), it seems to benefit > user experience to support this behavior. > > Thanks, > > Jeff > > On Fri, Apr 24, 2015 at 1:12 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> Multiple PMI Inits are not allowed. It might work in the current >> implementation within MPICH, but is not safe. >> >> If you are looking for MPICH specific behavior, you can look for the PMI_ID >> and PMI_RANK environment variables instead to get your rank. >> >> — Pavan >> >> On Apr 21, 2015, at 11:17 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> So MPICH doesn't fail when I try this on my Mac, but it would be good >> to know if I have a reasonable expectation of doing this in general. >> >> Thanks, >> >> Jeff >> >> jrhammon-mac01:ENDPOINTS jrhammon$ mpiexec -n 4 ./a.out >> PMI says I am 2 of 4 >> PMI says I am 0 of 4 >> PMI says I am 1 of 4 >> PMI says I am 3 of 4 >> MPI says I am 0 of 4 (provided=1) >> MPI says I am 2 of 4 (provided=1) >> MPI says I am 3 of 4 (provided=3) >> MPI says I am 1 of 4 (provided=3) >> >> jrhammon-mac01:ENDPOINTS jrhammon$ cat pmi.c >> #include <stdio.h> >> #include <stdlib.h> >> >> /*#include <pmi.h>*/ >> int PMI_Init( int *spawned ); >> int PMI_Finalize( void ); >> int PMI_Get_size( int *size ); >> int PMI_Get_rank( int *rank ); >> >> #include <mpi.h> >> >> int main(int argc, char * argv[]) >> { >> int has_parent; >> PMI_Init(&has_parent); >> >> int rank, size; >> PMI_Get_size(&size); >> PMI_Get_rank(&rank); >> >> printf("PMI says I am %d of %d \n", rank, size); >> fflush(stdout); >> >> int requested = (rank%2==0) ? MPI_THREAD_FUNNELED : MPI_THREAD_MULTIPLE; >> int provided; >> MPI_Init_thread(&argc, &argv, requested, &provided); >> >> int wsize, wrank; >> MPI_Comm_size(MPI_COMM_WORLD, &wsize); >> MPI_Comm_rank(MPI_COMM_WORLD, &wrank); >> >> printf("MPI says I am %d of %d (provided=%d)\n", wrank, wsize, provided); >> fflush(stdout); >> >> MPI_Finalize(); >> //PMI_Finalize(); /* required? */ >> >> return 0; >> } >> >> On Tue, Apr 21, 2015 at 9:09 PM, Jeff Hammond <jeff.science(a)gmail.com> >> wrote: >> >> Is it valid in _MPICH_ to make calls to PMI before MPI is initialized? >> I am interested in PMI_Init, PMI_Get_size and PMI_Get_rank. >> >> The motivating use case is to initialize e.g. half my ranks with >> MPI_THREAD_FUNNELED and the other half with MPI_THREAD_MULTIPLE but >> not use MPMD launching. >> >> I have two reasons for wanting to do it this way. First, it is >> otherwise unnecessary to use MPMD since I can branch at the top of my >> code and meet the requirements of FUNNELED and MULTIPLE. Second, I >> might be interested in running my code on a supercomputer with an >> MPICH-based MPI implementation that does not support MPMD launching in >> an unrestricted manner. >> >> If MPICH can handle this, then I will worry about whether or not the >> aforementioned supercomputer can. It is my assumption that, if MPICH >> cannot handle this, then the MPICH derivative in question cannot >> either. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> >> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] call PMI before MPI_Init_thread?
by Jeff Hammond 24 Apr '15

24 Apr '15

Why not implement the equivalent of the ref-counting init proposal or at least the simple things that allows multiple inits but only one finalize? Is it that you don't see the effort being worthwhile or because there is a principled reason (PMI semantics should match MPI)? Given that e.g. PGAS runtimes may want to use PMI for bootstrapping (I do this with DMAPP code on Cray, for example), it seems to benefit user experience to support this behavior. Thanks, Jeff On Fri, Apr 24, 2015 at 1:12 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > Multiple PMI Inits are not allowed. It might work in the current > implementation within MPICH, but is not safe. > > If you are looking for MPICH specific behavior, you can look for the PMI_ID > and PMI_RANK environment variables instead to get your rank. > > — Pavan > > On Apr 21, 2015, at 11:17 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > So MPICH doesn't fail when I try this on my Mac, but it would be good > to know if I have a reasonable expectation of doing this in general. > > Thanks, > > Jeff > > jrhammon-mac01:ENDPOINTS jrhammon$ mpiexec -n 4 ./a.out > PMI says I am 2 of 4 > PMI says I am 0 of 4 > PMI says I am 1 of 4 > PMI says I am 3 of 4 > MPI says I am 0 of 4 (provided=1) > MPI says I am 2 of 4 (provided=1) > MPI says I am 3 of 4 (provided=3) > MPI says I am 1 of 4 (provided=3) > > jrhammon-mac01:ENDPOINTS jrhammon$ cat pmi.c > #include <stdio.h> > #include <stdlib.h> > > /*#include <pmi.h>*/ > int PMI_Init( int *spawned ); > int PMI_Finalize( void ); > int PMI_Get_size( int *size ); > int PMI_Get_rank( int *rank ); > > #include <mpi.h> > > int main(int argc, char * argv[]) > { > int has_parent; > PMI_Init(&has_parent); > > int rank, size; > PMI_Get_size(&size); > PMI_Get_rank(&rank); > > printf("PMI says I am %d of %d \n", rank, size); > fflush(stdout); > > int requested = (rank%2==0) ? MPI_THREAD_FUNNELED : MPI_THREAD_MULTIPLE; > int provided; > MPI_Init_thread(&argc, &argv, requested, &provided); > > int wsize, wrank; > MPI_Comm_size(MPI_COMM_WORLD, &wsize); > MPI_Comm_rank(MPI_COMM_WORLD, &wrank); > > printf("MPI says I am %d of %d (provided=%d)\n", wrank, wsize, provided); > fflush(stdout); > > MPI_Finalize(); > //PMI_Finalize(); /* required? */ > > return 0; > } > > On Tue, Apr 21, 2015 at 9:09 PM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: > > Is it valid in _MPICH_ to make calls to PMI before MPI is initialized? > I am interested in PMI_Init, PMI_Get_size and PMI_Get_rank. > > The motivating use case is to initialize e.g. half my ranks with > MPI_THREAD_FUNNELED and the other half with MPI_THREAD_MULTIPLE but > not use MPMD launching. > > I have two reasons for wanting to do it this way. First, it is > otherwise unnecessary to use MPMD since I can branch at the top of my > code and meet the requirements of FUNNELED and MULTIPLE. Second, I > might be interested in running my code on a supercomputer with an > MPICH-based MPI implementation that does not support MPMD launching in > an unrestricted manner. > > If MPICH can handle this, then I will worry about whether or not the > aforementioned supercomputer can. It is my assumption that, if MPICH > cannot handle this, then the MPICH derivative in question cannot > either. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] call PMI before MPI_Init_thread?
by Balaji, Pavan 24 Apr '15

24 Apr '15

Multiple PMI Inits are not allowed. It might work in the current implementation within MPICH, but is not safe. If you are looking for MPICH specific behavior, you can look for the PMI_ID and PMI_RANK environment variables instead to get your rank. — Pavan On Apr 21, 2015, at 11:17 PM, Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> wrote: So MPICH doesn't fail when I try this on my Mac, but it would be good to know if I have a reasonable expectation of doing this in general. Thanks, Jeff jrhammon-mac01:ENDPOINTS jrhammon$ mpiexec -n 4 ./a.out PMI says I am 2 of 4 PMI says I am 0 of 4 PMI says I am 1 of 4 PMI says I am 3 of 4 MPI says I am 0 of 4 (provided=1) MPI says I am 2 of 4 (provided=1) MPI says I am 3 of 4 (provided=3) MPI says I am 1 of 4 (provided=3) jrhammon-mac01:ENDPOINTS jrhammon$ cat pmi.c #include <stdio.h> #include <stdlib.h> /*#include <pmi.h>*/ int PMI_Init( int *spawned ); int PMI_Finalize( void ); int PMI_Get_size( int *size ); int PMI_Get_rank( int *rank ); #include <mpi.h> int main(int argc, char * argv[]) { int has_parent; PMI_Init(&has_parent); int rank, size; PMI_Get_size(&size); PMI_Get_rank(&rank); printf("PMI says I am %d of %d \n", rank, size); fflush(stdout); int requested = (rank%2==0) ? MPI_THREAD_FUNNELED : MPI_THREAD_MULTIPLE; int provided; MPI_Init_thread(&argc, &argv, requested, &provided); int wsize, wrank; MPI_Comm_size(MPI_COMM_WORLD, &wsize); MPI_Comm_rank(MPI_COMM_WORLD, &wrank); printf("MPI says I am %d of %d (provided=%d)\n", wrank, wsize, provided); fflush(stdout); MPI_Finalize(); //PMI_Finalize(); /* required? */ return 0; } On Tue, Apr 21, 2015 at 9:09 PM, Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> wrote: Is it valid in _MPICH_ to make calls to PMI before MPI is initialized? I am interested in PMI_Init, PMI_Get_size and PMI_Get_rank. The motivating use case is to initialize e.g. half my ranks with MPI_THREAD_FUNNELED and the other half with MPI_THREAD_MULTIPLE but not use MPMD launching. I have two reasons for wanting to do it this way. First, it is otherwise unnecessary to use MPMD since I can branch at the top of my code and meet the requirements of FUNNELED and MULTIPLE. Second, I might be interested in running my code on a supercomputer with an MPICH-based MPI implementation that does not support MPMD launching in an unrestricted manner. If MPICH can handle this, then I will worry about whether or not the aforementioned supercomputer can. It is my assumption that, if MPICH cannot handle this, then the MPICH derivative in question cannot either. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ _______________________________________________ To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] patches for createf90types.c to test DP
by Jeff Hammond 23 Apr '15

23 Apr '15

Yeah, no urgency here. I can push a review branch once I get the QP stuff implemented. Jeff On Thu, Apr 23, 2015 at 12:46 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > OK. MPICH is now in freeze for 3.2b2 release. I will do it after the > release. > > --Junchao Zhang > > On Thu, Apr 23, 2015 at 2:39 PM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: >> >> Thanks. Please also apply the attached patch (0004) to fix a trivial bug. >> >> The other patch (0003) will make this test XFAIL. You should not >> apply it yet, but that's where I'm going... >> >> Jeff >> >> >> On Thu, Apr 23, 2015 at 10:44 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> > I will add your patch. Thanks. >> > >> > --Junchao Zhang >> > >> > On Thu, Apr 23, 2015 at 12:31 PM, Jeff Hammond <jeff.science(a)gmail.com> >> > wrote: >> >> >> >> Patches for test/mpi/f90/f90types/createf90types.c that test >> >> MPI_Type_create_f90_complex for 64b floats are attached. >> >> >> >> If these patches are accepted, I want to extend them to support the >> >> case of REAL128 (http://fortranwiki.org/fortran/show/Real+precision) >> >> which is part of Fortran 2008 and therefore should be supported by >> >> MPICH. Tests for REAL128 will fail since MPICH does not support it >> >> yet, but I'm hoping to inspire this to change. And I might end up >> >> doing it myself if I have to. >> >> >> >> Thanks, >> >> >> >> Jeff >> >> >> >> -- >> >> Jeff Hammond >> >> jeff.science(a)gmail.com >> >> http://jeffhammond.github.io/ >> >> >> >> _______________________________________________ >> >> To manage subscription options or unsubscribe: >> >> https://lists.mpich.org/mailman/listinfo/devel >> > >> > >> > >> > _______________________________________________ >> > To manage subscription options or unsubscribe: >> > https://lists.mpich.org/mailman/listinfo/devel >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] patches for createf90types.c to test DP
by Junchao Zhang 23 Apr '15

23 Apr '15

OK. MPICH is now in freeze for 3.2b2 release. I will do it after the release. --Junchao Zhang On Thu, Apr 23, 2015 at 2:39 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Thanks. Please also apply the attached patch (0004) to fix a trivial bug. > > The other patch (0003) will make this test XFAIL. You should not > apply it yet, but that's where I'm going... > > Jeff > > > On Thu, Apr 23, 2015 at 10:44 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> > wrote: > > I will add your patch. Thanks. > > > > --Junchao Zhang > > > > On Thu, Apr 23, 2015 at 12:31 PM, Jeff Hammond <jeff.science(a)gmail.com> > > wrote: > >> > >> Patches for test/mpi/f90/f90types/createf90types.c that test > >> MPI_Type_create_f90_complex for 64b floats are attached. > >> > >> If these patches are accepted, I want to extend them to support the > >> case of REAL128 (http://fortranwiki.org/fortran/show/Real+precision) > >> which is part of Fortran 2008 and therefore should be supported by > >> MPICH. Tests for REAL128 will fail since MPICH does not support it > >> yet, but I'm hoping to inspire this to change. And I might end up > >> doing it myself if I have to. > >> > >> Thanks, > >> > >> Jeff > >> > >> -- > >> Jeff Hammond > >> jeff.science(a)gmail.com > >> http://jeffhammond.github.io/ > >> > >> _______________________________________________ > >> To manage subscription options or unsubscribe: > >> https://lists.mpich.org/mailman/listinfo/devel > > > > > > > > _______________________________________________ > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/devel > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] patches for createf90types.c to test DP
by Jeff Hammond 23 Apr '15

23 Apr '15

Thanks. Please also apply the attached patch (0004) to fix a trivial bug. The other patch (0003) will make this test XFAIL. You should not apply it yet, but that's where I'm going... Jeff On Thu, Apr 23, 2015 at 10:44 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > I will add your patch. Thanks. > > --Junchao Zhang > > On Thu, Apr 23, 2015 at 12:31 PM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: >> >> Patches for test/mpi/f90/f90types/createf90types.c that test >> MPI_Type_create_f90_complex for 64b floats are attached. >> >> If these patches are accepted, I want to extend them to support the >> case of REAL128 (http://fortranwiki.org/fortran/show/Real+precision) >> which is part of Fortran 2008 and therefore should be supported by >> MPICH. Tests for REAL128 will fail since MPICH does not support it >> yet, but I'm hoping to inspire this to change. And I might end up >> doing it myself if I have to. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] patches for createf90types.c to test DP
by Junchao Zhang 23 Apr '15

23 Apr '15

I will add your patch. Thanks. --Junchao Zhang On Thu, Apr 23, 2015 at 12:31 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Patches for test/mpi/f90/f90types/createf90types.c that test > MPI_Type_create_f90_complex for 64b floats are attached. > > If these patches are accepted, I want to extend them to support the > case of REAL128 (http://fortranwiki.org/fortran/show/Real+precision) > which is part of Fortran 2008 and therefore should be supported by > MPICH. Tests for REAL128 will fail since MPICH does not support it > yet, but I'm hoping to inspire this to change. And I might end up > doing it myself if I have to. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

patches for createf90types.c to test DP
by Jeff Hammond 23 Apr '15

23 Apr '15

Patches for test/mpi/f90/f90types/createf90types.c that test MPI_Type_create_f90_complex for 64b floats are attached. If these patches are accepted, I want to extend them to support the case of REAL128 (http://fortranwiki.org/fortran/show/Real+precision) which is part of Fortran 2008 and therefore should be supported by MPICH. Tests for REAL128 will fail since MPICH does not support it yet, but I'm hoping to inspire this to change. And I might end up doing it myself if I have to. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0