[Petsc-trilinos-discussion] Scope and requirements

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:
>    One “suggestion” is, could there be a “higher-level” interface that
>    people could use that incorporated either PETSc or Trilinos
>    underneath? A difficulty I see with that approach is that design
>    decisions (either in C or C++) at one level of the stack permeate
>    the entire stack and users have to see more then just the top level
>    of the stack from our libraries. For example,

I think that if the program managers want better integration and an
easier transition between packages, that instead of creating a new
high-level interface, we should build out our cross-package plugin
support.  For example, ML is a popular solver among PETSc users, but we
could add support for more Trilinos preconditioners and solvers, and
even support assembling directly into a [TE]petra matrix (PETSc matrices
are more dynamic, but I still think this can be done reasonably).  We
probably need to talk some about representing block systems, but I don't
think the issues are insurmountable.

Then applications can freely choose whichever package they find more
convenient (based on experience, types of solvers, implementation
language, etc) with confidence that they will be able to access any
unique features of the other package.  When coupling multiple
applications using different solver packages, the coupler should be able
to choose either package to define the outer solve, with the same code
assembling either a monolithic matrix or a split/nested matrix with
native preconditioners within blocks.

As I see it, there is a fair amount of duplicate effort by packages
(such as libMesh, Deal.II, FEniCS) that ostensibly support both Trilinos
and PETSc, but were not written by "solvers people" and are managing the
imperfect correspondence themselves.  The unified interfaces that these
projects have built are generally less capable than had they committed
entirely to either one of our interfaces.


It will take some effort to implement this interoperability and it's
hard to sneak in under "basic research" like a lot of other software
maintenance tasks, but I think that providing it within our own plugin
systems is less work and can be supported better than any alternative.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-trilinos-discussion/attachments/20131120/b2da4bbe/attachment.pgp>