<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 4, 2015 at 12:30 PM, Martin Vymazal <span dir="ltr"><<a href="mailto:martin.vymazal@vki.ac.be" target="_blank">martin.vymazal@vki.ac.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
1) thank you for the suggestion.<br>
2) suppose you want to be able to switch between solver implementations<br>
provided by different libraries (e.g. petsc/trilinos). One obvious approach is<br>
through inheritance, but in order to keep child interfaces conforming to base<br>
class signatures, I need to wrap the solvers. If you can think of a better<br>
approach that would keep switching between solvers easy, I'm open to<br>
suggestions. I don't really need both trilinos and petsc, this is just a<br>
matter of curiosity.<br></blockquote><div><br></div><div>I think this is a bad way of doing that. You would introduce a whole bunch of types</div><div>at the top level which are meaningless (just like Trilinos). If you want another solver,</div><div>just wrap it up in the PETSc PCShell object (two calls at most). Its an easier to write</div><div>wrapper, which also fits in with all the debugging and profiling. We wrap a bunch of</div><div>things this way like Hypre (70+ packages last time I checked).</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Best regards,<br>
<br>
Martin Vymazal<br>
<br>
<br>
On Tuesday, August 04, 2015 12:24:14 PM Matthew Knepley wrote:<br>
> On Tue, Aug 4, 2015 at 12:15 PM, Martin Vymazal <<a href="mailto:martin.vymazal@vki.ac.be">martin.vymazal@vki.ac.be</a>><br>
><br>
> wrote:<br>
> > Hello,<br>
> ><br>
> > I'm trying to create a small C++ class to wrap the 'Vec' object. This<br>
> ><br>
> > class<br>
> > has an internal pointer to a member variable of type Vec, and in its<br>
> > destructor, it calls VecDestroy. Unfortunately, my test program segfaults<br>
> > and<br>
> > this seems to be due to the fact that the destructor of the wrapper class<br>
> > is<br>
> > called after main() calls PetscFinalize(). Apparently VecDestroy performs<br>
> > some<br>
> > collective communication, so calling it after PetscFinalize() is too late.<br>
> > How<br>
> > can I fix this?<br>
><br>
> 1) Declare your C++ in a scope, so that it goes out of scope before<br>
> PetscFinalize()<br>
><br>
> 2) Is there any utility to this wrapper since everything can be called<br>
> directly from C++?<br>
><br>
> Thanks,<br>
><br>
> Matt<br>
><br>
> > Thank you,<br>
> ><br>
> > Martin Vymazal<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>