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

Re: [petsc-dev] NumFOCUS affiliation?
by Jed Brown 10 Dec '19

10 Dec '19

https://gitlab.com/petsc/petsc/issues/511 "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: > Maybe we should make it a GitLab issue, we always finish GitLab issues promptly > > >> On Dec 10, 2019, at 11:22 AM, Jed Brown <jed(a)jedbrown.org> wrote: >> >> We made some first steps, but we/I dropped the ball on finishing the >> process. I'll pick it up over break. >> >> "Mills, Richard Tran" <rtmills(a)anl.gov> writes: >> >>> Fellow PETSc developers, >>> >>> I'm sitting in a session on open source software at the American >>> Geophysical Union meeting and there have been some mentions of NumFOCUS. >>> Which reminds me to ask: Did we ever do whatever was needed to become >>> NumFOCUS affiliated? I don't see PETSc on their list of affiliated or >>> sponsored projects. We even have PETSc and TAO logos that could go in >>> their list, so we should get PETSc/TAO in there. >>> >>> --Richard

1 0

Re: [petsc-dev] NumFOCUS affiliation?
by Smith, Barry F. 10 Dec '19

10 Dec '19

Maybe we should make it a GitLab issue, we always finish GitLab issues promptly > On Dec 10, 2019, at 11:22 AM, Jed Brown <jed(a)jedbrown.org> wrote: > > We made some first steps, but we/I dropped the ball on finishing the > process. I'll pick it up over break. > > "Mills, Richard Tran" <rtmills(a)anl.gov> writes: > >> Fellow PETSc developers, >> >> I'm sitting in a session on open source software at the American >> Geophysical Union meeting and there have been some mentions of NumFOCUS. >> Which reminds me to ask: Did we ever do whatever was needed to become >> NumFOCUS affiliated? I don't see PETSc on their list of affiliated or >> sponsored projects. We even have PETSc and TAO logos that could go in >> their list, so we should get PETSc/TAO in there. >> >> --Richard

1 0

Re: [petsc-dev] NumFOCUS affiliation?
by Jed Brown 10 Dec '19

10 Dec '19

We made some first steps, but we/I dropped the ball on finishing the process. I'll pick it up over break. "Mills, Richard Tran" <rtmills(a)anl.gov> writes: > Fellow PETSc developers, > > I'm sitting in a session on open source software at the American > Geophysical Union meeting and there have been some mentions of NumFOCUS. > Which reminds me to ask: Did we ever do whatever was needed to become > NumFOCUS affiliated? I don't see PETSc on their list of affiliated or > sponsored projects. We even have PETSc and TAO logos that could go in > their list, so we should get PETSc/TAO in there. > > --Richard

1 0

NumFOCUS affiliation?
by Mills, Richard Tran 10 Dec '19

10 Dec '19

Fellow PETSc developers, I'm sitting in a session on open source software at the American Geophysical Union meeting and there have been some mentions of NumFOCUS. Which reminds me to ask: Did we ever do whatever was needed to become NumFOCUS affiliated? I don't see PETSc on their list of affiliated or sponsored projects. We even have PETSc and TAO logos that could go in their list, so we should get PETSc/TAO in there. --Richard

1 0

Re: [petsc-dev] getting old branch
by Balay, Satish 10 Dec '19

10 Dec '19

All branches from bitbucket.org/petsc/petsc [now at bitbucket.org/petsc/petsc-pre-gitlab] should be available on gilab.com/petsc/petsc - [if it were not already merged to maint/master] So its strange.. Satish On Tue, 10 Dec 2019, Mark Adams wrote: > Nevermind, I figure it out, > > On Tue, Dec 10, 2019 at 8:19 AM Mark Adams <mfadams(a)lbl.gov> wrote: > > > I have a branch on bitbucket but its not on gilab. How do I get it? > > Thanks, > > Mark > > >

1 0

Re: [petsc-dev] getting old branch
by Mark Adams 10 Dec '19

10 Dec '19

Nevermind, I figure it out, On Tue, Dec 10, 2019 at 8:19 AM Mark Adams <mfadams(a)lbl.gov> wrote: > I have a branch on bitbucket but its not on gilab. How do I get it? > Thanks, > Mark >

1 0

getting old branch
by Mark Adams 10 Dec '19

10 Dec '19

I have a branch on bitbucket but its not on gilab. How do I get it? Thanks, Mark

1 0

Re: [petsc-dev] Valgrind problems
by Scott Kruger 08 Dec '19

08 Dec '19

Once MR!2329 is merged in, all of these test harness annoyances should be fixed. It wasn't a single issue, but rather a bunch of stdout/stderr and error code issues that were fixed in multiple MR's. Scott On 12/8/19 12:11 AM, Smith, Barry F. wrote: > > >> On Dec 7, 2019, at 6:00 PM, Matthew Knepley <knepley(a)gmail.com> wrote: >> >> Nope, you are right. >> >> Thanks, >> >> Matt >> >> On Sat, Dec 7, 2019 at 6:19 PM Balay, Satish <balay(a)mcs.anl.gov> wrote: >> The fix for this is in 363424266cb675e6465b4c7dcb06a6ff8acf57d2 >> >> Do you have this commit in your branch - and still seeing issues? >> >> Satish >> >> On Sat, 7 Dec 2019, Patrick Sanan wrote: >> >>> I was actually wondering about this, as in some cases valgrind errors appear and sometimes they don't, but I didn't dig into it too deeply. >>> >>> Here's my workaround, FWIW, which shows some output for that test on master. >>> >>> I don't see any output when I just run the tests like this: >>> >>> VALGRIND=1 make -f gmakefile.test test globsearch="dm_impls_plex_tests-ex1_fluent_2" >>> >>> But I do see something if I do this to find any non-empty .err files: >>> >>> find $PETSC_ARCH/tests -name *.err ! -size 0 >>> >>> And then I see these valgrind warnings after copy-pasting the path: > > This is really bad. Perhaps it is now fixed in master but obviously it crucial that all errors and valgrind errors are always visible in logging, otherwise we drive ourselves nuts chasing ghosts. > > Barry > > > > >>> >>> >>> $ cat arch-master-extra-opt/tests/dm/impls/plex/examples/tests/runex1_fluent_2/runex1_fluent_2.err >>> ==4990== Conditional jump or move depends on uninitialised value(s) >>> ==4990== at 0x4C3705A: rawmemchr (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) >>> ==4990== by 0x7687351: _IO_str_init_static_internal (strops.c:41) >>> ==4990== by 0x767878C: vsscanf (iovsscanf.c:40) >>> ==4990== by 0x76721A3: sscanf (sscanf.c:32) >>> ==4990== by 0x588147D: DMPlexCreateFluent_ReadSection (plexfluent.c:105) >>> ==4990== by 0x5882E3A: DMPlexCreateFluent (plexfluent.c:246) >>> ==4990== by 0x588492F: DMPlexCreateFluentFromFile (plexfluent.c:30) >>> ==4990== by 0x577E2B7: DMPlexCreateFromFile (plexcreate.c:3254) >>> ==4990== by 0x10BEDF: CreateMesh (ex1.c:170) >>> ==4990== by 0x10A20B: main (ex1.c:430) >>> ==4990== Uninitialised value was created by a stack allocation >>> ==4990== at 0x5881313: DMPlexCreateFluent_ReadSection (plexfluent.c:96) >>> ==4990== >>> ==4990== Use of uninitialised value of size 8 >>> ==4990== at 0x766276F: _IO_vfscanf (vfscanf.c:633) >>> ==4990== by 0x767879C: vsscanf (iovsscanf.c:41) >>> ==4990== by 0x76721A3: sscanf (sscanf.c:32) >>> ==4990== by 0x588147D: DMPlexCreateFluent_ReadSection (plexfluent.c:105) >>> ==4990== by 0x5882E3A: DMPlexCreateFluent (plexfluent.c:246) >>> ==4990== by 0x588492F: DMPlexCreateFluentFromFile (plexfluent.c:30) >>> ==4990== by 0x577E2B7: DMPlexCreateFromFile (plexcreate.c:3254) >>> ==4990== by 0x10BEDF: CreateMesh (ex1.c:170) >>> ==4990== by 0x10A20B: main (ex1.c:430) >>> ==4990== Uninitialised value was created by a stack allocation >>> ==4990== at 0x5881313: DMPlexCreateFluent_ReadSection (plexfluent.c:96) >>> ==4990== >>> ==4990== Conditional jump or move depends on uninitialised value(s) >>> ==4990== at 0x766277B: _IO_vfscanf (vfscanf.c:630) >>> ==4990== by 0x767879C: vsscanf (iovsscanf.c:41) >>> ==4990== by 0x76721A3: sscanf (sscanf.c:32) >>> ==4990== by 0x588147D: DMPlexCreateFluent_ReadSection (plexfluent.c:105) >>> ==4990== by 0x5882E3A: DMPlexCreateFluent (plexfluent.c:246) >>> ==4990== by 0x588492F: DMPlexCreateFluentFromFile (plexfluent.c:30) >>> ==4990== by 0x577E2B7: DMPlexCreateFromFile (plexcreate.c:3254) >>> ==4990== by 0x10BEDF: CreateMesh (ex1.c:170) >>> ==4990== by 0x10A20B: main (ex1.c:430) >>> ==4990== Uninitialised value was created by a stack allocation >>> ==4990== at 0x5881313: DMPlexCreateFluent_ReadSection (plexfluent.c:96) >>> ==4990== >>>> Am 07.12.2019 um 21:45 schrieb Matthew Knepley <knepley(a)gmail.com>: >>>> >>>> I am trying to clean up valgrind errors. However this one >>>> >>>> dm_impls_plex_tests-ex1_fluent_2 >>>> >>>> is valgrind clean on my machine. Does anyone get it to output something? >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> -- >>>> 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/> >>> >>> >> >> >> >> -- >> 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/ > -- Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 974-1841 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] Valgrind problems
by Smith, Barry F. 08 Dec '19

08 Dec '19

> On Dec 7, 2019, at 6:00 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > Nope, you are right. > > Thanks, > > Matt > > On Sat, Dec 7, 2019 at 6:19 PM Balay, Satish <balay(a)mcs.anl.gov> wrote: > The fix for this is in 363424266cb675e6465b4c7dcb06a6ff8acf57d2 > > Do you have this commit in your branch - and still seeing issues? > > Satish > > On Sat, 7 Dec 2019, Patrick Sanan wrote: > > > I was actually wondering about this, as in some cases valgrind errors appear and sometimes they don't, but I didn't dig into it too deeply. > > > > Here's my workaround, FWIW, which shows some output for that test on master. > > > > I don't see any output when I just run the tests like this: > > > > VALGRIND=1 make -f gmakefile.test test globsearch="dm_impls_plex_tests-ex1_fluent_2" > > > > But I do see something if I do this to find any non-empty .err files: > > > > find $PETSC_ARCH/tests -name *.err ! -size 0 > > > > And then I see these valgrind warnings after copy-pasting the path: This is really bad. Perhaps it is now fixed in master but obviously it crucial that all errors and valgrind errors are always visible in logging, otherwise we drive ourselves nuts chasing ghosts. Barry > > > > > > $ cat arch-master-extra-opt/tests/dm/impls/plex/examples/tests/runex1_fluent_2/runex1_fluent_2.err > > ==4990== Conditional jump or move depends on uninitialised value(s) > > ==4990== at 0x4C3705A: rawmemchr (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > > ==4990== by 0x7687351: _IO_str_init_static_internal (strops.c:41) > > ==4990== by 0x767878C: vsscanf (iovsscanf.c:40) > > ==4990== by 0x76721A3: sscanf (sscanf.c:32) > > ==4990== by 0x588147D: DMPlexCreateFluent_ReadSection (plexfluent.c:105) > > ==4990== by 0x5882E3A: DMPlexCreateFluent (plexfluent.c:246) > > ==4990== by 0x588492F: DMPlexCreateFluentFromFile (plexfluent.c:30) > > ==4990== by 0x577E2B7: DMPlexCreateFromFile (plexcreate.c:3254) > > ==4990== by 0x10BEDF: CreateMesh (ex1.c:170) > > ==4990== by 0x10A20B: main (ex1.c:430) > > ==4990== Uninitialised value was created by a stack allocation > > ==4990== at 0x5881313: DMPlexCreateFluent_ReadSection (plexfluent.c:96) > > ==4990== > > ==4990== Use of uninitialised value of size 8 > > ==4990== at 0x766276F: _IO_vfscanf (vfscanf.c:633) > > ==4990== by 0x767879C: vsscanf (iovsscanf.c:41) > > ==4990== by 0x76721A3: sscanf (sscanf.c:32) > > ==4990== by 0x588147D: DMPlexCreateFluent_ReadSection (plexfluent.c:105) > > ==4990== by 0x5882E3A: DMPlexCreateFluent (plexfluent.c:246) > > ==4990== by 0x588492F: DMPlexCreateFluentFromFile (plexfluent.c:30) > > ==4990== by 0x577E2B7: DMPlexCreateFromFile (plexcreate.c:3254) > > ==4990== by 0x10BEDF: CreateMesh (ex1.c:170) > > ==4990== by 0x10A20B: main (ex1.c:430) > > ==4990== Uninitialised value was created by a stack allocation > > ==4990== at 0x5881313: DMPlexCreateFluent_ReadSection (plexfluent.c:96) > > ==4990== > > ==4990== Conditional jump or move depends on uninitialised value(s) > > ==4990== at 0x766277B: _IO_vfscanf (vfscanf.c:630) > > ==4990== by 0x767879C: vsscanf (iovsscanf.c:41) > > ==4990== by 0x76721A3: sscanf (sscanf.c:32) > > ==4990== by 0x588147D: DMPlexCreateFluent_ReadSection (plexfluent.c:105) > > ==4990== by 0x5882E3A: DMPlexCreateFluent (plexfluent.c:246) > > ==4990== by 0x588492F: DMPlexCreateFluentFromFile (plexfluent.c:30) > > ==4990== by 0x577E2B7: DMPlexCreateFromFile (plexcreate.c:3254) > > ==4990== by 0x10BEDF: CreateMesh (ex1.c:170) > > ==4990== by 0x10A20B: main (ex1.c:430) > > ==4990== Uninitialised value was created by a stack allocation > > ==4990== at 0x5881313: DMPlexCreateFluent_ReadSection (plexfluent.c:96) > > ==4990== > > > Am 07.12.2019 um 21:45 schrieb Matthew Knepley <knepley(a)gmail.com>: > > > > > > I am trying to clean up valgrind errors. However this one > > > > > > dm_impls_plex_tests-ex1_fluent_2 > > > > > > is valgrind clean on my machine. Does anyone get it to output something? > > > > > > Thanks, > > > > > > Matt > > > > > > -- > > > 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/> > > > > > > > > -- > 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/

1 0

Re: [petsc-dev] Valgrind problems
by Matthew Knepley 07 Dec '19

07 Dec '19

Nope, you are right. Thanks, Matt On Sat, Dec 7, 2019 at 6:19 PM Balay, Satish <balay(a)mcs.anl.gov> wrote: > The fix for this is in 363424266cb675e6465b4c7dcb06a6ff8acf57d2 > > Do you have this commit in your branch - and still seeing issues? > > Satish > > On Sat, 7 Dec 2019, Patrick Sanan wrote: > > > I was actually wondering about this, as in some cases valgrind errors > appear and sometimes they don't, but I didn't dig into it too deeply. > > > > Here's my workaround, FWIW, which shows some output for that test on > master. > > > > I don't see any output when I just run the tests like this: > > > > VALGRIND=1 make -f gmakefile.test test > globsearch="dm_impls_plex_tests-ex1_fluent_2" > > > > But I do see something if I do this to find any non-empty .err files: > > > > find $PETSC_ARCH/tests -name *.err ! -size 0 > > > > And then I see these valgrind warnings after copy-pasting the path: > > > > > > $ cat > arch-master-extra-opt/tests/dm/impls/plex/examples/tests/runex1_fluent_2/runex1_fluent_2.err > > ==4990== Conditional jump or move depends on uninitialised value(s) > > ==4990== at 0x4C3705A: rawmemchr (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > > ==4990== by 0x7687351: _IO_str_init_static_internal (strops.c:41) > > ==4990== by 0x767878C: vsscanf (iovsscanf.c:40) > > ==4990== by 0x76721A3: sscanf (sscanf.c:32) > > ==4990== by 0x588147D: DMPlexCreateFluent_ReadSection > (plexfluent.c:105) > > ==4990== by 0x5882E3A: DMPlexCreateFluent (plexfluent.c:246) > > ==4990== by 0x588492F: DMPlexCreateFluentFromFile (plexfluent.c:30) > > ==4990== by 0x577E2B7: DMPlexCreateFromFile (plexcreate.c:3254) > > ==4990== by 0x10BEDF: CreateMesh (ex1.c:170) > > ==4990== by 0x10A20B: main (ex1.c:430) > > ==4990== Uninitialised value was created by a stack allocation > > ==4990== at 0x5881313: DMPlexCreateFluent_ReadSection > (plexfluent.c:96) > > ==4990== > > ==4990== Use of uninitialised value of size 8 > > ==4990== at 0x766276F: _IO_vfscanf (vfscanf.c:633) > > ==4990== by 0x767879C: vsscanf (iovsscanf.c:41) > > ==4990== by 0x76721A3: sscanf (sscanf.c:32) > > ==4990== by 0x588147D: DMPlexCreateFluent_ReadSection > (plexfluent.c:105) > > ==4990== by 0x5882E3A: DMPlexCreateFluent (plexfluent.c:246) > > ==4990== by 0x588492F: DMPlexCreateFluentFromFile (plexfluent.c:30) > > ==4990== by 0x577E2B7: DMPlexCreateFromFile (plexcreate.c:3254) > > ==4990== by 0x10BEDF: CreateMesh (ex1.c:170) > > ==4990== by 0x10A20B: main (ex1.c:430) > > ==4990== Uninitialised value was created by a stack allocation > > ==4990== at 0x5881313: DMPlexCreateFluent_ReadSection > (plexfluent.c:96) > > ==4990== > > ==4990== Conditional jump or move depends on uninitialised value(s) > > ==4990== at 0x766277B: _IO_vfscanf (vfscanf.c:630) > > ==4990== by 0x767879C: vsscanf (iovsscanf.c:41) > > ==4990== by 0x76721A3: sscanf (sscanf.c:32) > > ==4990== by 0x588147D: DMPlexCreateFluent_ReadSection > (plexfluent.c:105) > > ==4990== by 0x5882E3A: DMPlexCreateFluent (plexfluent.c:246) > > ==4990== by 0x588492F: DMPlexCreateFluentFromFile (plexfluent.c:30) > > ==4990== by 0x577E2B7: DMPlexCreateFromFile (plexcreate.c:3254) > > ==4990== by 0x10BEDF: CreateMesh (ex1.c:170) > > ==4990== by 0x10A20B: main (ex1.c:430) > > ==4990== Uninitialised value was created by a stack allocation > > ==4990== at 0x5881313: DMPlexCreateFluent_ReadSection > (plexfluent.c:96) > > ==4990== > > > Am 07.12.2019 um 21:45 schrieb Matthew Knepley <knepley(a)gmail.com>: > > > > > > I am trying to clean up valgrind errors. However this one > > > > > > dm_impls_plex_tests-ex1_fluent_2 > > > > > > is valgrind clean on my machine. Does anyone get it to output > something? > > > > > > Thanks, > > > > > > Matt > > > > > > -- > > > 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/> > > > > > > -- 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