[dune-pdelab] Why the lambda_*** methods?
Oliver Sander
oliver.sander at tu-dresden.de
Fri May 12 22:14:52 CEST 2017
Dear pdelab team,
I have recently tried to explain to somebody why the lambda_*** methods
are separate in the LocalOperator interface, rather than having alpha_***
assemble the entire residual. As it turns out, I am not sure I know
the reason myself.
Initially, I thought this was to make Newton solvers more efficient.
A Newton solver needs to call alpha_*** at each iteration, but lambda_***
only once. However, the Newton implementation in dune-pdelab calls
lambda_*** at each iteration. In fact, there is no way to access the
alpha_*** contribution throught the GridOperator interface at all!
So that's not the reason.
Then I learned that the finite difference code in NumericalJacobian uses
only alpha_***, but disregards lambda_***. That makes sense: in first-order
FD formulas, the lambda_*** parts cancel out anyway.
But now I am wondering: Is that really all? Because that reason does
not really convince me:
- While having lambda_*** separate may speed up FD approximations of the
Jacobian, it seems likely that it will slow down other things.
For example, calling lambda_*** and alpha_*** together means that
shape functions have to be computed twice, there are two separate
quadrature loops, etc.
- Having separate lambda_*** methods makes LocalOperator implementations
much larger (statically). Adding a normal source term to a Poisson assembler
is simply two extra lines in alpha_volume. A separate lambda_volume
method is at least 20 lines.
- Its doubtful whether FD approximations are desirable to begin with:
Algorithmic differentiation is faster and more precise.
Can I please get some insight from the pdelab team? Am I missing something?
Thanks,
Oliver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5158 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20170512/e6dd4b5c/attachment.bin>
More information about the dune-pdelab
mailing list