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

Re: [petsc-dev] Who checked in...
by Matthew Knepley 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 11:36 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Feb 12, 2013 at 10:31 AM, Matthew Knepley <knepley(a)mcs.anl.gov>wrote: > >> On Tue, Feb 12, 2013 at 11:28 AM, Matthew Knepley <knepley(a)gmail.com>wrote: >> >>> src/sys/logging/stagelog.c??? >>> >>> This is the same name modulo capitalization as >>> >>> src/sys/logging/utils/stageLog.c >>> >> > I'll move it, but can we also downcase those file names? Aren't all source > files supposed to be lowercase? > Yes, we should have remembered to do it when we moved them but I was not paying attention. Matt > $ git ls-files 'src/*.[ch]' |grep [A-Z] > > src/benchmarks/Index.c > src/benchmarks/MPI_Wtime.c > src/benchmarks/PLogEvent.c > src/benchmarks/PetscGetCPUTime.c > src/benchmarks/PetscGetTime.c > src/benchmarks/PetscMalloc.c > src/benchmarks/PetscMemcmp.c > src/benchmarks/PetscMemcpy.c > src/benchmarks/PetscMemzero.c > src/benchmarks/PetscTime.c > src/benchmarks/PetscVecNorm.c > src/benchmarks/streams/BasicVersion.c > src/benchmarks/streams/BasicVersionNoMPI.c > src/benchmarks/streams/OpenMPVersion.c > src/benchmarks/streams/PthreadVersion.c > src/benchmarks/streams/SSEVersion.c > src/dm/impls/da/utils/binaryMatlab.c > src/dm/impls/mesh/examples/tests/TestMeshExodus.c > src/dm/impls/mesh/examples/tutorials/Coarsener.h > src/dm/impls/mesh/examples/tutorials/Hierarchy.h > src/ksp/ksp/examples/tutorials/ex43-solCx.h > src/ksp/ksp/impls/gmres/agmres/agmresDeflation.c > src/ksp/ksp/impls/gmres/agmres/agmresLeja.c > src/ksp/ksp/impls/python/pythonK.c > src/ksp/pc/impls/python/pythonP.c > src/snes/examples/tutorials/ex633D_DB.c > src/snes/examples/tutorials/ex653D.c > src/sys/logging/utils/classLog.c > src/sys/logging/utils/eventLog.c > src/sys/logging/utils/stageLog.c > src/sys/shell/examples/tests/testcomponentsI.c > src/sys/shell/examples/tests/testcomponentsII.c > > > >> >>> 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 >>> >>> -- >>> 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 >>> >> > -- 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

1 0

Re: [petsc-dev] Who checked in...
by Jed Brown 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 10:31 AM, Matthew Knepley <knepley(a)mcs.anl.gov>wrote: > On Tue, Feb 12, 2013 at 11:28 AM, Matthew Knepley <knepley(a)gmail.com>wrote: > >> src/sys/logging/stagelog.c??? >> >> This is the same name modulo capitalization as >> >> src/sys/logging/utils/stageLog.c >> > I'll move it, but can we also downcase those file names? Aren't all source files supposed to be lowercase? $ git ls-files 'src/*.[ch]' |grep [A-Z] src/benchmarks/Index.c src/benchmarks/MPI_Wtime.c src/benchmarks/PLogEvent.c src/benchmarks/PetscGetCPUTime.c src/benchmarks/PetscGetTime.c src/benchmarks/PetscMalloc.c src/benchmarks/PetscMemcmp.c src/benchmarks/PetscMemcpy.c src/benchmarks/PetscMemzero.c src/benchmarks/PetscTime.c src/benchmarks/PetscVecNorm.c src/benchmarks/streams/BasicVersion.c src/benchmarks/streams/BasicVersionNoMPI.c src/benchmarks/streams/OpenMPVersion.c src/benchmarks/streams/PthreadVersion.c src/benchmarks/streams/SSEVersion.c src/dm/impls/da/utils/binaryMatlab.c src/dm/impls/mesh/examples/tests/TestMeshExodus.c src/dm/impls/mesh/examples/tutorials/Coarsener.h src/dm/impls/mesh/examples/tutorials/Hierarchy.h src/ksp/ksp/examples/tutorials/ex43-solCx.h src/ksp/ksp/impls/gmres/agmres/agmresDeflation.c src/ksp/ksp/impls/gmres/agmres/agmresLeja.c src/ksp/ksp/impls/python/pythonK.c src/ksp/pc/impls/python/pythonP.c src/snes/examples/tutorials/ex633D_DB.c src/snes/examples/tutorials/ex653D.c src/sys/logging/utils/classLog.c src/sys/logging/utils/eventLog.c src/sys/logging/utils/stageLog.c src/sys/shell/examples/tests/testcomponentsI.c src/sys/shell/examples/tests/testcomponentsII.c > >> 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 >> >> -- >> 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 >> >

1 0

Re: [petsc-dev] Who checked in...
by Matthew Knepley 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 11:28 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > src/sys/logging/stagelog.c??? > > This is the same name modulo capitalization as > > src/sys/logging/utils/stageLog.c > > 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 > > -- > 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 >

1 0

Stricter header includes
by Jed Brown 12 Feb '13

12 Feb '13

petscsys.h no longer includes petscimpl.h (including the _p_PetscObject definition) and petscvec.h no longer includes vecimpl.h (including _p_Vec). Users that need direct access can include the private headers, but we encourage you to explain your use case here so that we can provide a suitable public API. Merged here: https://bitbucket.org/petsc/petsc-dev/commits/5c59734726c7c41f493a5f5b9303c…

1 0

Re: [petsc-dev] Source cleanup potpourri
by Matthew Knepley 11 Feb '13

11 Feb '13

On Mon, Feb 11, 2013 at 5:28 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Mon, Feb 11, 2013 at 4:06 PM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > >> * We have a couple of malloc/free in use: >> http://krupp.iue.tuwien.ac.at/**petsc-style/malloc-free.txt<http://krupp.iue.tuwien.ac.at/petsc-style/malloc-free.txt> >> Except for the actual implementation of PetscMalloc() and the like >> somewhere in src/sys/, is there anything I have to keep in mind when fixing >> the other uses? >> > > The cases in mesh.c and plex.c are freeing memory allocated by an external > library. > Yep, there is no way around this currently. > options.c can be processed before the correct malloc implementation has > been determined (because it can be a command-line option). > > str.c stuff can be called before PetscInitialize > > hash.h is a third-party library that was brought in and was not fully > petsc-fied. > > yamlimpls.c is freeing memory allocated by an external library > > The tfs stuff was contributed and never petsc-fied. I don't think it's > worth doing maintenance on because it will have to be substantially > rewritten if someone wants to extend it in a nontrivial way. > > That pretty much covers it, so I think PETSc is okay on this front. > > >> >> * CHKERRQ is missing at a couple of places: >> http://krupp.iue.tuwien.ac.at/**petsc-style/ierr-chkerr.txt<http://krupp.iue.tuwien.ac.at/petsc-style/ierr-chkerr.txt> >> I noticed that PetscPrintf() is hardly ever checked for the value of >> ierr. Is this intentional? If yes, which other functions in PETSc should >> not be checked for the return value in ierr = ...? >> > > It looks like most of these are accidentally missing. CHKERRABORT can be > used when the function does not return PetscErrorCode, but the function > should really be fixed to return PetscErrorCode. > > >> >> * There is quite some dead code around: >> http://krupp.iue.tuwien.ac.at/**petsc-style/if0.txt<http://krupp.iue.tuwien.ac.at/petsc-style/if0.txt> >> Are there any objections (or even LOUD objections) in removing all blocks >> which are older than ~1 year? >> > > This may need to be done on a case by case basis, but most of it can > probably go. I wouldn't put any effort into src/dm/impls/{mesh,cartesian} > because I suspect that code will be deleted en masse within a year. > 1) Don't remove the dead code in ctetgen.c because I still have to turn on some of the cooler features (eventually) 2) mesh will be deleted when PyLith and Blaise have fully converted code. The aim is this summer. I will delete cartesian when I have documented the cool Grey code traversals that are buried in there. Matt > >> * src/contrib/markadamscolor/**color.c is the only place using assert(): >> http://krupp.iue.tuwien.ac.at/**petsc-style/assert.txt<http://krupp.iue.tuwien.ac.at/petsc-style/assert.txt> >> Since color.c entered in the previous century and hasn't been notably >> touched since at least 2001, is there any reason other than software >> archeology for keeping it? >> > > I don't know what other people think about the contrib directory. It has a > lot of cobwebs in it, but it can be fun to look at sometimes. The FUN3D > code in there is now out of date with respect to PETSc and METIS > interfaces. Somewhere along the line, comp/flow.c became syntactically > incorrect. (Perhaps reformatting interacted poorly its heavy use of macros.) > -- 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

1 0

Re: [petsc-dev] Source cleanup potpourri
by Karl Rupp 11 Feb '13

11 Feb '13

Hi Jed, > * We have a couple of malloc/free in use: > > (...) > > That pretty much covers it, so I think PETSc is okay on this front. Thanks, good news then. PETSc-fication should not be forgotten, though... > * CHKERRQ is missing at a couple of places: > http://krupp.iue.tuwien.ac.at/__petsc-style/ierr-chkerr.txt > <http://krupp.iue.tuwien.ac.at/petsc-style/ierr-chkerr.txt> > I noticed that PetscPrintf() is hardly ever checked for the value of > ierr. Is this intentional? If yes, which other functions in PETSc > should not be checked for the return value in ierr = ...? > > > It looks like most of these are accidentally missing. CHKERRABORT can be > used when the function does not return PetscErrorCode, but the function > should really be fixed to return PetscErrorCode. The current check only covers cases where the error code is stored in ierr. More of PETSc-specific static code analysis could be done with compiler tools, but we are not there yet. > * There is quite some dead code around: > http://krupp.iue.tuwien.ac.at/__petsc-style/if0.txt > <http://krupp.iue.tuwien.ac.at/petsc-style/if0.txt> > Are there any objections (or even LOUD objections) in removing all > blocks which are older than ~1 year? > > > This may need to be done on a case by case basis, but most of it can > probably go. Ok, I will apply defensive reasoning then... > I wouldn't put any effort into > src/dm/impls/{mesh,cartesian} because I suspect that code will be > deleted en masse within a year. I just added a reminder to my calendar for rechecking in two years ;-) > * src/contrib/markadamscolor/__color.c is the only place using assert(): > http://krupp.iue.tuwien.ac.at/__petsc-style/assert.txt > <http://krupp.iue.tuwien.ac.at/petsc-style/assert.txt> > Since color.c entered in the previous century and hasn't been > notably touched since at least 2001, is there any reason other than > software archeology for keeping it? > > > I don't know what other people think about the contrib directory. It has > a lot of cobwebs in it, but it can be fun to look at sometimes. The > FUN3D code in there is now out of date with respect to PETSc and METIS > interfaces. Somewhere along the line, comp/flow.c became syntactically > incorrect. (Perhaps reformatting interacted poorly its heavy use of macros.) That code was hard to refactor, and it seems to be missing a brace somewhere. Anyway, there's still Mercurial as a last resort... ;-) Best regards, Karli

1 0

Re: [petsc-dev] Source cleanup potpourri
by Jed Brown 11 Feb '13

11 Feb '13

On Mon, Feb 11, 2013 at 4:06 PM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > * We have a couple of malloc/free in use: > http://krupp.iue.tuwien.ac.at/**petsc-style/malloc-free.txt<http://krupp.iue.tuwien.ac.at/petsc-style/malloc-free.txt> > Except for the actual implementation of PetscMalloc() and the like > somewhere in src/sys/, is there anything I have to keep in mind when fixing > the other uses? > The cases in mesh.c and plex.c are freeing memory allocated by an external library. options.c can be processed before the correct malloc implementation has been determined (because it can be a command-line option). str.c stuff can be called before PetscInitialize hash.h is a third-party library that was brought in and was not fully petsc-fied. yamlimpls.c is freeing memory allocated by an external library The tfs stuff was contributed and never petsc-fied. I don't think it's worth doing maintenance on because it will have to be substantially rewritten if someone wants to extend it in a nontrivial way. That pretty much covers it, so I think PETSc is okay on this front. > > * CHKERRQ is missing at a couple of places: > http://krupp.iue.tuwien.ac.at/**petsc-style/ierr-chkerr.txt<http://krupp.iue.tuwien.ac.at/petsc-style/ierr-chkerr.txt> > I noticed that PetscPrintf() is hardly ever checked for the value of ierr. > Is this intentional? If yes, which other functions in PETSc should not be > checked for the return value in ierr = ...? > It looks like most of these are accidentally missing. CHKERRABORT can be used when the function does not return PetscErrorCode, but the function should really be fixed to return PetscErrorCode. > > * There is quite some dead code around: > http://krupp.iue.tuwien.ac.at/**petsc-style/if0.txt<http://krupp.iue.tuwien.ac.at/petsc-style/if0.txt> > Are there any objections (or even LOUD objections) in removing all blocks > which are older than ~1 year? > This may need to be done on a case by case basis, but most of it can probably go. I wouldn't put any effort into src/dm/impls/{mesh,cartesian} because I suspect that code will be deleted en masse within a year. > > * src/contrib/markadamscolor/**color.c is the only place using assert(): > http://krupp.iue.tuwien.ac.at/**petsc-style/assert.txt<http://krupp.iue.tuwien.ac.at/petsc-style/assert.txt> > Since color.c entered in the previous century and hasn't been notably > touched since at least 2001, is there any reason other than software > archeology for keeping it? > I don't know what other people think about the contrib directory. It has a lot of cobwebs in it, but it can be fun to look at sometimes. The FUN3D code in there is now out of date with respect to PETSc and METIS interfaces. Somewhere along the line, comp/flow.c became syntactically incorrect. (Perhaps reformatting interacted poorly its heavy use of macros.)

1 0

Source cleanup potpourri
by Karl Rupp 11 Feb '13

11 Feb '13

Hi, I've got a couple of questions related to fixing some of the remaining style issues: * We have a couple of malloc/free in use: http://krupp.iue.tuwien.ac.at/petsc-style/malloc-free.txt Except for the actual implementation of PetscMalloc() and the like somewhere in src/sys/, is there anything I have to keep in mind when fixing the other uses? * CHKERRQ is missing at a couple of places: http://krupp.iue.tuwien.ac.at/petsc-style/ierr-chkerr.txt I noticed that PetscPrintf() is hardly ever checked for the value of ierr. Is this intentional? If yes, which other functions in PETSc should not be checked for the return value in ierr = ...? * There is quite some dead code around: http://krupp.iue.tuwien.ac.at/petsc-style/if0.txt Are there any objections (or even LOUD objections) in removing all blocks which are older than ~1 year? * src/contrib/markadamscolor/color.c is the only place using assert(): http://krupp.iue.tuwien.ac.at/petsc-style/assert.txt Since color.c entered in the previous century and hasn't been notably touched since at least 2001, is there any reason other than software archeology for keeping it? Best regards, Karli

1 0

Re: [petsc-dev] Example cleanup
by Jed Brown 10 Feb '13

10 Feb '13

On Sun, Feb 10, 2013 at 9:09 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > Don't disagree with any of your reasons, however, there is very little > work wasted here. Most of the coding > is adding new methods, hooking up Python, etc. and not writing the two > lines for output. Thus, adding JSON > later will be all new work, and will invalid hardly anything. This is > modularity :) > Sounds good, though I don't understand "hooking up Python". Are you doing the validation itself in C or Python? If the latter, then just write JSON (no library needed, basically identical to python dict and array notation) and parse it using the Python standard library: import json python_dict = json.load(open('the-file.json'))

1 0

Re: [petsc-dev] Example cleanup
by Matthew Knepley 10 Feb '13

10 Feb '13

On Sun, Feb 10, 2013 at 9:49 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Sun, Feb 10, 2013 at 8:40 AM, Matthew Knepley <knepley(a)gmail.com>wrote: > >> The phrase "may as well" is very slippery. Python arrays are just [x, y, >> z], whereas JSON needs a library. >> However, the format is is now way crucial to the scheme. I want to get >> the workflow up an running with >> the simplest format. We will inevitably tweak it was we add tons of crap >> on top if it works. >> > > The syntax for plain arrays is identical. I was suggesting JSON to manage > recursive data structures (nested solvers, perhaps monitoring different > things). So it becomes a dict of arrays or a dict of dicts of arrays. Also, > we could spit out -snes_view in machine-readable form, we could have nicer > diagnostics on the GUI side. It is because of these extensions that I think > it's worth starting with something that will extend gracefully rather than > a hack that is only intended for arrays of numbers. > Don't disagree with any of your reasons, however, there is very little work wasted here. Most of the coding is adding new methods, hooking up Python, etc. and not writing the two lines for output. Thus, adding JSON later will be all new work, and will invalid hardly anything. This is modularity :) 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

1 0