<html><head></head><body>I was responding to your statement about an AD system being unable to compute a residual without also computing a Jacobian. Beyond that, it's just about how much intermediate work could be reused.<br>
<br>
I still don't understand your many field case. The geometric overhead is amortized and the Jacobian contribution typically grows quadratically in the number of fields, so I would expect it to increase the Jacobian:residual cost ratio, not reduce it.<br><br><div class="gmail_quote">On December 12, 2016 8:36:09 AM PST, Derek Gaston <friedmud@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><br /><br /><div class="gmail_quote"><div dir="ltr">On Mon, Dec 12, 2016 at 12:36 AM Jed Brown <<a href="mailto:jed@jedbrown.org">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="gmail_msg" />
> general to be "bad code management"?<br class="gmail_msg" />
<br class="gmail_msg" />
AD that prevents calling the non-AD function is bad AD.<br class="gmail_msg" /></blockquote><div><br /></div><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><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="gmail_msg" />
of many fields would already amortize the geometric overhead of visiting<br class="gmail_msg" />
an element.<br class="gmail_msg" /></blockquote><div><br /></div><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><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><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><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="gmail_msg"
/></blockquote><div><br /></div><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 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="gmail_msg" />
the residual, in which case the mere possibility of a line search (or of<br class="gmail_msg" />
converging) would justify deferring the Jacobian. I think it's much<br class="gmail_msg" />
better to make residuals and Jacobians fast independently, then perhaps<br class="gmail_msg" />
make the residual do some cheap caching, and worry about second-guessing Newton only as a last resort.</blockquote><div><br /></div><div>I think I agree. These are definitely "fringe" cases... for most applications Jacobians are _way_ more expensive.</div><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="gmail_msg" />
demonstrate some benefit to using heuristics and a relative cost model<br class="gmail_msg" />
to sometimes compute residuals and Jacobians together. It just isn't<br class="gmail_msg" />
that interesting and I think the gains are likely small and will<br class="gmail_msg" />
generate lots of bikeshedding about the heuristic.<br class="gmail_msg" /></blockquote><div><br /></div><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><div><br /></div><div>Derek</div></div></div>
</blockquote></div></body></html>