Dear Florian,
> {
> BlockCompressedSetSparsityPattern csp (2,2);
> ...
> DoFTools::make_sparsity_pattern (stokes_dof_handler, coupling,
> csp);
> ...
> }
>
>
>
> I found out that the memory increases during the call
> DoFTools::make_sparsity_pattern (stokes_dof_handler, coupling, csp);
>
> But when I check the memory consumption of the dof_handler it seems to
> remain the same. So which object needs so much memory (because the
> memory of csp should be released at the end of the function)?
> Is there a possibility to circumvent this huge memory consumption, so
> that I have got a chance to run my program for larger problems?
I think your problem is the way the sparsity pattern is constructed by
the CompressedSetSparsityPattern class. You should be able to use many
more dofs if you use BlockCompressedSparsityPattern instead, which is
however much slower. T. Heister has recently implemented a class
CompressedSimpleSparsityPattern which could be worth a try, because it
seems to use not that much more memory than CompressedSparsityPattern,
but should be significantly faster (I'm not sure whether all interfaces
to it are already working)...
Then there is another point (at least in the current version of
step-32): As the Trilinos interfaces are implemented now, each processor
will have to own the full sparsity pattern in order to create a
distributed matrix. As step-32 does this right now - namely generating
the whole sparsity pattern on all processors at the same time - makes
things even worse since on usual clusters up to 8 processors share the
memory, which decreases the available memory per thread by a factor of 4
or 8. Eventually this should be improved, but I don't know if anyone has
looked at it or if there is a solution on the distributed_grids branch
that could easily be used here...
Best,
Martin
_______________________________________________
