<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 22, 2013 at 5:19 PM, Bartlett, Roscoe A. <span dir="ltr"><<a href="mailto:bartlettra@ornl.gov" target="_blank">bartlettra@ornl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Jed,<br>
<br>
This does not sound like dependency inversion and dependency injection which work just fine with static libraries or shared libraries. For example, you can you can take a 5 year old pre-built and pre-installed version of Trilinos with Stratimikos and a downstream customer code (or library, APP, or whatever) can create subclasses of the necessary types (i.e. Thyra::LinearOpWtihSolveBase, Thyra::LinearOpWithSolveFactoryBase, Thyra::PrecondtionerFactoryBase, etc.) and can insert them into a Stratimikos::DefaultLinearSolverBuilder object (which is a upper-level factory for preconditioners and linear solvers) and then support for these automatically shows up along with their parameter lists. This is how Teko and MeuLu preconditioners are added to Stratimikos::DefaultLinearSolverBuilder objects which are used in downstream apps like Derkar, Denovo, Albany, etc. A grad student created a new preconditioner for use in Denovo and added it to the Stratimikos::DefaultLinearSolverBuild<br>
er object used by Denovo with just a few lines of code (just a #include and a call to setPreconditioningStrategyFactory()). I can't find a presentation that shows this but I can show source code for this.<br></blockquote>
<div><br></div><div><a href="http://en.wikipedia.org/wiki/Dependency_injection">http://en.wikipedia.org/wiki/Dependency_injection</a> Yes, we use plugins in exactly the same way. They obey the top-level interface,<br></div>
<div>just like your Stratimikos interfaces, and we instantiate the concrete type dynamically (we can load the appropriate DLL with a</div><div>runtime option if necessary). It has been this way since I was in grad school in 1996.</div>
<div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
-Ross<br>
<div class="im"><br>
> -----Original Message-----<br>
> From: Jed Brown [mailto:<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>]<br>
> Sent: Friday, November 22, 2013 3:09 PM<br>
> To: Barry Smith; Bartlett, Roscoe A.<br>
> Cc: <a href="mailto:petsc-trilinos-discussion@lists.mcs.anl.gov">petsc-trilinos-discussion@lists.mcs.anl.gov</a><br>
> Subject: Re: [Petsc-trilinos-discussion] Scope and requirements<br>
><br>
</div><div class=""><div class="h5">> Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
> > Building PETSc to use ML, obviously, requires ML to be built<br>
> > before PETSc since PETSc configure needs to link against the ML to<br>
> > verify it is correct and PETSc make needs to locate the ML<br>
> > includes to compile the ML wrapper.<br>
><br>
> Although I do not think it is necessary in this case, PETSc _could_ be<br>
> compiled without ML, but have the ML plugin (currently residing in<br>
> src/ksp/pc/impls/ml) compiled later, dropping the libpetsc-ml.so into<br>
> $prefix/lib/petsc/plugins/.<br>
><br>
> Unfortunately, some systems don't support shared libraries, so this is<br>
> not a viable distribution plan in general. It is also possible to have<br>
> libpetsc-ml.a, which the user must link with -lpetsc-ml -lpetsc. If we<br>
> allow plugin registration before PetscInitialize(), the registration<br>
> function could be given __attribute((constructor)) or use a C++<br>
> constructor.<br>
><br>
> So such variants are possible with at most a couple lines of code, but I<br>
> don't think it's necessary for the current purpose.<br>
</div></div><div class=""><div class="h5">_______________________________________________<br>
Petsc-trilinos-discussion mailing list<br>
<a href="mailto:Petsc-trilinos-discussion@lists.mcs.anl.gov">Petsc-trilinos-discussion@lists.mcs.anl.gov</a><br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>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>