[Petsc-trilinos-discussion] Scope and requirements

[Bartlett, Roscoe A.]

Thanks Barry,

I will inform the Hydra-TH developers of the option of updating the version of ML used under PETSc and building the PETSc/ML adapters downstream from Trilinos.  In the end it is up to them how they want to address the issue of PETSc and Trilinos with Hydra-TH.  It is just that the current approach of Hydra-TH using a different version of PETSc and ML from the rest of the VERA components will not allow them to couple in with other VERA codes.

Cheers,

-Ross

> -----Original Message-----
> From: Barry Smith [mailto:bsmith at mcs.anl.gov]
> Sent: Friday, November 22, 2013 9:35 PM
> To: Bartlett, Roscoe A.
> Cc: Jed Brown; Matthew Knepley; petsc-trilinos-discussion at lists.mcs.anl.gov
> Subject: Re: [Petsc-trilinos-discussion] Scope and requirements
> 
> 
> On Nov 22, 2013, at 7:41 PM, Bartlett, Roscoe A. <bartlettra at ornl.gov>
> wrote:
> 
> > So what? If it solves a problem, what is it to us what a client application
> does?
> 
>    I think Jed explained this pretty well in his later email.
> 
> > The problem is that there should be no link ordering reqiirement between
> trilinos and petsc.
> 
>    We can do this. We build PETSc and then after Trilinos is located (which may
> be even after the application is linked) we build the ML wrapper.  Yes
> currently it is terribly documented and foggy, thanks for making that clear.
> We will simplify the steps to do this and document how one does this. We
> can do this with many of the external packages but it is currently too obscure.
> 
>    Barry
> 
> 
> 
> > What if trilinos had adapters for petsc solvers and preconditioners (like was
> supposed to happen in tops-2 ), how would that work (that is called a circular
> dependency)? With C++ we could just put in static initialization code in
> downstream lib to insert adapter automatically but there should really be an
> independent package outside of both that provides trilinos and petsc
> interoperability and that solves the ordering problem.
> >
> > -Ross
> >
> >
> > -----Original Message-----
> > From: Barry Smith [bsmith at mcs.anl.gov]
> > Sent: Friday, November 22, 2013 08:02 PM Eastern Standard Time
> > To: Bartlett, Roscoe A.
> > Cc: Jed Brown; Matthew Knepley; petsc-trilinos-
> discussion at lists.mcs.anl.gov
> > Subject: Re: [Petsc-trilinos-discussion] Scope and requirements
> >
> >
> > On Nov 22, 2013, at 6:48 PM, Bartlett, Roscoe A. <bartlettra at ornl.gov>
> wrote:
> >
> > > Then what is the issue with shared vs static libs? Why can't downstream
> client app just compile the petsc ml adapter, call the registration func then
> use ml under petsc like before?
> >
> >    They can. Our objection to this is
> >
> > > call the registration func.
> >
> >     Barry
> >
> >
> > >
> > > -Ross
> > >
> > > -----Original Message-----
> > > From: Jed Brown [jedbrown at mcs.anl.gov]
> > > Sent: Friday, November 22, 2013 06:44 PM Eastern Standard Time
> > > To: Matthew Knepley; Bartlett, Roscoe A.
> > > Cc: Barry Smith; petsc-trilinos-discussion at lists.mcs.anl.gov
> > > Subject: Re: [Petsc-trilinos-discussion] Scope and requirements
> > >
> > > Matthew Knepley <knepley at gmail.com> writes:
> > >
> > > > 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.
> > >
> > >
> > >
> > > PETSc's system is closer to what Martin Fowler refers to as "service
> > >
> > > locator" in his essay which seems to be a popular reference, though the
> > >
> > > techniques had been around for decades by the time he wrote the essay.
> > >
> > >
> > >
> > > http://www.martinfowler.com/articles/injection.html
> > >
> >
> >