On Tuesday, August 04, 2015 01:19:33 PM Barry Smith wrote: > > On Aug 4, 2015, at 12:34 PM, Matthew Knepley <[email protected]> wrote: > > > > On Tue, Aug 4, 2015 at 12:30 PM, Martin Vymazal <[email protected]> > > 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 > > > <[email protected]> > > > > > > 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
