<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 12, 2016 at 10:36 AM, Derek Gaston <span dir="ltr"><<a href="mailto:friedmud@gmail.com" target="_blank">friedmud@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Dec 12, 2016 at 12:36 AM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Can you expand on that? Do you believe automatic differentiation in<br class="m_-4658274767107223707gmail_msg">
> general to be "bad code management"?<br class="m_-4658274767107223707gmail_msg">
<br class="m_-4658274767107223707gmail_msg">
AD that prevents calling the non-AD function is bad AD.<br class="m_-4658274767107223707gmail_msg"></blockquote><div><br></div></span><div>That's not exactly the problem. Even if you can call an AD and a non-AD residual... you still have to compute two residuals to compute a residual and a Jacobian separately when using AD.</div><div><br></div><div>It's not the end of the world... but it was something that prompted me to ask the question.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are all the fields in unique function spaces that need different<br>
transforms or different quadratures? If not, it seems like the presence<br class="m_-4658274767107223707gmail_msg">
of many fields would already amortize the geometric overhead of visiting<br class="m_-4658274767107223707gmail_msg">
an element.<br class="m_-4658274767107223707gmail_msg"></blockquote><div><br></div></span><div>These were two separate examples. Expensive shape functions, by themselves, could warrant computing the residual and Jacobian simultaneously. Also: many variables, by themselves, could do the same.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Alternatively, you could cache the effective material coefficient (and its gradient) at each quadrature point during residual evaluation, thus avoiding a re-solve when building the Jacobian.</blockquote><div><br></div></span><div>I agree with this. We have some support for it in MOOSE now... and more plans for better support in the future. It's a classic time/space tradeoff.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would recommend that unless you know that line searches are rare.<br class="m_-4658274767107223707gmail_msg"></blockquote><div><br></div></span><div>BTW: Many (most?) of our most complex applications all _disable_ line search. Over the years we've found line search to be more of a hindrance than a help. We typically prefer using some sort of "physics based" damped Newton.</div></div></div></blockquote><div><br></div><div>We should move this discussion to a separate thread. I think this is the wrong choice. I would make the analogy that</div><div>you have a Stokes problem, and after finding that ILU fails you go back to GS and thousands of iterates which eventually</div><div>succeeds. The line search (or globalization) needs to respect problem structure. I think we have the potential to handle</div><div>this in PETSc.</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"><div dir="ltr"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is far more common that the Jacobian is _much_ more expensive than<br class="m_-4658274767107223707gmail_msg">
the residual, in which case the mere possibility of a line search (or of<br class="m_-4658274767107223707gmail_msg">
converging) would justify deferring the Jacobian. I think it's much<br class="m_-4658274767107223707gmail_msg">
better to make residuals and Jacobians fast independently, then perhaps<br class="m_-4658274767107223707gmail_msg">
make the residual do some cheap caching, and worry about second-guessing Newton only as a last resort.</blockquote><div><br></div></span><div>I think I agree. These are definitely "fringe" cases... for most applications Jacobians are _way_ more expensive.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That said, I have no doubt that we could<br class="m_-4658274767107223707gmail_msg">
demonstrate some benefit to using heuristics and a relative cost model<br class="m_-4658274767107223707gmail_msg">
to sometimes compute residuals and Jacobians together. It just isn't<br class="m_-4658274767107223707gmail_msg">
that interesting and I think the gains are likely small and will<br class="m_-4658274767107223707gmail_msg">
generate lots of bikeshedding about the heuristic.<br class="m_-4658274767107223707gmail_msg"></blockquote><div><br></div></span><div>I agree here too. It could be done... but I think you've convinced me that it's not worth the trouble :-)</div><div><br></div><div>Thanks for the discussion everyone!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Derek</div></font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">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></div>