[petsc-dev] Removed functions in MPI 3
Barry Smith
bsmith at mcs.anl.gov
Mon Jan 21 22:21:18 CST 2013
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.
More information about the petsc-dev
mailing list