Hi Florian, Florian Keller wrote: > > So which object needs so much memory (because the memory of csp should > be released at the end of the function)? > A few things: 1. The dynamic sparsity patterns BlockCompressed*SparsityPattern, especially BlockCompressedSetSparsityPattern, need a lot of memory to store the dynamic sparsity pattern created with DofTools::make_sparsity_pattern(). 2. BlockCompressedSetSparsityPattern uses an stl container with an allocator from stl which may not release it's memory after destruction of the csp (depends on your compiler, the standard library and it's settings). 3. Even in a parallel setting you generate the full sparsity pattern on every cpu. This is a memory and runtime bottleneck of course. I'm currently experimenting with a way to only generate the local rows, which speeds up the process dramatically. I'm doing this with Petsc not with Trilinos, so we have to check first if this also works with the Trilinos matrices. I can go into more detail if anyone is interested. You basically replace DofTools::make_sparsity_pattern() with an own routine which does csp.add() only for your local rows, this works because Petsc only looks at the local rows for creating the matrix (and Trilinos should work the same way).
Anyway, my advice would be to try BlockCompressedSimpleSparsityPattern instead of BlockCompressedSetSparsityPattern first (only available via svn, i think). See http://dealii.org/developer/doxygen/deal.II/group__Sparsity.html - "Dynamic" or "compressed" sparsity patterns. edit: I was slower than Martin with my answer, but I'm to lazy to edit my answer :-) bye, Timo _______________________________________________
