[Petsc-trilinos-discussion] Scope and requirements

[Bartlett, Roscoe A.]

Matt,
But someone would have to physically modify one or perhaps two of the three APPs in the three-APP scenario mentioned in the below slides and paper right?  If the breaks in backward compatibility are significant, who is going to upgrade APP1 and APP2 to the current version of Library A (or at least the one currently used in APP3)?  If the core developers for APP1 and APP2 are not part of the project to couple these with APP3, then who is going to make those mortifications to APP1 and APP2?  How can  they safely make those changes if they are not the core developers?  Will those mortifications make it back into the master sources for APP1 and APP2?  If the breaks in backward compatibility are minor, then what is the big deal in maintain backward compatibility over longer periods of time?   However, if the breaks in backward compatibility are significant and the behavior of the software changes a lot (even for the better), then that can result in a lot of work to upgrade the (likely poorly designed) test suites of these APP codes.  How can this work in practice?

This relates to my point 3. We do not change our interface based on the external package, so no problem.

[Bartlett, Roscoe A.] So PETSc does maintain backward compatibility of the interfaces and behavior?  I think that constitutes the definition of "backward compatibility".  Then what is the argument here?

As for the code GAMG to replace ML, should we tell the LANL Hydra-TH developers to stop using ML under PETSc and use GAMG instead?  Will they get the same or better performance in all cases?  Will this change their solutions requiring them to re-verify their entire test suite?  If the answer is yes to any of these, this will be a harder sell.

If their test suites are based upon convergence to a given tolerance, as all parallel tests must be, then everything will be fine.

[Bartlett, Roscoe A.] Have you seen exodiff-based testing?  Exodiff uses an unscaled L-infinity norm that makes it very hard to set good tolerances.  If applications defined a application-specific inner product with physics meaning, setting a good engineer tolerance would be easy and robust.  Yes, if application codes defined good robust tests this would be a piece of cake but they don't in many cases.  That is the reality with these codes.  However, that does not answer the issue of performance of ML vs. GAMG which the Hydra-TH developers and users will care a lot about also obviously.  Googling for "GAMG preconditioner" does not find anything. Should I be searching for something else?
BTW: The guidelines you list below for smoothing the breaks in backward compatibility are important, but that does *not* negate the advantages in maintaining contiguous sets of releases that maintain backward compatibility when considering larger software ecosystems.  Those measures just make it less painful when you do finally break backward compatibility but that change still requires careful manual changes to the code, usually by the core developers of the user code.
I have never been convinced of the merits of versioning. It always creates more problems than it solves, as evidenced by this thread I think.

[Bartlett, Roscoe A.] I don't understand what you mean by "versioning".  We likely will need to discuss this in person at some point.  Are you going to the SWP2XS workshop in January?

        http://www.orau.gov/swproductivity2014

Without understanding exactly what the PETSc policy is on backward compatibility, it is hard to know how to start going about building the foundation for a strategy for PETSc and Trilinos mutual co-existence and compatibility in complex lifecycle scenarios.

Cheers,

-Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-trilinos-discussion/attachments/20131121/6f591257/attachment-0001.html>