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

[Michael Wenske]

Dear Steffen and Gregor,

thanks for answering so quick. I tried Gregors Method and compared the
L2 error against the
one Paraview would calculate for runs with different rank on a 40x40
grid with overlap 1 (Yaspgrid):

ranks    Paraview        Dune par L2

1            0.000825..    0.00108165..

2            0.000825..    0.00108188..

3            0.000825..    0.0011758..

4            0.000825..    0.00110271..

relevant method:

//--------------------------------------------------------------------------------------------------------------------------

    double get_an_l2_error_norm(const RHSType& numeric_sol, const
RHSType& analytic_sol) {
        using DGF = Dune::PDELab::DiscreteGridFunction<GFS,RHSType>;
        DGF numericDGF(*gfs_p,numeric_sol);
        DGF analyticDGF(*gfs_p,analytic_sol);
        Dune::PDELab::DifferenceAdapter<DGF,DGF>
diff2(numericDGF,analyticDGF);
        double l2err2 = l2norm2(diff2);
        double globall2err =  sqrt(gv_p->comm().sum(l2err2));
        return globall2err;
    }

//--------------------------------------------------------------------------------------------------------------------------

The fact that Paraview provides the same value throughout, gives me hope
that the parallelization
works correct (no matter the actual precision of the L2error measurement).

The l2norm.hh iterates via a templated iterator over the gridview. You
said it is not correct, does that mean
that the PDELab iterators iterate over the overlap-entities doubly?

lg,

Michael

      

On 11.12.18 14:03, Steffen Müthing wrote:
> 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: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20181211/8d6a6e22/attachment.sig>