[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