February 2019 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Man pages usage of "Collective on XXX"
by Smith, Barry F. 06 Feb '19

06 Feb '19

> On Feb 6, 2019, at 2:01 PM, Dave May via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > > * I notice that most man pages will say > Collective on <type> > e.g. > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMDA/DMDACreat… > > * Some others say > Collective on <implementation-name> > > e.g. > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMDA/DMDACreat… > > or > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMComposite… > > In the former, at least the word "DMDA" gets linked back to the implementation, whilst in the latter "DMComposite" does not. > > Should "Collective on <implementation-name>" be avoided? Yeah, the above two examples are just wrong (probably inherited from before DM was a fully defined object). In both these cases they are collective on DA > It is potentially somewhat unclear given that the name of the implementation does not appear anywhere in the arg list (type or variable name). > > That said, "collective on <type>" could be similarly criticized if a method existed with two args of the same type. > > * Many of the methods in this file > > www.mcs.anl.gov/petsc/petsc-current/src/dm/impls/shell/dmshell.c.html > > simply say "Collective" (without a type or implementation name), or they say "Logically Collective on XXX" No page should just say collective. > > I do realize that there is a pattern that the statement "collective on xxx" or "not collective" applies (implicitly) to the first argument of any PETSc function call (at least that I've come across) so possibly just indicating the method as "Collective" might suffice (assuming (i) there is a pattern and (ii) everyone knows about the pattern). > > Q: Should I make a PR to unify these man pages (and any others I spot) to just say "Collective on <type>"? That would be fine. So there are two possibilities Collective on XXX or Logically Collective on XXX > > > Thanks, > Dave > >

1 0

Re: [petsc-dev] Man pages usage of "Collective on XXX"
by Matthew Knepley 06 Feb '19

06 Feb '19

On Wed, Feb 6, 2019 at 3:03 PM Dave May via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: > * I notice that most man pages will say > Collective on <type> > e.g. > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMDA/DMDACreat… > > * Some others say > Collective on <implementation-name> > > e.g. > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMDA/DMDACreat… > > or > > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMComposite… > > In the former, at least the word "DMDA" gets linked back to the > implementation, whilst in the latter "DMComposite" does not. > > Should "Collective on <implementation-name>" be avoided? > It is potentially somewhat unclear given that the name of the > implementation does not appear anywhere in the arg list (type or variable > name). > > That said, "collective on <type>" could be similarly criticized if a > method existed with two args of the same type. > > * Many of the methods in this file > > www.mcs.anl.gov/petsc/petsc-current/src/dm/impls/shell/dmshell.c.html > > simply say "Collective" (without a type or implementation name), or they > say "Logically Collective on XXX" > > I do realize that there is a pattern that the statement "collective on > xxx" or "not collective" applies (implicitly) to the first argument of any > PETSc function call (at least that I've come across) so possibly just > indicating the method as "Collective" might suffice (assuming (i) there is > a pattern and (ii) everyone knows about the pattern). > > Q: Should I make a PR to unify these man pages (and any others I spot) to > just say "Collective on <type>"? > This has always bugged me. It should say, I think, 'Collective on <arg name>", or "Logically collective on <arg name>". Thanks, Matt > Thanks, > Dave > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Man pages usage of "Collective on XXX"
by Dave May 06 Feb '19

06 Feb '19

* I notice that most man pages will say Collective on <type> e.g. https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMDA/DMDACreat… * Some others say Collective on <implementation-name> e.g. https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMDA/DMDACreat… or https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMComposite… In the former, at least the word "DMDA" gets linked back to the implementation, whilst in the latter "DMComposite" does not. Should "Collective on <implementation-name>" be avoided? It is potentially somewhat unclear given that the name of the implementation does not appear anywhere in the arg list (type or variable name). That said, "collective on <type>" could be similarly criticized if a method existed with two args of the same type. * Many of the methods in this file www.mcs.anl.gov/petsc/petsc-current/src/dm/impls/shell/dmshell.c.html simply say "Collective" (without a type or implementation name), or they say "Logically Collective on XXX" I do realize that there is a pattern that the statement "collective on xxx" or "not collective" applies (implicitly) to the first argument of any PETSc function call (at least that I've come across) so possibly just indicating the method as "Collective" might suffice (assuming (i) there is a pattern and (ii) everyone knows about the pattern). Q: Should I make a PR to unify these man pages (and any others I spot) to just say "Collective on <type>"? Thanks, Dave

1 0

Re: [petsc-dev] parallel partitioning of uninterpolated meshes not supported
by Hapla Vaclav 06 Feb '19

06 Feb '19

Bump - is this question too complex or too stupid? :-) I'm now looking again on tests which are still failing in knepley/fix-plex-interpolate-sf-new. There are several ones failing with Parallel partitioning of uninterpolated meshes not supported So I'll just remove them for now. One test (m_impls_plex_tests-ex18_2b) is failing just because of diff. I'll just check if the current output is correct and update the output file. But these three dm_impls_plex_tests-ex18_6_tet_nsize-4interpolate-parallel_faces-2,2,2 dm_impls_plex_tests-ex18_6_tet_nsize-4interpolate-parallel_faces-1,3,5 dm_impls_plex_tests-ex18_6_tet_nsize-4interpolate-parallel_faces-3,4,7 fail with point SF contains X but not Y from its cone Can it also be a problem of partitioning, and not interpolation? So should we just for now disable ctetgen without interpolation and remove those tests? If it is the case, knepley/fix-plex-interpolate-sf-new should be merged soon, just after removing the failing tests. Thanks Vaclav On 31 Jan 2019, at 15:33, Hapla Vaclav <vaclav.hapla(a)erdw.ethz.ch<mailto:[email protected]>> wrote: Matt, your commit https://bitbucket.org/petsc/petsc/commits/ffbd61634109cd55a4e1889a4f100c5a1… says Parallel partitioning of uninterpolated meshes not supported. So should I now take it as a not-yet-implemented feature? Does it really concern only this order of operations? 1) load sequentially 2) distribute 3) redistribute in parallel 4) interpolate in parallel So the following three use cases I) 1) load sequentially 2) interpolate sequentially 3) distribute 4) redistribute in parallel II) 1) load sequntially 2) distribute 3) interpolate in parallel 4) redistribute in parallel III) 1) load in parallel 2) interpolate in parallel 3) redistribute in parallel can still be considered supported in general? I mean not regarding the issues with the SF which still seem to affect parallel interpolation (https://bitbucket.org/petsc/petsc/branch/knepley/fix-plex-interpolate-sf) BTW I now rebased this branch onto master as <https://bitbucket.org/petsc/petsc/branch/knepley/fix-plex-interpolate-sf-new> https://bitbucket.org/petsc/petsc/branch/knepley/fix-plex-interpolate-sf-new and it now needs to take that not-yet-implemented feature into account - I will update it and remind to me what cases are still failing. Thanks in advance for clarification! Vaclav

1 0

Re: [petsc-dev] patch for wrong integer type
by Fabian.Jakub 05 Feb '19

05 Feb '19

That should do. Thanks to all of you. Cheers, Fabian On 2/5/19 7:04 AM, Karl Rupp wrote: > Hi Fabian, > > I just merged the patch to master and maint. Please let us know whether > this solves the issue. > > Best regards, > Karli > > > On 2/4/19 8:51 PM, Matthew Knepley via petsc-dev wrote: >> On Mon, Feb 4, 2019 at 2:42 PM Fabian.Jakub via petsc-dev >> <petsc-dev(a)mcs.anl.gov <mailto:[email protected]>> wrote: >> >> Dear Petsc Team, >> >> I recently had segfaults when dumping DMPlexs through the >> PetscObjectViewer into hdf5 files >> >> This happens to me with 64 bit integers and I think there is a >> PetscInt >> where an int should be placed. >> >> >> Thanks! I think Vaclav caught this last week >> >> https://bitbucket.org/petsc/petsc/commits/15b861d2d1f810846f37f539a33922bed… >> >> >> Should be merged soon. >> >> Matt >> >> Please have a look at the attached patch. >> >> Yours, >> >> Fabian >> >> >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which >> their experiments lead. >> -- Norbert Wiener >> >> https://www.cse.buffalo.edu/~knepley/ >> <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] patch for wrong integer type
by Karl Rupp 05 Feb '19

05 Feb '19

Hi Fabian, I just merged the patch to master and maint. Please let us know whether this solves the issue. Best regards, Karli On 2/4/19 8:51 PM, Matthew Knepley via petsc-dev wrote: > On Mon, Feb 4, 2019 at 2:42 PM Fabian.Jakub via petsc-dev > <petsc-dev(a)mcs.anl.gov <mailto:[email protected]>> wrote: > > Dear Petsc Team, > > I recently had segfaults when dumping DMPlexs through the > PetscObjectViewer into hdf5 files > > This happens to me with 64 bit integers and I think there is a PetscInt > where an int should be placed. > > > Thanks! I think Vaclav caught this last week > > https://bitbucket.org/petsc/petsc/commits/15b861d2d1f810846f37f539a33922bed… > > Should be merged soon. > > Matt > > Please have a look at the attached patch. > > Yours, > > Fabian > > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which > their experiments lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] cray warning - reduction in alignment ignored
by Smith, Barry F. 04 Feb '19

04 Feb '19

Hmm, I looked at the docs and the aligned just specifies a minimum alignment (the compile could possibly use a larger alignment) So I am not sure why we even use it; but I do know that the code did not work "somewhere" without that attribute. Presumably the warning message is somewhat "silly" if it is truly a minimum value because the compiler is free to use a larger value it does not need to provide a warning that it is using a larger value. I guess for now we just "let it go", I don't see any other useful way to proceed (though having any confusing warning messages from compilers is never desirable). Barry > On Feb 4, 2019, at 8:39 AM, Hapla Vaclav <vaclav.hapla(a)erdw.ethz.ch> wrote: > > Barry, I realized the problem appeared because of --with-precision=single. Without that the warnings disappeared. Maybe DMNetwork code should be completely disabled for single (all tests actually require double)? Or is it expected to work fine with single on other archs? > > I also wanted to run the tests but apparently test harness doesn't work with --with-batch > # /scratch/snx3000/haplav/petsc/config/petsc_harness.sh: line 123: Not_appropriate_for_batch_systems_You_must_use_your_batch_system_to_submit_MPI_jobs_speak_with_your_local_sys_admin: command not found > > But running some examples manually, they look fine: > > /scratch/snx3000/haplav/petsc/src/ksp/ksp/examples/tutorials/network>srun -n 2 ./ex1_nest > Vec Object: 2 MPI processes > type: mpi > Process [0] > Edge 0: > -1. > Edge 1: > 7. > Edge 2: > -4. > Process [1] > Edge 3: > -2. > Edge 4: > -1. > Edge 5: > 3. > Vertex 0: > -2. > Vertex 1: > -1. > Vertex 2: > 3. > Vertex 3: > 0. > > > /scratch/snx3000/haplav/petsc/src/snes/examples/tutorials/network/power>srun ./power -snes_rtol 1.e-3 > nb = 9, ngen = 3, nload = 3, nbranch = 9 > Nonlinear solve converged due to CONVERGED_FNORM_RELATIVE iterations 3 > > > > Vaclav > > >> On 1 Feb 2019, at 19:43, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: >> >> >> I cannot remember why it is sizeof(PetscScalar) specifically. I do remember that having an alignment is crucial to DMNetwork and it can fail and crash if there is no alignment. So it is possible that the code will not work with the Cray compilers. >> >> The attribute is checked in config/PETSc/configure.py; my guess is that since Cray is producing only a warning the configure check is saying that the attribute exists which maybe wrong in this situation. Can you take a look at the configure.log and see what it is reporting, or email it? >> >> My wild guess is that we should be turning off the attribute (during the configure process) for the Cray compiler to prevent generating bad code and crashing at run time. You could check if the DMNetwork code (possibly) works correctly with the Cray compiler by running the tests: >> >> src/ksp/ksp/examples/tutorials/network/ex1.c: requires: !complex double define(PETSC_HAVE_ATTRIBUTEALIGNED) >> src/ksp/ksp/examples/tutorials/network/ex1_nest.c: requires: !complex double define(PETSC_HAVE_ATTRIBUTEALIGNED) >> src/ksp/ksp/examples/tutorials/network/ex2.c: requires: !single double define(PETSC_HAVE_ATTRIBUTEALIGNED) >> src/ksp/ksp/examples/tutorials/network/makefile:#requiresdefine 'PETSC_HAVE_ATTRIBUTEALIGNED' >> src/snes/examples/tutorials/network/ex1.c: requires: !complex double define(PETSC_HAVE_ATTRIBUTEALIGNED) >> src/snes/examples/tutorials/network/ex1.c: requires: double !complex define(PETSC_HAVE_ATTRIBUTEALIGNED) >> src/snes/examples/tutorials/network/ex1.c: requires: double !complex define(PETSC_HAVE_ATTRIBUTEALIGNED) >> src/snes/examples/tutorials/network/makefile:#requiresdefine 'PETSC_HAVE_ATTRIBUTEALIGNED' >> src/snes/examples/tutorials/network/power/makefile:#requiresdefine 'PETSC_HAVE_ATTRIBUTEALIGNED' >> src/snes/examples/tutorials/network/power/power.c: requires: !complex double define(PETSC_HAVE_ATTRIBUTEALIGNED) >> src/snes/examples/tutorials/network/power/power.c: requires: double !complex define(PETSC_HAVE_ATTRIBUTEALIGNED) >> src/snes/examples/tutorials/network/power/power.c: requires: double !complex define(PETSC_HAVE_ATTRIBUTEALIGNED) >> src/snes/examples/tutorials/network/power/power.h:} PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); >> src/snes/examples/tutorials/network/power/power.h:} PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); >> src/snes/examples/tutorials/network/power/power.h:} PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); >> src/snes/examples/tutorials/network/power/power.h:} PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); >> >> Thanks >> >> Barry >> >> >> >> >>> On Feb 1, 2019, at 11:47 AM, Hapla Vaclav via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: >>> >>> I've got this with Cray compiler >>> >>> CC arch-daint-cray-opt/obj/dm/impls/network/network.o >>> CC-1160 craycc: WARNING File = /scratch/snx3000/haplav/petsc/include/petsc/private/dmnetworkimpl.h, Line = 20 >>> A reduction in alignment is ignored. >>> } PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); >>> ^ >>> >>> CC-1160 craycc: WARNING File = /scratch/snx3000/haplav/petsc/include/petsc/private/dmnetworkimpl.h, Line = 25 >>> A reduction in alignment is ignored. >>> } PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); >>> ^ >>> >>> Cray C : Version 8.7.3 (20180718184853_d127f1e88e6a577c0c4f008444940f2bcded38e8) >>> Total warnings detected in /scratch/snx3000/haplav/petsc/src/dm/impls/network/network.c: 2 >>> >>> >>> Is it something fixable? >>> >>> Thanks >>> >>> Vaclav >> >

1 0

Re: [petsc-dev] patch for wrong integer type
by Matthew Knepley 04 Feb '19

04 Feb '19

On Mon, Feb 4, 2019 at 2:42 PM Fabian.Jakub via petsc-dev < petsc-dev(a)mcs.anl.gov> wrote: > Dear Petsc Team, > > I recently had segfaults when dumping DMPlexs through the > PetscObjectViewer into hdf5 files > > This happens to me with 64 bit integers and I think there is a PetscInt > where an int should be placed. > Thanks! I think Vaclav caught this last week https://bitbucket.org/petsc/petsc/commits/15b861d2d1f810846f37f539a33922bed… Should be merged soon. Matt > Please have a look at the attached patch. > > Yours, > > Fabian > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

patch for wrong integer type
by Fabian.Jakub 04 Feb '19

04 Feb '19

Dear Petsc Team, I recently had segfaults when dumping DMPlexs through the PetscObjectViewer into hdf5 files This happens to me with 64 bit integers and I think there is a PetscInt where an int should be placed. Please have a look at the attached patch. Yours, Fabian

1 0

Re: [petsc-dev] cray warning - reduction in alignment ignored
by Hapla Vaclav 04 Feb '19

04 Feb '19

Barry, I realized the problem appeared because of --with-precision=single. Without that the warnings disappeared. Maybe DMNetwork code should be completely disabled for single (all tests actually require double)? Or is it expected to work fine with single on other archs? I also wanted to run the tests but apparently test harness doesn't work with --with-batch # /scratch/snx3000/haplav/petsc/config/petsc_harness.sh: line 123: Not_appropriate_for_batch_systems_You_must_use_your_batch_system_to_submit_MPI_jobs_speak_with_your_local_sys_admin: command not found But running some examples manually, they look fine: /scratch/snx3000/haplav/petsc/src/ksp/ksp/examples/tutorials/network>srun -n 2 ./ex1_nest Vec Object: 2 MPI processes type: mpi Process [0] Edge 0: -1. Edge 1: 7. Edge 2: -4. Process [1] Edge 3: -2. Edge 4: -1. Edge 5: 3. Vertex 0: -2. Vertex 1: -1. Vertex 2: 3. Vertex 3: 0. /scratch/snx3000/haplav/petsc/src/snes/examples/tutorials/network/power>srun ./power -snes_rtol 1.e-3 nb = 9, ngen = 3, nload = 3, nbranch = 9 Nonlinear solve converged due to CONVERGED_FNORM_RELATIVE iterations 3 Vaclav > On 1 Feb 2019, at 19:43, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > > I cannot remember why it is sizeof(PetscScalar) specifically. I do remember that having an alignment is crucial to DMNetwork and it can fail and crash if there is no alignment. So it is possible that the code will not work with the Cray compilers. > > The attribute is checked in config/PETSc/configure.py; my guess is that since Cray is producing only a warning the configure check is saying that the attribute exists which maybe wrong in this situation. Can you take a look at the configure.log and see what it is reporting, or email it? > > My wild guess is that we should be turning off the attribute (during the configure process) for the Cray compiler to prevent generating bad code and crashing at run time. You could check if the DMNetwork code (possibly) works correctly with the Cray compiler by running the tests: > > src/ksp/ksp/examples/tutorials/network/ex1.c: requires: !complex double define(PETSC_HAVE_ATTRIBUTEALIGNED) > src/ksp/ksp/examples/tutorials/network/ex1_nest.c: requires: !complex double define(PETSC_HAVE_ATTRIBUTEALIGNED) > src/ksp/ksp/examples/tutorials/network/ex2.c: requires: !single double define(PETSC_HAVE_ATTRIBUTEALIGNED) > src/ksp/ksp/examples/tutorials/network/makefile:#requiresdefine 'PETSC_HAVE_ATTRIBUTEALIGNED' > src/snes/examples/tutorials/network/ex1.c: requires: !complex double define(PETSC_HAVE_ATTRIBUTEALIGNED) > src/snes/examples/tutorials/network/ex1.c: requires: double !complex define(PETSC_HAVE_ATTRIBUTEALIGNED) > src/snes/examples/tutorials/network/ex1.c: requires: double !complex define(PETSC_HAVE_ATTRIBUTEALIGNED) > src/snes/examples/tutorials/network/makefile:#requiresdefine 'PETSC_HAVE_ATTRIBUTEALIGNED' > src/snes/examples/tutorials/network/power/makefile:#requiresdefine 'PETSC_HAVE_ATTRIBUTEALIGNED' > src/snes/examples/tutorials/network/power/power.c: requires: !complex double define(PETSC_HAVE_ATTRIBUTEALIGNED) > src/snes/examples/tutorials/network/power/power.c: requires: double !complex define(PETSC_HAVE_ATTRIBUTEALIGNED) > src/snes/examples/tutorials/network/power/power.c: requires: double !complex define(PETSC_HAVE_ATTRIBUTEALIGNED) > src/snes/examples/tutorials/network/power/power.h:} PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); > src/snes/examples/tutorials/network/power/power.h:} PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); > src/snes/examples/tutorials/network/power/power.h:} PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); > src/snes/examples/tutorials/network/power/power.h:} PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); > > Thanks > > Barry > > > > >> On Feb 1, 2019, at 11:47 AM, Hapla Vaclav via petsc-dev <petsc-dev(a)mcs.anl.gov> wrote: >> >> I've got this with Cray compiler >> >> CC arch-daint-cray-opt/obj/dm/impls/network/network.o >> CC-1160 craycc: WARNING File = /scratch/snx3000/haplav/petsc/include/petsc/private/dmnetworkimpl.h, Line = 20 >> A reduction in alignment is ignored. >> } PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); >> ^ >> >> CC-1160 craycc: WARNING File = /scratch/snx3000/haplav/petsc/include/petsc/private/dmnetworkimpl.h, Line = 25 >> A reduction in alignment is ignored. >> } PETSC_ATTRIBUTEALIGNED(sizeof(PetscScalar)); >> ^ >> >> Cray C : Version 8.7.3 (20180718184853_d127f1e88e6a577c0c4f008444940f2bcded38e8) >> Total warnings detected in /scratch/snx3000/haplav/petsc/src/dm/impls/network/network.c: 2 >> >> >> Is it something fixable? >> >> Thanks >> >> Vaclav >

1 0