Matrix memory and n_nonzeros postprocessor.

[spco]

Addresses #1053. Outputs to screen. To help with what this looks like:

Number of active cells: 64 (on 4 levels)
Number of degrees of freedom: 1526 (578+81+289+289+289)

*** Timestep 15:  t=0.9375 seconds
   Solving temperature system... 10 iterations.
   Solving C_1 system ... 10 iterations.
   Solving C_2 system ... 9 iterations.
   Rebuilding Stokes preconditioner...
   Solving Stokes system... 8+0 iterations.

   Postprocessing:
     Temperature min/avg/max:               0 K, 0.4917 K, 1 K
     Compositions min/max/mass:             -0.001546/1.056/0.4167 // -0.001105/0.9944/0.4581
     System matrix memory consumption (MB): 0.440365

Total system matrix memory consumption: 0.440365 MB.
Total system matrix nnz: 33749
system matrix nnz by block: 
       14842        3116           0           0           0
        3116           0           0           0           0
           0           0        4225           0           0
           0           0           0        4225           0
           0           0           0           0        4225

Total system preconditioner matrix memory consumption: 0.292473 MB.
Total system preconditioner matrix nnz: 20826
system preconditioner matrix nnz by block: 
        7526           0           0           0           0
           0         625           0           0           0
           0           0        4225           0           0
           0           0           0        4225           0
           0           0           0           0        4225

[tjhei]

/run-tests

[tjhei]

Nice! This will be really useful to debug the DG sparsity patterns.

[tjhei]

I am okay to merge as is when the tests pass. @bangerth what do you think about adding a test to make sure we won't mess up the matrix in the future?

[spco]

I should probably update this to only output 2.d.p. for memory usage, in the vein of #1078. I'll push that in here as soon as I'm happy it works.

[spco]

Updated to only output 2 d.p.

[bangerth]

Looks good to me. I'm usually not the biggest fan of using screen output space, but in this case it's just a debugging aid and not meant to be informative to the average user. So this works for me.

I'd very much like to have a test for this. @spco -- can you add something like what you already show? The only test output worth saving is the screen-output file.

[spco]

The resume_free_surface test is failing for me, just like for @Shangxin-Liu in #1107. Again, this seems to be an unrelated issue.
Looking at the diff it seems like the resume_free_surface test is not generating solution-00009.0000.gnuplot1 or solution-00009.0000.gnuplot2. Is there something wrong with that test? My master and this branch are up-to-date.

[bangerth]

Hm, I would usually see whether @tjhei could take a look, but he's offline for the next couple of weeks.

Let's ignore this issue for now. Is the patch ready otherwise?

[spco]

Yes it's ready, unless we want to add the test I mentioned in #1051 in here.

[spco]

Does @ian-r-rose have any idea what might be happening, to make this test not create those files?

[bangerth]

I did apparently not look closely enough to this patch. In this function, can you:

• make the second argument a const reference
• break arguments onto separate lines
• I suspect that the function could be made const itself. In fact, I think the function doesn't actually have to be a member function, in which case it could just as well live in an anonymous namespace in the .cc file, rather than being part of the public interface.

[bangerth]

Let's keep #1051 separate. We can always add tests at a later time in independent pull requests.

[spco]

This latest should be good to go once all-1 tests have passed. I've pulled get_stats() out into an anonymous namespace, which just requires the MPI_COMM to be passed in, and fixed the constness/alignment.

I agree on keeping #1051 separate.

[bangerth]

There isn't actually a need to forward declare this function. In fact, forward declaring things in anonymous namespaces has no useful effect because every other .cc file that may #include this one would see this function in a different namespace than where it really is (because every .cc has a unique anonymous namespace). Just remove the declaration.

[bangerth]

Real close now!

[spco]

Such a taskmaster! ;) Fixed, and squashed. And something learned about forward declarations! Thanks.

[bangerth]

Yes, sorry. I'm a stickler for details :-( It makes me a good programmer, but a poor collaborator :-(