Remove/Redesign CellInterface

[TTitscher]

In our todays meeting, @joergfunger and me, both rather independently came up with the idea of a NewmarkCell or TimedependentCell, with Gradient, Hessian123, .... I am aware that we discussed that before and decided for the more general approach of Cell::Integrate(Vector/MatrixFunction) instead.

The new idea, however, is the removal of a common cell base class. So we can have both. On the one side, the current all purpose Cell. On the other hand, specialized cells that only work with certain integrands and simplify the use of time integration schemes. With #194 done, they should all be "orthogonal" to the assembler(s). Some possibilities:

• TimeDependentCell that integrates a TimeDependentIntegrand (obviously, you can still use this integrand via bind with the general Cell)
• Why define a cell, when a FreeFunction::Integrate(element, integrationType, function) is enough?
• Define a cell where a single instance has multiple elements.

Problem - Visualize:

For the most simple visualization we need two main features:

1. interpolate dof values and coordinates to arbitrary natural coordinates
2. identify the shape

We often want to also visualize complex data from integration points. This requires:

3. access to integration point data, integrands and dof values

Mainly for feature 3., we chose to visualize a group of CellInterface, as it seems natural for them to loop over integration points. But they to not really integrate, but evaluate. And for feature 1 and 2, a group of ElementCollection also seems nice. Especially, since the Cell::Interpolate(...) only forwards to the ElementInterface

Solution ideas:

1. Keep a common CellVisualizeInterface that provides the three features above.
2. Visualize ElementCollection instead and treat the integration point stuff as a special feature. E.g. it could be provided by as captured variables in a visualize functions.

So I mainly want to know if you like the idea and if it is worth to think further in this direction.

[joergfunger]

I also support the idea, some remarks from my side. Why do you say "They should all be orthogonal to the assembler?". IMO, similar to #194, the assembler would just get a full and a sparse matrix and assemble those. In this context, I guess you mean the list of cells that we have to store at some point, which would require a common base class if both options could be mixed (or used separately, but both in the same time integration scheme). I agree that both options should not have a common base class.

Regarding the options

1. TimeDependent Cell - I like the idea
2. Free function - this is an "out of the box" idea, but the more I think about it, the more appealing it seems to be. The cell was originally designed to track store the history data and reference to the interpolation. Since the tracking of history data is "outsourced", we could really get rid of the cell. However, this means that we also have to think a little bit more thoroughly about the ElementInterface, since instead of looping over cells to compute the global matrices, we will have to loop over ElementInterfaces. We would also have to store at some point, which integration type we want to use. Even though we could do this somewhere outside (e.g. store for each integration type the corresponding list of ElementInterfaces), this does not seem to be like a consistent idea, e.g. how can we assure that the integration point data fits (say you usually use 4 integration points per cell, but than evaluating your response with an integration type with only 3 ips will give you a result, but totally wrong)
3. I don't understand this last proposal

Regarding the Visualize Option 1 (CellVisualize) seems to be closest to the current implementation. However, I very much like the second idea (visualize element collection) and use captured variables for the other parameters. This is in particular relevant, if we decide to remove the NodeMerge, since in this case we would also have to provide a way how to generally transfer dof values (different types depending on your problem, e.g. d,v,a,t,dt) to the Cell/ElementInterface for visualization purposes.

[TTitscher]

Orthogonal may have been the wrong word. I mean we can assemble arbitrary cell types with arbitrary assemblers. Their common generic interface (no interface classes) is that all cells can somehow return matrix/vector+numbering and all assemblers take matrix/vector+numbering.

Point 3. could be a ConstantJacobianCell where each element has the same jacobian that is stored once (for each IP) in this cell, as well the B matrices. Could be solved differently though.

[Psirus]

Personally, I'm fine with multiple cell types. The only fear I have has been shrugged off with "obviously, you can still use this integrand via bind with the general Cell". If that works out, fine.

I fear, however, that TimeDependentProblem, TimeDependentCell and TimeDependentIntegrand will diverge from the rest. First in small but subtle ways, and at some point the whole idea of "write integrand once, use with any cell" and "write cell once, use with any time integration scheme" goes out of the window. And then you have a loose collection of integrands, cells and time-integration schemes, and nobody knows what is compatible with what any-more.

[TTitscher]

And then you have a loose collection of integrands, cells and time-integration schemes, and nobody knows what is compatible with what any-more.

One way of solving it could be a TimeDependentInterface or a NewmarkInterface for the time integration schemes. In the cell-bind approach, you implement that interface it almost exactly how it is currently done, with TimeDependentGradientFunction and such. For the TimeDependentCells, you can omit these intermediate functions and call cell.Gradient(...) directly. I mean, we can always replace an interface with multiple std::function or template lambdas, see NewtonRaphson. But on such a high level, I prefer interfaces since I find them easier to implement - e.g. IDE hints.

And you are definitely right that we need to ensure that the general way works besides the convenient wrapper/interface.