Pde assembler

[TTitscher]

• Step towards #194
• Assembles directly into DofVector/DofMatrixSparse so somehow requires #164 to be 'wired' to the rest of NuTo. It may help Team JK (@Psirus @joergfunger ) though.
• Advantage over SimpleAssembler: Option to SetZero() the matrix and keep the nonzero entries for the next assembly.
• remark: It has not AddLumped method. IMO this should somehow be done in a LumpedCellAssembler or something that transforms the cell-vector into a matrix and calls MatrixAssembler::Add(...). Or is this too inefficient?

[codecov[bot]]

Codecov Report

Merging #236 into PDE_reviewed will increase coverage by 0.12%. The diff coverage is 94.52%.

@@               Coverage Diff                @@
##           PDE_reviewed     #236      +/-   ##
================================================
+ Coverage         84.41%   84.54%   +0.12%     
================================================
  Files               296      299       +3     
  Lines             10860    11000     +140     
================================================
+ Hits               9168     9300     +132     
- Misses             1692     1700       +8

Flag	Coverage Δ
#integrationtests	62.02% <100%> (ø)	:arrow_up:
#unittests	87.81% <94.52%> (+0.12%)	:arrow_up:

Impacted Files	Coverage Δ
nuto/mechanics/dofs/DofContainer.h	100% <100%> (ø)	:arrow_up:
test/mechanics/cell/Assembler.cpp	100% <100%> (ø)
nuto/mechanics/cell/Assembler.h	100% <100%> (ø)
nuto/mechanics/cell/Assembler.cpp	90.8% <90.8%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update e50fc48...627efd1. Read the comment docs.

[TTitscher]

I will add a static Add method for the VectorAssembler as well. I can also collect the static methods in a common namespace like

void Assembler::Add(DofVector& rVector, DofVector v, DofVector numbering);
void Assembler::Add(DofMatrixSparse& rMatrix, DofMatrix m, DofVector numbering);
void Assembler::Add(DofContainer<TripletList>& rTriplets, DofMatrix m, DofVector numbering);

I still like to keep the classes as they avoid reallocations without changing the syntax like:

MatrixAssembler assembler(...);
for (double t : timeSteps)
{
   const auto& K = BuildMatrix(assembler, cells.begin(), cells.end(), HessianFunction);
   // in the first call of this loop, a K will be build from a triplet list
   // the second time, the nonzeros are automatically reused and
   // assembly is done with `coeffRef`.
}

[joergfunger]

Can we assure that the sparsity pattern between different time steps does not change? In particular, we do not assemble entries that are almost zero. In case of e.g. the gradient damage model that stress is only a function of the nonlocal strains as soon as we exceed the damage initiation threshold. Thus, this part of the matrix is initially zero and thus cannot be accessed via coeffRef. Furthermore, what is the advantage of using this direct access using coeffRef?

[TTitscher]

In particular, we do not assemble entries that are almost zero.

Well, we probably should do that. Currently, we don't. In anyway, coeffRef will insert (possibly inefficient) the entry anyways. https://eigen.tuxfamily.org/dox/classEigen_1_1SparseMapBase_3_01Derived_00_01WriteAccessors_01_4.html#title6

Furthermore, what is the advantage of using this direct access using coeffRef?

It is not exactly coeffRef that makes the difference. I used it to indicate that we do not need the triplets and can reuse an existing matrix. When I profile my examples, 10%-20% of the time is spend in various memory allocation methods. This does not seem right. And I think that the biggest chunk of memory is the sparse matrix. In every iteration, we allocate the triplet lists, allocate a Eigen::SparseMatrix, deallocate triplet lists and deallocate the matrix. With the proposed assembler, this would be solved conveniently/automatically.