[dune-pdelab] [SPOOFED?] parallel L2-error norms and parallel volume integrals

[Steffen Müthing]

Hi Michael,

> Am 11.12.2018 um 12:03 schrieb Michael Wenske <m_wens01 at wwu.de>:
> 
> Dear List,
> 
> i'm having problems verifying my numerics in a parallel DUNE-PDELab setting.
> 
> Im on Dune 2.6, I use a Yasp grid and solve Darcy-like equations.
> 
> I constructed an analytical solution, which I can interpolate and write
> to .vtk files
> together with the numerical solution.
> I can compare the numerical solution and the analytic solution with the
> tools
> Paraview provides (Calculator-filter and Integrate Variables etc. ). And
> so far things look wonderful,
> but this way I rely on the correctness of the Paraview implementation.
> And I have to click a lot.
> 
> Now I want to do the same thing in the code in a more automated fashion.
> Is there PDELab functionality to -globally- compare and analyze two
> solutions?
> 
> I tried:
> 
>     double get_error_norm(const RHSType& numeric_sol, const RHSType&
> analytic_sol){
>                 auto difference = numeric_sol-analytic_sol;        //Fail
>                 ISTLHelperType parHelper(*gfs_p);
>                 Dune::PDELab::OverlappingScalarProduct<GFS,RHSType>
> ovlp_scalar_prod(*gfs_p,parHelper);
>                 double norm =ovlp_scalar_prod.norm(difference);
>                 return norm;
>     }
> 
> where RHSType is :"Dune::PDELab::Backend::Vector<GFS,RangeFieldType>"
> 
> but it seems that there are no parallel operators implemented to do *=,
> +, - on these Vector types.
> Technically the above approach is not correct, as not every coefficient
> should be weighted in the same way.
> Coefficients which lie on the Border of the domain (Q1, quadrilateral)
> should be counted half/quarter.

you cannot weight the values (the norm involves squaring the values, so you will
get wrong results). Assuming your solution is consistent (which it should be after
solve()), your code actually does the right thing. The parallel helper computes a
disjoint partitioning for all degrees of freedom, so every entry of the vector gets
added only once into your norm.

That said, you might also want to look into Gregor’s solution, which actually integrates
your error over the domain. That said, the l2norm.hh version is not correct in parallel
for overlapping grids, as overlapping regions will be integrated over more than once.

Best
Steffen

> 
> I might force my Local operator to do such operations, since the Methods
> are provided with the necessary
> Information upon assembly, but it seems wrong to me to mix the numerical
> solution steps with the analysis-related
> code.
> 
> If I would set up something like a AnalyserLocalOperator, how would I
> traverse this correctly? Currently I pass
> The local operators as template types to the solvers, but in this case
> there is nothing to solve.
> The whole Abstraction of the Local Operator is pointed towards
> assembling a Matrix( for a Solver), so If I just want
> to analyze my solution w.r.t volume, histogram, L2 error against
> analytic sol etc. is this still the correct approach?
> 
> This might be trivial for the ol' folks but I can't seem to figure out a
> clean way to do this.
> 
> thanks in advance,
> 
> Michael Wenske
> 
> 
> 
> 
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at lists.dune-project.org
> https://lists.dune-project.org/mailman/listinfo/dune-pdelab
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20181211/cb4946f2/attachment.sig>