[dune-pdelab] Why the lambda_*** methods?

[Jö Fahlke]

Hi!

I don't really remember either why this is the case, but I think it was indeed
some kind of optimization.  The local operator interface was in the original
code that Peter provided, but the grid operator (then grid operator space) has
been rewritten completely since then.  It is possible that the optimizations
were there originally but have been lost.  You'll have to ask Peter directly
if you want to know for sure what was intended.

Regards,
Jö.

Am Fri, 12. May 2017, 22:14:52 +0200 schrieb Oliver Sander:
> 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
> 



> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab


-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729

If you receive something that says "Send this to everyone you know,"
pretend you don't know me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20170515/9205c79b/attachment.sig>