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

Re: [petsc-dev] Stricter header includes
by Jed Brown 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 4:46 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > I thought Developer meant "we are still figuring this out", or "you can > really hurt yourself here", not "this is secret". > > > > That was my impression too. I thought the actual internal stuff did not > have a generated man page. > > So we don't need documentation for our own stuff? Consider the manual > page for PetscHeaderCreate(), that is truly a "developer" operation which > has a manual page and is in petscimpl.h (where it should be, it needn't be > public). Maybe we need both a "Developer" level and a > "Experimental"/"Dangerous"/"New" level? Good point, anyone implementing a new KSP need to include "private" headers. There are probably fewer people using PetscComposedData* so I guess it's fine as a developer level operation. As a general principle, I think everything implemented with a stable ABI should go outside petsc-private, regardless of level. That's means pretty much anything that does not depend on the struct definitions. This is also encouragement to eliminate macros.

1 0

Re: [petsc-dev] Stricter header includes
by Barry Smith 12 Feb '13

12 Feb '13

On Feb 12, 2013, at 4:41 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Tue, Feb 12, 2013 at 4:37 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Tue, Feb 12, 2013 at 5:34 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Certain PETSc "functions" are documented as being "Developer" level. Does this mean they will be in a "developer" API as opposed to the "user" API (for example in xxximpl.h instead of petscxxx.h)? Or will there not be a "developer" API at all and xxximpl.h merely provides access to the direct data structure. > > I thought Developer meant "we are still figuring this out", or "you can really hurt yourself here", not "this is secret". > > That was my impression too. I thought the actual internal stuff did not have a generated man page. So we don't need documentation for our own stuff? Consider the manual page for PetscHeaderCreate(), that is truly a "developer" operation which has a manual page and is in petscimpl.h (where it should be, it needn't be public). Maybe we need both a "Developer" level and a "Experimental"/"Dangerous"/"New" level? Barry > > It's possible to be a bit more strict about this by enabling visibility. When configured using --with-visibility, internal functions become "invisible" outside the shared library (even those that aren't file-local). To make that more precise and explicit, we could use PETSC_INTERNAL instead of PETSC_EXTERN for those functions.

1 0

Re: [petsc-dev] Stricter header includes
by Jed Brown 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 4:37 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Tue, Feb 12, 2013 at 5:34 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> >> Certain PETSc "functions" are documented as being "Developer" level. >> Does this mean they will be in a "developer" API as opposed to the "user" >> API (for example in xxximpl.h instead of petscxxx.h)? Or will there not be >> a "developer" API at all and xxximpl.h merely provides access to the direct >> data structure. >> > > I thought Developer meant "we are still figuring this out", or "you can > really hurt yourself here", not "this is secret". > That was my impression too. I thought the actual internal stuff did not have a generated man page. It's possible to be a bit more strict about this by enabling visibility. When configured using --with-visibility, internal functions become "invisible" outside the shared library (even those that aren't file-local). To make that more precise and explicit, we could use PETSC_INTERNAL instead of PETSC_EXTERN for those functions.

1 0

Re: [petsc-dev] Stricter header includes
by Matthew Knepley 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 5:34 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Certain PETSc "functions" are documented as being "Developer" level. > Does this mean they will be in a "developer" API as opposed to the "user" > API (for example in xxximpl.h instead of petscxxx.h)? Or will there not be > a "developer" API at all and xxximpl.h merely provides access to the direct > data structure. > I thought Developer meant "we are still figuring this out", or "you can really hurt yourself here", not "this is secret". Matt > On Feb 12, 2013, at 4:24 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > The PetscObjectState* and PetscObjectComposedData* routines are in > petscimpl, but documented as a public API. It would be nice to turn all > these macros into functions (which will change their signature). > > I'm a big fan of turning CPP macros into functions so would be happy to > see this happen. > > Barry > > > I'm dubious of any claims that these are called in a context where a > static function call would be a performance limitation. > > > > > > On Tue, Feb 12, 2013 at 9:39 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > 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… > > > > -- 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] Stricter header includes
by Barry Smith 12 Feb '13

12 Feb '13

Certain PETSc "functions" are documented as being "Developer" level. Does this mean they will be in a "developer" API as opposed to the "user" API (for example in xxximpl.h instead of petscxxx.h)? Or will there not be a "developer" API at all and xxximpl.h merely provides access to the direct data structure. On Feb 12, 2013, at 4:24 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > The PetscObjectState* and PetscObjectComposedData* routines are in petscimpl, but documented as a public API. It would be nice to turn all these macros into functions (which will change their signature). I'm a big fan of turning CPP macros into functions so would be happy to see this happen. Barry > I'm dubious of any claims that these are called in a context where a static function call would be a performance limitation. > > > On Tue, Feb 12, 2013 at 9:39 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > 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] Stricter header includes
by Jed Brown 12 Feb '13

12 Feb '13

The PetscObjectState* and PetscObjectComposedData* routines are in petscimpl, but documented as a public API. It would be nice to turn all these macros into functions (which will change their signature). I'm dubious of any claims that these are called in a context where a static function call would be a performance limitation. On Tue, Feb 12, 2013 at 9:39 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > 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] Who checked in...
by Jed Brown 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 10:44 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Tue, Feb 12, 2013 at 10:41 AM, Matthew Knepley <knepley(a)gmail.com>wrote: > >> Yes, we should have remembered to do it when we moved them but I was not >> paying attention. > > > Okay, I'll rename all those source files and remove the duplication. > https://bitbucket.org/petsc/petsc-dev/commits/46f6a6b7413afa07caccfcc54b7fd…

1 0

Re: [petsc-dev] Fwd: petsc/petsc-dev added -valgrind -debugger option to petscmpiexec (commit 398f06830ac9d0920f8d4e4d0bac972857d520d4)
by Jed Brown 12 Feb '13

12 Feb '13

Okay, pushed https://bitbucket.org/petsc/petsc-dev/commits/1b382c0c8a0048fa000c4641e3098… On Tue, Feb 12, 2013 at 11:37 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Stupid bitbucket doesn't let me respond to this. > > I think this is to handle the case where the vectors were obtained > without the appropriate block size so the routines called below cannot be > work properly. Perhaps the code should be changed so that the x and y bs > are only set if the jac->bs is a legitimate value and not when it is -1. > > Barry > > > Begin forwarded message: > > > From: Jed Brown <Bitbucket <commits-noreply(a)bitbucket.org>> > > Subject: Re: petsc/petsc-dev added -valgrind -debugger option to > petscmpiexec (commit 398f06830ac9d0920f8d4e4d0bac972857d520d4) > > Date: February 12, 2013 7:10:23 AM CST > > To: bsmith(a)mcs.anl.gov > > > > New comment on changeset: > > > > > https://bitbucket.org/petsc/petsc-dev/commits/398f06830ac9d0920f8d4e4d0bac9… > > > > Jed Brown (jedbrown) said: > > > > What is this trying to achieve? In `runex19_4`, this results in changing > the block size from `4` to `-1`. Can we delete these lines or do we need to > set `jac->bs` in that case? > > > > -- > > This is an comment notification from bitbucket.org. > > You are receiving this because you are participating > > in a comment thread. > >

1 0

Fwd: petsc/petsc-dev added -valgrind -debugger option to petscmpiexec (commit 398f06830ac9d0920f8d4e4d0bac972857d520d4)
by Barry Smith 12 Feb '13

12 Feb '13

Stupid bitbucket doesn't let me respond to this. I think this is to handle the case where the vectors were obtained without the appropriate block size so the routines called below cannot be work properly. Perhaps the code should be changed so that the x and y bs are only set if the jac->bs is a legitimate value and not when it is -1. Barry Begin forwarded message: > From: Jed Brown <Bitbucket <commits-noreply(a)bitbucket.org>> > Subject: Re: petsc/petsc-dev added -valgrind -debugger option to petscmpiexec (commit 398f06830ac9d0920f8d4e4d0bac972857d520d4) > Date: February 12, 2013 7:10:23 AM CST > To: bsmith(a)mcs.anl.gov > > New comment on changeset: > > https://bitbucket.org/petsc/petsc-dev/commits/398f06830ac9d0920f8d4e4d0bac9… > > Jed Brown (jedbrown) said: > > What is this trying to achieve? In `runex19_4`, this results in changing the block size from `4` to `-1`. Can we delete these lines or do we need to set `jac->bs` in that case? > > -- > This is an comment notification from bitbucket.org. > You are receiving this because you are participating > in a comment thread.

1 0

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

12 Feb '13

On Tue, Feb 12, 2013 at 10:41 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > Yes, we should have remembered to do it when we moved them but I was not > paying attention. Okay, I'll rename all those source files and remove the duplication.

1 0