[dune-pdelab] Runtime Jump for Large YaspCube Grids

[Dominic Kempf]

Hello Dion,

while at first glance, I was inclined to say that this has something to do
with the fact that your solution vector is fitting the L1 Cache in the
smaller test and does not in the bigger, I am not so sure now. That does
not explain a breakdown of the linear solver. For further analysis, we
would need to investigate your local operator, your build system flags and
so on. To speed things up: What do you think about just coming over some
time today and analyze it on site (to call me, dial 8888)? Might as well
use the fact we are working on the same campus. Dont worry mailing list: We
will give you a summary afterwards!

Dominic

On Thu, Jan 22, 2015 at 10:02 AM, Dion Häfner <
dhaefner at iup.uni-heidelberg.de> wrote:

>  Hey Dominic,
>
> thank you for your answer. I am solving the Richards Equation (nonlinear
> PDE) with the DG method, essentially using:
>
>   typedef Dune::PDELab::QkDGLocalFiniteElementMap<Real,Real,order,dim>
> FEM;   as finite element map,
>   typedef Dune::PDELab::ISTLBackend_BCGS_AMG_SSOR<IGO> LS;   as linear
> solver,
>   typedef Dune::PDELab::Newton<IGO,LS,U> PDESOLVER;   as non-linear solver,
>   Dune::PDELab::Alexander2Parameter<Real> alex2;    as timestepper.
>
> The grid is set up with
>
>           Dune::FieldVector<double,dim> N;
>           for (unsigned int i=0; i<dim; i++)
>             N[i] = elements[i];
>           Dune::FieldVector<bool,dim> periodic(false);
>           int overlap = 2;
>           const YaspXDirPartition<dim> yp;
>           Dune::YaspGrid<dim>
> grid(helper.getCommunicator(),upperRight,N,periodic,overlap,&yp);
>           typedef Dune::YaspGrid<dim>::LeafGridView GV;
>           const GV& gv=grid.leafGridView();
>
> I have appended the source code responsible for the actual solution, along
> with two logfiles - one with barely over 2000 elements in the grid, one
> barely below. You can see that the amount of linear iterations (and thus
> linear solve time) rises sharply if the elements exceed 2000.
>
> I hope this is enough information to address this problem - if not, please
> tell me so.
>
>
> Thank you kindly for your time!
>
> Dion
>
>
> Am 21.01.15 um 10:23 schrieb Dominic Kempf:
>
>  Hello Dion,
>
>  to answer your question we need some information on the exact problem you
> are using for this benchmark. Can you provide us the code? I will refrain
> from any wild guesses that come to my mind before having seen the actual
> problem.
>
>  Best,
> Dominic
>
> On Tue, Jan 20, 2015 at 7:33 PM, Dion Häfner <
> dhaefner at iup.uni-heidelberg.de> wrote:
>
>> Dear PDELab Developers,
>>
>> when I was benchmarking my DUNE / PDELab module, I noticed a sudden jump
>> in runtime (approx. by a factor of 4) as soon as the number of grid
>> elements exceeded 2000 in a YaspCube grid. I could not reproduce this
>> behavior with UG Grids, so I think it is somewhat specific to YaspCube
>> Grids.
>>
>> Has anyone encountered a similar behavior before? How can this be
>> adressed?
>>
>> Sorry if my question is not very specific. If you need further
>> information on my module or the methods used, please ask and I will provide.
>>
>> Thank you in advance,
>>
>> Dion Häfner
>>
>> _______________________________________________
>> dune-pdelab mailing list
>> dune-pdelab at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-pdelab
>>
>
>
>
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20150122/706562de/attachment.htm>