<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 21, 2013 at 2:01 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Matt,<u></u><u></u></span></p><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt">
<div class="im"><div><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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><u></u><u></u></p>
</div></div><div><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p></div></div>
<div><p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">[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?</span></i></b></p>
</div></div></div></blockquote><div><br></div><div>Nope. I am not sure why we would argue for anything beyond interface stability.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt"><div class="im"><blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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><u></u><u></u></p>
</div></blockquote><div><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
</div></div><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal" style="margin-left:5.25pt"><b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">[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?</span></i></b></p>
</div></div></div></blockquote><div><br></div><div>The algorithms are nearly identical. The performance should be better on large machines because Mark is careful about making process</div><div>subsets for coarse grids:</div>
<div><br></div><div> <a href="http://lmgtfy.com/?q=Petsc+GAMG+PC">http://lmgtfy.com/?q=Petsc+GAMG+PC</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt"><div><div><p class="MsoNormal" style="margin-left:5.25pt">
<b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></i></b></p></div><div class="im"><blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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><u></u><u></u></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.<u></u><u></u></p></div></div><div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">[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?<u></u><u></u></span></i></b></p>
<p class="MsoNormal"><b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></i></b></p><p class="MsoNormal"><b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></i></b><span style="font-family:Arial,sans-serif"> <a href="http://www.orau.gov/swproductivity2014" target="_blank">http://www.orau.gov/swproductivity2014</a></span></p>
</div></div></div></div></blockquote><div><br></div><div>Its likely.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt"><div><div><p class="MsoNormal"> </p></div></div></div></div>
</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt"><div><p class="MsoNormal"></p><p class="MsoNormal"><b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.</span></i></b></p>
</div></div></div></blockquote><div><br></div><div>It should be enough to look at interface compatibility.</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt"><div><p class="MsoNormal"><b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Cheers,<u></u><u></u></span></i></b></p>
<p class="MsoNormal"><b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></i></b></p><p class="MsoNormal"><b><i><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">-Ross<u></u><u></u></span></i></b></p>
</div><p class="MsoNormal"> <u></u><u></u></p></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>