<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Matt,<o:p></o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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?</span><o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This relates to my point 3. We do not change our interface based on the external package, so no problem.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>[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?<o:p></o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></i></b></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If their test suites are based upon convergence to a given tolerance, as all parallel tests must be, then everything will be fine.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal style='margin-left:5.25pt'><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>[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?<o:p></o:p></span></i></b></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>BTW: The guidelines you list below for smoothing the breaks in backward compatibility are important, but that does *<b>not</b>* 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.</span><o:p></o:p></p></div></blockquote><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>[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?<o:p></o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span></i></b><span style='font-family:"Arial","sans-serif"'> <a href="http://www.orau.gov/swproductivity2014">http://www.orau.gov/swproductivity2014</a></span><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers,<o:p></o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Ross<o:p></o:p></span></i></b></p></div></div><p class=MsoNormal> <o:p></o:p></p></div></div></div></div></body></html>