[Petsc-trilinos-discussion] Scope and requirements

[Jed Brown]

Thanks for the concrete example, Ross.

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

> We have two parallel Fortran codes using PETSc, MPACT (Univ. of Mich.)
> and COBRA-TF (Penn. State), that have overlapping sets of processes
> and they can't currently figure out how to initialize PETSc to work in
> these cases (they may ask for some help actually).  Also, what about
> nested PETSc solves from different applications?  What does that
> output look like if you could even get it to run (which they have not
> yet)?

Objects share nothing and each monitor can have its own private viewer,
more below.  Profiling information (-log_summary) is collated globally
and can be directed anywhere.

> As of right now, it is completely impractical to couple Hydra-TH into
> Insilico because of their use of PETSc and an old version of ML from
> Trilinos.  

You can build PETSc with ML from Trilinos, but --download-ml does not
pull down full Trilinos so the user has to install Trilinos first and
use --with-ml-dir=/path/to/trilinos.  Not many of our users have been
motivated to do this.

> 1) The current version of PETSc must be compatible with the current
> version of Trilinos so they can be linked in a single executable and
> we must remove link order dependencies.  Also, users need to know
> ranges of versions of Trilinos and PETSc that are link and runtime
> compatible.  The better that the mature capabilities in Trilinos and
> PETSc can maintain backward compatibility over longer ranges of
> time/versions, the easier this gets.  The ideas for doing this are
> described in the section "Regulated Backward Compatibility" in
> http://web.ornl.gov/~8vt/TribitsLifecycleModel_v1.0.pdf .  Also, PETSc
> should support dependency inversion and dependency injection so that
> people can add ML support into PETSc without having to directly have
> ML upstream from PETSc.  

PETSc can use an externally-configured ML, but the current build
system/distribution mechanism needs that information when PETSc is
built.  Zero source code modifications are necessary to compile the ML
plugin externally, just build system.  If shared libraries cannot be
used, someone would need to call PCRegister("ml",PCCreate_ML).

> 2) The user needs to have complete control of where output goes on an
> object-by-object based on each process, period.  

This is already supported through source interfaces and run-time
options.  Output is always associated with a PetscViewer, usually via
the monitor interfaces of the solvers.

> Otherwise, multiphysics codes (either all PETSc or Trilinos or mixes)
> create incomprehensible output.  This also applies to nested solves
> (i.e. how does output form GMRES nested inside of GMRES output looks
> like?).  

  -physA_ksp_monitor outer.log
  -physB_mg_levels_2_fieldsplit_momentum_ksp_monitor_true_residual inner.log
  -physB_mg_levels_2_fieldsplit_momentum_ksp_monitor_singular_value inner-sing.log

You can also use the programmatic interfaces to wire this up.

> Therefore, I would say that before there is any talk of more detailed
> interfaces or interoperability between Trilinos and PETSc that we
> first solve the basic problems of version compatibility, 

PETSc and Trilinos have a different approach to interface evolution.  We
tend to make minor modifications each year while you tend to create
entirely new interfaces and coax applications over to the new ones.  The
need to upgrade inflicts some pain on the users, but our users have
always ultimately buckled down and done it.

> dependency injection, 

All PETSc objects have full plugin architectures.  You can register
anything from matrix and vector formats to solvers, monitors, and
viewers at run-time, and they appear native.  Applications frequently
change matrix format at run-time.

> and outputting control.  

Hopefully there is some parity between PetscViewers and the Trilinos
streams.
-------------- 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/20131121/437618f9/attachment.pgp>