[Petsc-trilinos-discussion] Scope and requirements

[Matthew Knepley]

On Thu, Nov 21, 2013 at 12:39 PM, Bartlett, Roscoe A.
<bartlettra at ornl.gov>wrote:

> > > 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.
>
> [Bartlett, Roscoe A.]
>
> But the compatibility between Trilinos and PETSc, say in the PETSc/ML case
> has nothing to do with the "user" (i.e. downstream project using Trilinos
> and PETSc).  Can they just grab arbitrary versions of PETSC and Trilinos
> and configure and build them and have the ML support under PETSc work?  If
> not arbitrary versions (which is unreasonable) what about ranges of
> versions?  Think about this same issue in a large ecosystem of libraries
> and applications in a large multi-physics coupled code (CASL VERA is a
> small example of this we have already had to face).  For example, if every
> major release of Library A breaks backward compatibility with prior
> versions and you have to couple together three APPs that all use three
> different versions of Library A in a statically linked executable, how can
> that work?  Do you just tell all the APP development teams to all upgrade
> (or downgrade) to the use same version of Library A that has different
> interfaces and behavior between the different v
>  ersions?  Is that practical?  What if the downstream project development
> team does even have access to the developers of say APP1 that currently
> only works against an older version of Library A?  Does the downstream
> project development team take it upon themselves to upgrade the version of
> Library A (with new interfaces and behavior) in APP1 that they did not even
> develop and don't really understand all the test cases for
>

We support the latest version of a package. Nothing else. Any other
strategy is just not feasible.

   Matt


> However, if Library A maintains sufficient backward compatibility between
> the ranges of versions of Library A currently in use by all three APP
> codes, then you just need to use the latest version of Library A and that
> is it.  Easy as pie.  This example, by the way, is shown in slides 36 and
> 37 in
> http://web.ornl.gov/~8vt/ORNLCSMDTribitsLifecycleModelPresentation.pdf.
>  For those interested in the deeper arguments, I would recommend the
> section on "Regulated Backward Compatibility" in:
>
>     http://web.ornl.gov/~8vt/TribitsLifecycleModel_v1.0.pdf
>
> which also describes the general three APP scenario mentioned above.
>
> Cheers,
>
> -Ross
>
>
> _______________________________________________
> Petsc-trilinos-discussion mailing list
> Petsc-trilinos-discussion at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-trilinos-discussion/attachments/20131121/d56f4e75/attachment.html>