<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 2, 2013 at 5:29 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
> I do not find this argument convincing, and I don't think its coherent<br>
> above.<br>
<br>
</div>The incremental cost of adding new fields is high if you have to modify<br>
code in more places.  If I have n fields and want to add one more, you<br>
would have me write three functions (f0_u, f1_u, f2_u) for residuals and<br>
up to 9(2n+1) for Jacobian entries [1] (and modify existing functions<br>
for the other direction of coupling).  Since C does not have closures,<br>
those functions either need to be generated (terrible workflow) or<br>
hand-written (worse).<br></blockquote><div><br></div><div>1) You only write the functions which you have. I did physics for many years before</div><div>    computing, and anyone who does the derivation keeps all the terms separate</div>
<div>    until the end. I think polling our users would find that they like this.</div><div><br></div><div>2) Shoving everything into a single function makes it very hard to have sparse input</div><div>     to the Jacobian.</div>
<div><br></div><div>3) PyLith is fairly complex and we have had no trouble writing the functions. It would</div><div>    have been more complex to put everything in one function.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

This is wholly untenable, so we need an alternative.  I would have one<br>
function for residuals and one function for Jacobians, with the results<br>
added together.  Yes, you have to pack all the fields into the arrays,<br>
but a dynamic PetscBag could be used to avoid fragile indexing there.</blockquote><div><br></div><div>Things that do not exist are not simpler.</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 class="im">
> Are you proposing to merge f0/f1/f2? That seems untenable since we must<br>
> test against different things, unless you want one fat functions with<br>
> f0/f1/f2<br>
> as arguments. That does not seem any simpler to me.<br>
<br>
</div>It is simpler because you can use loops and can decompose the terms<br>
however you like.<br>
<br>
<br>
[1] The complexities are 2 residual functions and 4(2n+1) Jacobian<br>
    contributions if you only need first derivatives.<br>
</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>