How to deal with multiple IntegratorCell/Face objects using OperatorBase

[nfehn]

For the evaluation of the linearized operator in a nonlinear problem, we have multiple objects of type IntegratorCell/Face, one living as a member variable in OperatorBase, one living in a derived class, e.g. integrator_linearized in ElasticityOperator.

As mentioned by @kronbichler, the goal is to have local IntegratorCell/Face objects living in the scope of the cell_loop()/face_loop() functions. The question is then how to deisgn OperatorBase to be able to handle all possible cases and still make use of a base class implementation to realize a generic operator without code duplication. One possibility would be to generalize the interface of OperatorBase::reinit_cell(cell) towards:

void
OperatorBase::reinit_cell(std::vector<std::shared_ptr<IntegratorCell>> const & integrators, 
                          unsigned int const cell)
{
  for(auto & integrator : integrators)
    integrator->reinit(cell);
}

By overwriting reinit_cell() in derived classes, some problem-dependent initialization can be done as is the case currently

void
DerivedOperator::reinit_cell(std::vector<std::shared_ptr<IntegratorCell>> const & integrators, 
                             unsigned int const cell)
{
  OperatorBase::reinit_cell(integrators, cell);

  integrators[dof_index_nonlinear]->some_problem_dependent_reinit();
}

The indexing [dof_index_nonlinear] (with some consistency checks e.g. during setup to make sure the vector is set up and accessed correctly) might be seen as a disadvantage and I am not sure if a int-to-string-converting (as we do in order to handle dof-indices for MatrixFreeData/MatrixFree) would be acceptable in terms of performance when doing this for all (macro-)cells/faces of a grid.

@kronbichler what is your opinion?