[Petsc-trilinos-discussion] Scope and requirements

[Bartlett, Roscoe A.]

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::DefaultLinearSolverBuilder 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.

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