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

[Martin Vymazal]

On Tuesday, August 04, 2015 01:19:33 PM Barry Smith wrote:
> > 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


Of course I prefer to rely on other people's expertise in the domain instead 
of doing the job over again (with probably worse result). What you say about 
PETSc being a wrapper for other libraries makes sense.

Martin


> 
> >    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