Make sure particle fields do not create a matrix block

[gassmoeller]

to save memory. Do this by specifying Coupling::None for the SparsityPattern

[tjhei]

see #1053 to check if it really worked.

[spco]

I'm just looking into this. Here's the parameter file I use:
matrix_nonzeros_particles.txt

This generates output

-----------------------------------------------------------------------------
-- This is ASPECT, the Advanced Solver for Problems in Earth's ConvecTion.
--     . version 1.5.0-pre
--     . running in DEBUG mode
--     . running with 1 MPI process
--     . using Trilinos
-----------------------------------------------------------------------------

Number of active cells: 16 (on 3 levels)
Number of degrees of freedom: 412 (162+25+144+81)

*** Timestep 0:  t=0 seconds
   Solving temperature system... 0 iterations.
   Solving C_1 system ... 0 iterations.
   Rebuilding Stokes preconditioner...
   Solving Stokes system... 22+0 iterations.

   Postprocessing:
     Writing particle output: output/particles/particles-00000

Total system matrix memory consumption: 0.16 MB.
Total system matrix nnz: 12393
system matrix nnz by block: 
        4356         882           0           0
         882           0           0           0
           0           0        5184           0
           0           0           0        1089

Total system preconditioner matrix memory consumption: 0.12 MB.
Total system preconditioner matrix nnz: 8620
system preconditioner matrix nnz by block: 
        2178           0           0           0
           0         169           0           0
           0           0        5184           0
           0           0           0        1089


Termination requested by criterion: end time


+---------------------------------------------+------------+------------+
| Total wallclock time elapsed since start    |     0.319s |            |
|                                             |            |            |
| Section                         | no. calls |  wall time | % of total |
+---------------------------------+-----------+------------+------------+
| Assemble Stokes system          |         1 |    0.0219s |       6.9% |
| Assemble composition system     |         1 |    0.0205s |       6.4% |
| Assemble temperature system     |         1 |    0.0327s |        10% |
| Build Stokes preconditioner     |         1 |    0.0193s |       6.1% |
| Build composition preconditioner|         1 |   0.00023s |     0.072% |
| Build temperature preconditioner|         1 |     0.003s |      0.94% |
| Solve Stokes system             |         1 |   0.00751s |       2.4% |
| Solve composition system        |         1 |  0.000521s |      0.16% |
| Solve temperature system        |         1 |  0.000822s |      0.26% |
| Initialization                  |         1 |     0.106s |        33% |
| Particles: Advect               |         2 |    0.0472s |        15% |
| Particles: Generate             |         1 |   0.00364s |       1.1% |
| Particles: Initialization       |         1 |  0.000555s |      0.17% |
| Particles: Output               |         1 |   0.00257s |      0.81% |
| Particles: Sort                 |         2 |   0.00235s |      0.74% |
| Postprocessing                  |         1 |    0.0527s |        17% |
| Setup dof systems               |         1 |    0.0359s |        11% |
| Setup initial conditions        |         1 |    0.0107s |       3.4% |
+---------------------------------+-----------+------------+------------+

Program ended with exit code: 0

This is using 1 composition field, so it looks like particles don't create a matrix block (this is true with both single and multiple MPI processes, but with different matrix nnz as these are treated differently in #1100 thanks to the dG temperature field).

(Please correct me if I'm doing something wrong - I have zero experience of using particles!)

Do we want a test (ie the one above) added to ensure this behaviour later, or are we happy to have proved it to ourselves once? Or would it be better to explicitly specify Coupling::None as @gassmoeller suggests?

[gassmoeller]

Hi Sam,
sorry for the too brief description. This issue is currently only possible to test on the branch of #1007, because only with these changes you can designate a particular compositional field as being advected on particles and not solved as regular field. In that case (i.e. for every field that is designated as representation of the particle properties) we should not create a matrix block, but currently we simply create matrix blocks for every field. But before we settle on the exact implementation of #1007, this issue is not easily solvable (or at least you would need to update your fix to the updates of #1007, so I would suggest to pause this issue for now).

[spco]

Ok, thanks René - I will leave this to you!

On Wed, 13 Jul 2016 18:06 Rene Gassmöller, notifications@github.com wrote:

Hi Sam,
sorry for the too brief description. This issue is currently only possible
to test on the branch of #1007
#1007, because only with
these changes you can designate a particular compositional field as being
advected on particles and not solved as regular field. In that case (i.e.
for every field that is designated as representation of the particle
properties) we should not create a matrix block, but currently we simply
create matrix blocks for every field. But before we settle on the exact
implementation of #1007 #1007,
this issue is not easily solvable (or at least you would need to update
your fix to the updates of #1007
#1007, so I would suggest to
pause this issue for now).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1051 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ALEqcuV5afpsQe0IbhDSLX-3jJgJQ06Sks5qVRsAgaJpZM4JBXuX
.