Matthew Knepley <[email protected]> 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.
pgpDdSukCd1FL.pgp
Description: PGP signature
