You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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 inOperatorBase
, one living in a derived class, e.g.integrator_linearized
inElasticityOperator
.As mentioned by @kronbichler, the goal is to have local
IntegratorCell/Face
objects living in the scope of thecell_loop()
/face_loop()
functions. The question is then how to deisgnOperatorBase
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 ofOperatorBase::reinit_cell(cell)
towards:By overwriting
reinit_cell()
in derived classes, some problem-dependent initialization can be done as is the case currentlyThe 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 forMatrixFreeData
/MatrixFree
) would be acceptable in terms of performance when doing this for all (macro-)cells/faces of a grid.@kronbichler what is your opinion?
The text was updated successfully, but these errors were encountered: