[Petsc-trilinos-discussion] Scope and requirements

[Matthew Knepley]

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

> 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?*
>

Nope. I am not sure why we would argue for anything beyond interface
stability.


> 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?*
>

The algorithms are nearly identical. The performance should be better on
large machines because Mark is careful about making process
subsets for coarse grids:

    http://lmgtfy.com/?q=Petsc+GAMG+PC


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

Its likely.


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

It should be enough to look at interface compatibility.

   Matt


> *Cheers,*
>
>
>
> *-Ross*
>
>


-- 
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/faccd60b/attachment.html>