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
Currently, OperatorBase receives affine constraints as a separate argument in initialization routines.
I consider this somewhat impractical / error prone. For example, in the IncNS module, we currently pass in an empty constraints object constraint_dummy for some operators (convective, viscous). However, it is hard to see whether this is a bug. Previously, when we had only a pure DG formulation (no Hdiv), there were no constraints in the IncNS module. Maybe, we then forgot to replace constraint_dummy in the setup of the operators, I am not sure.
Another aspect are the two dof-indices (dof_index and dof_index_inhomogeneous) that we have in OperatorBaseData since recent changes regarding the implementation of affine constraints for hanging nodes and inhomogeneous boundary data. From the current code version, it is hard to see which constraints OperatorBase actually expects to receive. This problem would not occur if the implementation in OperatorBase selects the constraints corresponding to OperatorBaseData::dof_index or OperatorBaseData::dof_index_inhomogeneous.
I think it would be good to have the affine constraints returned via MatrixFree, so I am in favor of such a change. There is one caveat, namely that MatrixFree::get_affine_constraints(dof_index) cannot return the constraints if the affine constraints object has a different Number type than MatrixFree (say one double and the other float). But I think we use consistent number types (possibly different in multigrid, but those have their own constraints and MatrixFree objects), so I think this should work.
Currently,
OperatorBase
receives affine constraints as a separate argument in initialization routines.I consider this somewhat impractical / error prone. For example, in the
IncNS
module, we currently pass in an empty constraints objectconstraint_dummy
for some operators (convective, viscous). However, it is hard to see whether this is a bug. Previously, when we had only a pure DG formulation (no Hdiv), there were no constraints in theIncNS
module. Maybe, we then forgot to replaceconstraint_dummy
in the setup of the operators, I am not sure.Another aspect are the two dof-indices (
dof_index
anddof_index_inhomogeneous
) that we have inOperatorBaseData
since recent changes regarding the implementation of affine constraints for hanging nodes and inhomogeneous boundary data. From the current code version, it is hard to see which constraintsOperatorBase
actually expects to receive. This problem would not occur if the implementation inOperatorBase
selects the constraints corresponding toOperatorBaseData::dof_index
orOperatorBaseData::dof_index_inhomogeneous
.@kronbichler what do you think?
The text was updated successfully, but these errors were encountered: