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

[Oliver Sander]

Hi Jö,

thanks for the Information.  So is there a policy regarding lambda_*** ?
Are these methods actively discouraged?  More concretely, suppose you were
writing a book chapter on dune-pdelab, would the lambda_*** methods be a
central part of the LocalOperator interface, or rather relegated to a footnote?

Thanks,
Oliver

On 15.05.2017 11:24, Jö Fahlke wrote:
> 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
> 
> 

-------------- 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/20170515/4795ea65/attachment.bin>