Thank you very much for answering. I'm saying that making a DynamicSparsityPattern by using the procedure described above is more expensive (from the memory point of view) respect using TrilinosWrappers::BlockSparsityPattern. I noted this trouble trying to run some test cases with a large number of unknowns (100 millions of dofs). In such cases, I get an out of memory error if I use DynamicSparsityPattern, whereas it works fine using TrilinosWrappers::BlockSparsityPattern. Investigating on smaller cases, I noted that a peak of memory usage occurs during the call of the function: DoFTools::make_sparsity_pattern(dof_handler, scratch_coupling, dsp, constraints, false, this_mpi_process); It means that the problem remains, even if the program runs until the end. As far as the analysis of memory consumption is concerned, I used the Massif tool from Valgrind.
Matteo Il giorno dom 6 ott 2019 alle ore 11:19 Wolfgang Bangerth < [email protected]> ha scritto: > > Matteo, > > > Especially large memory consumption occurs in the system setup phase. > > After some debugging, I was able to figure out that the part of the code > > responsible for this is the generation of the sparsity pattern, i.e., > the > > following rows: > > > > BlockDynamicSparsityPattern dsp(local_partitioning); > > DoFTools::make_sparsity_pattern(dof_handler, scratch_coupling, dsp, > > constraints, false, this_mpi_process); > > > > I wanted to point out that this behavior doesn't depend on PETSc, but it > is > > related only with the procedure wherewith we make the Block Sparsity > Pattern > > (BSP). Indeed I ran into the same issue with Trilinos > > if the above strategy is selected. > > > > In the previous version of the code, I used these rows to generate the > BSP: > > > > TrilinosWrappers::BlockSparsityPattern > sp(local_partitioning,MPI_COMM_WORLD); > > DoFTools::make_sparsity_pattern(dof_handler, matrix_coupling, > > sp, constraints, false, this_mpi_process); > > sp.compress(); > > > > In this last case, the amount of memory required to generate the BSP is > much > > less respect with the first case. > > Any ideas what is going on? Am I doing wrong something? > > What is the precise difference? Just the existence of the communicator > argument when creating the sparsity object? Or are you saying that > creating a > DynamicSparsityPattern > is expensive whereas creating a > TrilinosWrappers::SparsityPattern > is not? If so, do you think you could come up with a small testcase that > really just does that and nothing else, and that illustrates the problem? > > As a side note, how do you determine memory consumption? > > Best > W. > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: [email protected] > www: http://www.math.colostate.edu/~bangerth/ > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > --- > You received this message because you are subscribed to the Google Groups > "deal.II User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/62227886-8fd1-46f5-ab55-6161b5892878%40colostate.edu > . > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/CAAUoYWUocSJYwgD%3DbHSjbz90Sq35MSthF_XY-Wi2KFzKZwKo0w%40mail.gmail.com.
