[petsc-users] C++ wrapper for petsc vector

[Barry Smith]

> On Aug 4, 2015, at 12:34 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Tue, Aug 4, 2015 at 12:30 PM, Martin Vymazal <martin.vymazal at vki.ac.be> wrote:
> Hello,
> 
>  1) thank you for the suggestion.
>  2) suppose you want to be able to switch between solver implementations
> provided by different libraries (e.g. petsc/trilinos). One obvious approach is
> through inheritance, but in order to keep child interfaces conforming to base
> class signatures, I need to wrap the solvers. If you can think of a better
> approach that would keep switching between solvers easy, I'm open to
> suggestions. I don't really need both trilinos and petsc, this is just a
> matter of curiosity.
> 
> I think this is a bad way of doing that. You would introduce a whole bunch of types
> at the top level which are meaningless (just like Trilinos). If you want another solver,
> just wrap it up in the PETSc PCShell object (two calls at most). Its an easier to write
> wrapper, which also fits in with all the debugging and profiling. We wrap a bunch of
> things this way like Hypre (70+ packages last time I checked).

   As Matt points out PETSc is already a wrapper library in that it is designed to easily wrap around other solver libraries to use the common PETSc API. So what you are doing is writing a wrapper library around a wrapper library, certainly possible but of questionable value.

   Note also that what makes particular solvers powerful is their use of "extra information" to obtain fast convergence over the only information being the "matrix values"; so for example the near null space for some algebraic multigrid methods, the geometric information for geometric multigrid, the "block structure" for "block preconditioners (what we call PCFIELDSPLIT in PETSc), etc. Do you really want to handle all of this "extra information" in your wrapper class? We already understand these details and provide APIs for them, it would be a huge thankless project for you to reproduce them all in your API.

 Barry


> 
>    Matt
>  
> Best regards,
> 
>  Martin Vymazal
> 
> 
> On Tuesday, August 04, 2015 12:24:14 PM Matthew Knepley wrote:
> > On Tue, Aug 4, 2015 at 12:15 PM, Martin Vymazal <martin.vymazal at vki.ac.be>
> >
> > wrote:
> > > Hello,
> > >
> > >  I'm trying to create a small C++ class to wrap the 'Vec' object. This
> > >
> > > class
> > > has an internal pointer to a member variable of type Vec, and in its
> > > destructor, it calls VecDestroy. Unfortunately, my test program segfaults
> > > and
> > > this seems to be due to the fact that the destructor of the wrapper class
> > > is
> > > called after main() calls PetscFinalize(). Apparently VecDestroy performs
> > > some
> > > collective communication, so calling it after PetscFinalize() is too late.
> > > How
> > > can I fix this?
> >
> > 1) Declare your C++ in a scope, so that it goes out of scope before
> > PetscFinalize()
> >
> > 2) Is there any utility to this wrapper since everything can be called
> > directly from C++?
> >
> >   Thanks,
> >
> >      Matt
> >
> > > Thank you,
> > >
> > >  Martin Vymazal
> 
> 
> 
> 
> -- 
> 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