[Petsc-trilinos-discussion] Scope and requirements

[Jed Brown]

"Bartlett, Roscoe A." <bartlettra at ornl.gov> writes:

> So what? If it solves a problem, what is it to us what a client
> application does? 

We have failed if we pawn this responsibility off to a client
application.  It is possibly acceptable as a temporary workaround, but
not as a general strategy.

> The problem is that there should be no link ordering reqiirement
> between trilinos and petsc. 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)?  

You seem to be viewing PETSc and Trilinos as singular monolithic
packages, where as they are in fact modular and as long as the
dependency graph of the sub-packages forms a DAG, it would be possible
accommodate.  However, that farms off complexity to the build system,
which I don't like, and is why I suggested distributing the plugins
separately.  The problem with plugins, which I noted early
<87y54h4ohf.fsf at jedbrown.org>, is that when distributed with static
libraries, the user has to do something to activate the plugin.  The
plugin does not affect the _interface_ seen by the client application,
and yet they depend on it in the sense that they must link it explicitly
(or worse, call a function).  The entire point of IoC (and encapsulation
in general) is to eliminate dependencies on implementation, but static
libraries deny us of link-time encapsulation.

> With C++ we could just put in static initialization code in downstream
> lib

Yuck.

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

That's what I suggested on Thursday <87y54h4ohf.fsf at jedbrown.org>.
PETSc needs zero source-code modifications to do this, just a simple
build system change and some mechanism of informing the user how to link
the libpetsc-ml.a (or libpetsc-trilinos.a if we bundle plugins for
matrix types, MueLu, and whatever else).

It is the distribution and informing the user of how to link that I'm
most concerned with.  Separate distribution means we would need another
configure.

* Should that configure trust configure results obtained earlier by
  PETSc and/or Trilinos build systems?  People will accidentally or
  intentionally change their environments between configures, so
  trusting earlier results will create support email.  But while
  configure takes one minute on a laptop, it takes an hour on a
  "leadership" machine, so re-running configure hurts usability (human
  time to install).

* Will there be an option to automatically download?  (Most PETSc users
  use --download-ml instead of installing on their own.)

* Current users can include PETSc makefiles, run a command-line tool, or
  use FindPETSc.cmake to determine how to link.  If the plugins are
  distributed separately, where will the user's build system get link
  information?  That step must be exactly the same with or without
  plugins and with static or shared libraries.  Users of shared
  libraries should be able to link only with -lpetsc.
-------------- 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/20131123/4bf9fd17/attachment.pgp>