[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