On Jan 21, 2013, at 7:03 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> On Mon, Jan 21, 2013 at 6:38 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Probably not, but petscsys.h includes petsc-private/petscimpl.h
> petscvec.h includes petsc-private/vecimpl.h etc so I think all user code
> includes all the parts of petsc-private that PETSc code does.
>
> Could we reasonably split those?
I don't think so.
> Something that is always included by user code is not very "private". Can we
> put the essential parts in petscsysinline.h, petscvecinline.h?
It will introduced much to much of a burden on PETSc developers to constantly
be balancing what is in petscsysinline.h and petsc-private/petscimpl.h. In the
end since any "inline stuff" needs to know essentially the EXACT underlying
struct data structures there is nothing that is truly private. {For example,
VecGetArray() could be done with hacks but then those hacks have to be kept in
mind forever more.}
I think trying to do this would just be unproductive "idealism", which is
why it isn't this way now. I tried to do this originally and gave it up
probably before Matt even came on the scene.
Barry
>
>
> Could we bag the ugly MPI logging macros and somehow use the "perfectly
> designed" MPI profiling level to gather the information? Sadly I think not,
> but would that be workable? (And still work with other MPI logging systems?)
>
> We have source code access so we should put our logging at a higher level.
> That stuff is meant to enable profiling without source code (just by linking
> differently). I think our choices are to namespace every intercept or to put
> the intercepts somewhere that they don't conflict with other libraries.
