<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 21, 2013 at 12:39 PM, Bartlett, Roscoe A. <span dir="ltr"><<a href="mailto:bartlettra@ornl.gov" target="_blank">bartlettra@ornl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> > Therefore, I would say that before there is any talk of more detailed<br>
> > interfaces or interoperability between Trilinos and PETSc that we<br>
> > first solve the basic problems of version compatibility,<br>
><br>
> PETSc and Trilinos have a different approach to interface evolution.  We<br>
> tend to make minor modifications each year while you tend to create<br>
> entirely new interfaces and coax applications over to the new ones.  The<br>
> need to upgrade inflicts some pain on the users, but our users have<br>
> always ultimately buckled down and done it.<br>
<br>
</div>[Bartlett, Roscoe A.]<br>
<br>
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<br>

 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<br>
</blockquote><div><br></div><div>We support the latest version of a package. Nothing else. Any other strategy is just not feasible.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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 <a href="http://web.ornl.gov/~8vt/ORNLCSMDTribitsLifecycleModelPresentation.pdf" target="_blank">http://web.ornl.gov/~8vt/ORNLCSMDTribitsLifecycleModelPresentation.pdf</a>.  For those interested in the deeper arguments, I would recommend the section on "Regulated Backward Compatibility" in:<br>

<br>
    <a href="http://web.ornl.gov/~8vt/TribitsLifecycleModel_v1.0.pdf" target="_blank">http://web.ornl.gov/~8vt/TribitsLifecycleModel_v1.0.pdf</a><br>
<br>
which also describes the general three APP scenario mentioned above.<br>
<br>
Cheers,<br>
<br>
-Ross<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Petsc-trilinos-discussion mailing list<br>
<a href="mailto:Petsc-trilinos-discussion@lists.mcs.anl.gov">Petsc-trilinos-discussion@lists.mcs.anl.gov</a><br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/petsc-trilinos-discussion</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>