[Petsc-trilinos-discussion] Scope and requirements

[Matthew Knepley]

On Fri, Nov 22, 2013 at 5:19 PM, Bartlett, Roscoe A. <bartlettra at ornl.gov>wrote:

> Jed,
>
> 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
>  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.
>

http://en.wikipedia.org/wiki/Dependency_injection Yes, we use plugins in
exactly the same way. They obey the top-level interface,
just like your Stratimikos interfaces, and we instantiate the concrete type
dynamically (we can load the appropriate DLL with a
runtime option if necessary). It has been this way since I was in grad
school in 1996.

   Matt


> -Ross
>
> > -----Original Message-----
> > From: Jed Brown [mailto:jedbrown at mcs.anl.gov]
> > Sent: Friday, November 22, 2013 3:09 PM
> > To: Barry Smith; Bartlett, Roscoe A.
> > Cc: petsc-trilinos-discussion at lists.mcs.anl.gov
> > Subject: Re: [Petsc-trilinos-discussion] Scope and requirements
> >
> > Barry Smith <bsmith at mcs.anl.gov> writes:
> > >     Building PETSc to use ML, obviously, requires ML to be built
> > >     before PETSc since PETSc configure needs to link against the ML to
> > >     verify it is correct and PETSc make needs to locate the ML
> > >     includes to compile the ML wrapper.
> >
> > Although I do not think it is necessary in this case, PETSc _could_ be
> > compiled without ML, but have the ML plugin (currently residing in
> > src/ksp/pc/impls/ml) compiled later, dropping the libpetsc-ml.so into
> > $prefix/lib/petsc/plugins/.
> >
> > Unfortunately, some systems don't support shared libraries, so this is
> > not a viable distribution plan in general.  It is also possible to have
> > libpetsc-ml.a, which the user must link with -lpetsc-ml -lpetsc.  If we
> > allow plugin registration before PetscInitialize(), the registration
> > function could be given __attribute((constructor)) or use a C++
> > constructor.
> >
> > So such variants are possible with at most a couple lines of code, but I
> > don't think it's necessary for the current purpose.
> _______________________________________________
> Petsc-trilinos-discussion mailing list
> Petsc-trilinos-discussion at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-trilinos-discussion/attachments/20131122/45573e99/attachment-0001.html>