- devel - mailman3.cels.anl.gov

Re: [mpich-devel] HYDRA_TOPO_DEBUG=1 needs a line break
by Kenneth Raffenetti 18 Nov '15

18 Nov '15

The newline is added after all the hwthreads are added to the string - line 469. You might be overrunning the max string length, as that is not well handled. Can you try doubling DBG_STR_LENGTH at the top of the file? Ken On 11/18/2015 09:09 AM, Jeff Hammond wrote: > I followed the example on > https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Exam… > but got a huge mess rather than the output shown on the Wiki. > > Is the lack of line break here intentional? I think it would be more > useful if it did. > > jhammond@nid00218:~/> HYDRA_TOPO_DEBUG=1 mpiexec -rmk slurm -n 8 > -bind-to core true > > process 0 binding: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 2 > binding: 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 3 binding: 0 0 0 1 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 5 binding: 0 0 0 0 0 1 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0process 6 binding: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0process 1 binding: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 4 > binding: 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 7 binding: 0 0 0 0 > 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0jhammond@nid00218:~/> > > The offending line appears to be 463 in > src/pm/hydra/tools/topo/hwloc/topo_hwloc.c, but I don't know if the "\n" > goes there or in the definition of HYDU_snprintf. > > Thanks, > > Jeff > > -- > 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

HYDRA_TOPO_DEBUG=1 needs a line break
by Jeff Hammond 18 Nov '15

18 Nov '15

I followed the example on https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Exam… but got a huge mess rather than the output shown on the Wiki. Is the lack of line break here intentional? I think it would be more useful if it did. jhammond@nid00218:~/> HYDRA_TOPO_DEBUG=1 mpiexec -rmk slurm -n 8 -bind-to core true process 0 binding: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 2 binding: 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 3 binding: 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 5 binding: 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 6 binding: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 1 binding: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 4 binding: 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 7 binding: 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0jhammond@nid00218:~/> The offending line appears to be 463 in src/pm/hydra/tools/topo/hwloc/topo_hwloc.c, but I don't know if the "\n" goes there or in the definition of HYDU_snprintf. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

testsuite broken for out-of-place builds
by Jeff Hammond 11 Nov '15

11 Nov '15

I filed https://trac.mpich.org/projects/mpich/ticket/2313 for this. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

../../coll/alltoall1.c:11:25: fatal error: mpicolltest.h: No such file or directory
by Jeff Hammond 10 Nov '15

10 Nov '15

I tried to build the MPICH test suite with Intel MPI and it fails here: ../../coll/alltoall1.c:11:25: fatal error: mpicolltest.h: No such file or directory I got here by doing "make dist" in the test/mpi directory of the 3.2rc2 build and then unpacking the tarball mpich-testsuite-3.2rc2.tgz in a separate directory. Since I can find this file in the test tree, I think it is just missing from the "make dist" export list. [jrhammo@bowman-rps build-impi]$ find ~/MPICH/git/ -name mpicolltest.h /storage/home_intel/jrhammo/MPICH/git/test/mpi/include/mpicolltest.h Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] autogen.sh libtool version mismatch
by Kenneth Raffenetti 10 Nov '15

10 Nov '15

On 11/10/2015 11:46 AM, Rob Latham wrote: > > > On 11/10/2015 11:29 AM, Kenneth Raffenetti wrote: >> Looks to be specific to the 2.4.3 tarball, which has an unexpected >> LT_PACKAGE_VERSION (2.4.2.458.26-92994) in m4/ltversion.m4. We can >> either put in a workaround or just bump the requirement in the next >> release. >> >> Thanks for reporting. > > can you make 2.4.2.458.26-92994 the lowest working number or is that > string too goofy to easily parse? This was my thought as a workaround. Local tests indicate it will work. Either way, we'll jam in a fix after the release. Ken > > ==rob >> >> Ken >> >> On 11/10/2015 08:54 AM, Jeff Hammond wrote: >>> autogen.sh fails because it says I need "version 2.4.3 or higher >>> required", but I have version 2.4.3 (see below). i upgraded to 2.4.6 >>> and the problem went away. >>> >>> Anyways, this isn't a blocker but it seems to be weird logic that it >>> happens. >>> >>> Jeff >>> >>> [jrhammo@bowman-rps git]$ ./autogen.sh >>> >>> >>> #################################### >>> >>> ## Replicating confdb (and similar) >>> >>> #################################### >>> >>> >>> syncing 'src/mpl' --> 'src/pm/hydra/mpl' >>> >>> syncing 'confdb' --> 'src/mpi/romio/confdb' >>> >>> syncing 'confdb' --> 'src/mpl/confdb' >>> >>> syncing 'confdb' --> 'src/pm/hydra/confdb' >>> >>> syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' >>> >>> syncing 'confdb' --> 'test/mpi/confdb' >>> >>> >>> #################################### >>> >>> ## Checking user environment >>> >>> #################################### >>> >>> >>> Verifying the location of autogen.sh... done >>> >>> Checking if autotools are in the same location... yes, all in >>> /storage/home_intel/jrhammo/TOOLS >>> >>> Checking for autoconf version... >= 2.67 >>> >>> Checking for automake version... >= 1.15 >>> >>> Checking for libtool version... bad libtool installation >>> >>> You either do not have libtool in your path or it is too old >>> >>> (version 2.4.3 or higher required). You may be able to use >>> >>> >>> libtool --version >>> >>> >>> Unfortunately, there is no standard format for the version output and >>> >>> it changes between autotools versions. In addition, some versions of >>> >>> autoconf choose among many versions and provide incorrect output). >>> >>> [jrhammo@bowman-rps git]$ libtool --version >>> >>> libtool (GNU libtool) 2.4.3 >>> >>> Written by Gordon Matzigkeit, 1996 >>> >>> >>> Copyright (C) 2014 Free Software Foundation, Inc. >>> >>> This is free software; see the source for copying conditions. There >>> is NO >>> >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>> PURPOSE. >>> >>> >>> -- >>> 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 >>> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] autogen.sh libtool version mismatch
by Rob Latham 10 Nov '15

10 Nov '15

On 11/10/2015 11:29 AM, Kenneth Raffenetti wrote: > Looks to be specific to the 2.4.3 tarball, which has an unexpected > LT_PACKAGE_VERSION (2.4.2.458.26-92994) in m4/ltversion.m4. We can > either put in a workaround or just bump the requirement in the next > release. > > Thanks for reporting. can you make 2.4.2.458.26-92994 the lowest working number or is that string too goofy to easily parse? ==rob > > Ken > > On 11/10/2015 08:54 AM, Jeff Hammond wrote: >> autogen.sh fails because it says I need "version 2.4.3 or higher >> required", but I have version 2.4.3 (see below). i upgraded to 2.4.6 >> and the problem went away. >> >> Anyways, this isn't a blocker but it seems to be weird logic that it >> happens. >> >> Jeff >> >> [jrhammo@bowman-rps git]$ ./autogen.sh >> >> >> #################################### >> >> ## Replicating confdb (and similar) >> >> #################################### >> >> >> syncing 'src/mpl' --> 'src/pm/hydra/mpl' >> >> syncing 'confdb' --> 'src/mpi/romio/confdb' >> >> syncing 'confdb' --> 'src/mpl/confdb' >> >> syncing 'confdb' --> 'src/pm/hydra/confdb' >> >> syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' >> >> syncing 'confdb' --> 'test/mpi/confdb' >> >> >> #################################### >> >> ## Checking user environment >> >> #################################### >> >> >> Verifying the location of autogen.sh... done >> >> Checking if autotools are in the same location... yes, all in >> /storage/home_intel/jrhammo/TOOLS >> >> Checking for autoconf version... >= 2.67 >> >> Checking for automake version... >= 1.15 >> >> Checking for libtool version... bad libtool installation >> >> You either do not have libtool in your path or it is too old >> >> (version 2.4.3 or higher required). You may be able to use >> >> >> libtool --version >> >> >> Unfortunately, there is no standard format for the version output and >> >> it changes between autotools versions. In addition, some versions of >> >> autoconf choose among many versions and provide incorrect output). >> >> [jrhammo@bowman-rps git]$ libtool --version >> >> libtool (GNU libtool) 2.4.3 >> >> Written by Gordon Matzigkeit, 1996 >> >> >> Copyright (C) 2014 Free Software Foundation, Inc. >> >> This is free software; see the source for copying conditions. There >> is NO >> >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> >> -- >> 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 >> > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] autogen.sh libtool version mismatch
by Jeff Hammond 10 Nov '15

10 Nov '15

Thanks. I'd just bump if were you. Patching for such a stupid thing doesn't make sense. Jeff Sent from my iPhone > On Nov 10, 2015, at 9:29 AM, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> wrote: > > Looks to be specific to the 2.4.3 tarball, which has an unexpected LT_PACKAGE_VERSION (2.4.2.458.26-92994) in m4/ltversion.m4. We can either put in a workaround or just bump the requirement in the next release. > > Thanks for reporting. > > Ken > >> On 11/10/2015 08:54 AM, Jeff Hammond wrote: >> autogen.sh fails because it says I need "version 2.4.3 or higher >> required", but I have version 2.4.3 (see below). i upgraded to 2.4.6 >> and the problem went away. >> >> Anyways, this isn't a blocker but it seems to be weird logic that it >> happens. >> >> Jeff >> >> [jrhammo@bowman-rps git]$ ./autogen.sh >> >> >> #################################### >> >> ## Replicating confdb (and similar) >> >> #################################### >> >> >> syncing 'src/mpl' --> 'src/pm/hydra/mpl' >> >> syncing 'confdb' --> 'src/mpi/romio/confdb' >> >> syncing 'confdb' --> 'src/mpl/confdb' >> >> syncing 'confdb' --> 'src/pm/hydra/confdb' >> >> syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' >> >> syncing 'confdb' --> 'test/mpi/confdb' >> >> >> #################################### >> >> ## Checking user environment >> >> #################################### >> >> >> Verifying the location of autogen.sh... done >> >> Checking if autotools are in the same location... yes, all in >> /storage/home_intel/jrhammo/TOOLS >> >> Checking for autoconf version... >= 2.67 >> >> Checking for automake version... >= 1.15 >> >> Checking for libtool version... bad libtool installation >> >> You either do not have libtool in your path or it is too old >> >> (version 2.4.3 or higher required). You may be able to use >> >> >> libtool --version >> >> >> Unfortunately, there is no standard format for the version output and >> >> it changes between autotools versions. In addition, some versions of >> >> autoconf choose among many versions and provide incorrect output). >> >> [jrhammo@bowman-rps git]$ libtool --version >> >> libtool (GNU libtool) 2.4.3 >> >> Written by Gordon Matzigkeit, 1996 >> >> >> Copyright (C) 2014 Free Software Foundation, Inc. >> >> This is free software; see the source for copying conditions. There is NO >> >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> >> -- >> 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 > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] autogen.sh libtool version mismatch
by Kenneth Raffenetti 10 Nov '15

10 Nov '15

Looks to be specific to the 2.4.3 tarball, which has an unexpected LT_PACKAGE_VERSION (2.4.2.458.26-92994) in m4/ltversion.m4. We can either put in a workaround or just bump the requirement in the next release. Thanks for reporting. Ken On 11/10/2015 08:54 AM, Jeff Hammond wrote: > autogen.sh fails because it says I need "version 2.4.3 or higher > required", but I have version 2.4.3 (see below). i upgraded to 2.4.6 > and the problem went away. > > Anyways, this isn't a blocker but it seems to be weird logic that it > happens. > > Jeff > > [jrhammo@bowman-rps git]$ ./autogen.sh > > > #################################### > > ## Replicating confdb (and similar) > > #################################### > > > syncing 'src/mpl' --> 'src/pm/hydra/mpl' > > syncing 'confdb' --> 'src/mpi/romio/confdb' > > syncing 'confdb' --> 'src/mpl/confdb' > > syncing 'confdb' --> 'src/pm/hydra/confdb' > > syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' > > syncing 'confdb' --> 'test/mpi/confdb' > > > #################################### > > ## Checking user environment > > #################################### > > > Verifying the location of autogen.sh... done > > Checking if autotools are in the same location... yes, all in > /storage/home_intel/jrhammo/TOOLS > > Checking for autoconf version... >= 2.67 > > Checking for automake version... >= 1.15 > > Checking for libtool version... bad libtool installation > > You either do not have libtool in your path or it is too old > > (version 2.4.3 or higher required). You may be able to use > > > libtool --version > > > Unfortunately, there is no standard format for the version output and > > it changes between autotools versions. In addition, some versions of > > autoconf choose among many versions and provide incorrect output). > > [jrhammo@bowman-rps git]$ libtool --version > > libtool (GNU libtool) 2.4.3 > > Written by Gordon Matzigkeit, 1996 > > > Copyright (C) 2014 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > -- > 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

autogen.sh libtool version mismatch
by Jeff Hammond 10 Nov '15

10 Nov '15

autogen.sh fails because it says I need "version 2.4.3 or higher required", but I have version 2.4.3 (see below). i upgraded to 2.4.6 and the problem went away. Anyways, this isn't a blocker but it seems to be weird logic that it happens. Jeff [jrhammo@bowman-rps git]$ ./autogen.sh #################################### ## Replicating confdb (and similar) #################################### syncing 'src/mpl' --> 'src/pm/hydra/mpl' syncing 'confdb' --> 'src/mpi/romio/confdb' syncing 'confdb' --> 'src/mpl/confdb' syncing 'confdb' --> 'src/pm/hydra/confdb' syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' syncing 'confdb' --> 'test/mpi/confdb' #################################### ## Checking user environment #################################### Verifying the location of autogen.sh... done Checking if autotools are in the same location... yes, all in /storage/home_intel/jrhammo/TOOLS Checking for autoconf version... >= 2.67 Checking for automake version... >= 1.15 Checking for libtool version... bad libtool installation You either do not have libtool in your path or it is too old (version 2.4.3 or higher required). You may be able to use libtool --version Unfortunately, there is no standard format for the version output and it changes between autotools versions. In addition, some versions of autoconf choose among many versions and provide incorrect output). [jrhammo@bowman-rps git]$ libtool --version libtool (GNU libtool) 2.4.3 Written by Gordon Matzigkeit, 1996 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] MPI_Dist_graph_create self-edge
by Daniel Ibanez 24 Oct '15

24 Oct '15

Rajeev, Thank you ! This was indeed a bug in my code that called Dist_graph_create, good thing I copied the resulting values exactly into the demo code. I should actually be specifying n=1 at all times for my application. Things are working as I expect now, sorry if I wasted someone's time. On Sat, Oct 24, 2015 at 9:32 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: > On rank 0, if you are passing n=2, shouldn’t the sources and degrees > arrays be of size 2? > > Rajeev > > > On Oct 24, 2015, at 6:37 PM, Daniel Ibanez <dan.a.ibanez(a)gmail.com> > wrote: > > > > Pavan, > > > > Here is a short program that reproduces the issue: > > > > > > > > #include <mpi.h> > > #include <assert.h> > > > > int main(int argc, char** argv) > > { > > MPI_Init(&argc, &argv); > > int size; > > MPI_Comm_size(MPI_COMM_WORLD, &size); > > assert(size == 2); > > int rank; > > MPI_Comm_rank(MPI_COMM_WORLD, &rank); > > MPI_Comm newcomm; > > if (rank == 0) { > > int sources[1] = {0}; > > int degrees[1] = {2}; > > int destinations[2] = {1,0}; > > int weights[2] = {2,1}; > > MPI_Dist_graph_create(MPI_COMM_WORLD, 2, sources, degrees, > destinations, > > weights, MPI_INFO_NULL, 0, &newcomm); > > } else { > > int sources[1] = {1}; > > int degrees[1] = {1}; > > int destinations[1] = {0}; > > int weights[1] = {2}; > > MPI_Dist_graph_create(MPI_COMM_WORLD, 1, sources, degrees, > destinations, > > weights, MPI_INFO_NULL, 0, &newcomm); > > } > > MPI_Comm_free(&newcomm); > > MPI_Finalize(); > > } > > > > > > > > > > Thanks, > > > > Dan > > > > On Sat, Oct 24, 2015 at 7:21 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > Daniel, > > > > Do you have a test program that shows these errors? > > > > The algorithms are a first cut, for now, but we are hoping to optimize > them in 2016 (together with one of our vendor partners, who will be > contributing code for it). > > > > Thanks, > > > > -- Pavan > > > > From: Daniel Ibanez <dan.a.ibanez(a)gmail.com> > > Reply-To: "devel(a)mpich.org" <devel(a)mpich.org> > > Date: Saturday, October 24, 2015 at 5:05 PM > > To: "devel(a)mpich.org" <devel(a)mpich.org> > > Subject: [mpich-devel] MPI_Dist_graph_create self-edge > > > > Hello, > > > > Using MPICH 3.1.4, I'm getting internal assertions of this kind > > of when using MPI_Dist_graph_create : > > > > Assertion failed in file src/mpi/topo/dist_gr_create.c at line 223: > s_rank >= 0 > > Assertion failed in file src/mpi/topo/dist_gr_create.c at line 195: > sources[i] < comm_size > > > > I've checked that ranks passed in are in the proper range, > > rather I think the issue is caused by requesting an edge > > from rank 0 to itself. > > (Another hint is that its non-deterministic which assertion > > I get; it depends on the order in which the ranks get scheduled > > by the OS, so there is a bit of a bug in the implementation, > > or at least no check for self-edges). > > > > Does the MPI standard allow for self-edges in these graphs ? > > > > Thank you, > > > > P.S. - I'll throw in a bigger question while I'm at it: are > > MPI_Dist_graph_create and MPI_Neighbor_alltoallv > > implemented with optimally scalable algorithms ? > > I'm betting my scalability on them being roughly > > O(log(P)) where P is communicator size, assuming > > neighborhood sizes and message sizes are constant. > > > > _______________________________________________ > > 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 > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0