Should we get rid of the DofVectors/DofSparseMatrices at the global level?

[Psirus]

trafficstars

If you look at the current Assembler implementation, a lot of the code is related to this split into DofTypes. The question is if we could get rid of these classes. That would simplify the assembler, we would have fewer FromEigen/ToEigen calls in our code, and no manual implementation of vector-matrix multiplication should you need it.

The main feature was that one could have separate residual norms for each dof type. This could also be accomplished with a free function if we had a mapping of which entries belonged to which dof type.

Do you see any downsides?

[joergfunger]

I personally see no downsides, but many simplifications. However, I would keep the DofVector (at least now) to store the current state (that might include dof_types currently not solved for). However, for the parameters passed via callbacks to the time integrations scheme (boost ode int or our Newton solver) I would only pass the vector of independent dofs with the current dof_types. This is because the time integration schemes only work on this (reduced) state - it should not know, how this reduced vector/matrix is actually created.

[Psirus]

Just a note: once this is done, skipping assembly of entries that are zero should get much easier and should be implemented.