[petsc-dev] access to finite element second derivatives

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:
> I do not find this argument convincing, and I don't think its coherent
> above.

The incremental cost of adding new fields is high if you have to modify
code in more places.  If I have n fields and want to add one more, you
would have me write three functions (f0_u, f1_u, f2_u) for residuals and
up to 9(2n+1) for Jacobian entries [1] (and modify existing functions
for the other direction of coupling).  Since C does not have closures,
those functions either need to be generated (terrible workflow) or
hand-written (worse).

This is wholly untenable, so we need an alternative.  I would have one
function for residuals and one function for Jacobians, with the results
added together.  Yes, you have to pack all the fields into the arrays,
but a dynamic PetscBag could be used to avoid fragile indexing there.

> Are you proposing to merge f0/f1/f2? That seems untenable since we must
> test against different things, unless you want one fat functions with
> f0/f1/f2
> as arguments. That does not seem any simpler to me. 

It is simpler because you can use loops and can decompose the terms
however you like.


[1] The complexities are 2 residual functions and 4(2n+1) Jacobian
    contributions if you only need first derivatives.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131202/e0d9a4ea/attachment.sig>