-
Notifications
You must be signed in to change notification settings - Fork 248
Description
@tjhei This is mostly a question for you. In mesh_deformation/interface.cc
, we build the surface velocity constraints like so (slightly simplified):
// Ask all plugins to add their constraints.
// For the moment add constraints from all plugins into one object, then
// merge that matrix with the existing constraints (respecting the existing
// constraints as more important).
//
// We initialize the constraints object with the locally
// relevant DoF indices as the set of constraints to store (also
// using the locally relevant indices for the "locally owned"
// DoFs). This way, plugins can fill information for all locally
// relevant DoFs and we do not need to communicate.
AffineConstraints<double> plugin_constraints(mesh_vertex_constraints.get_local_lines(),
mesh_vertex_constraints.get_local_lines());
for (const auto &boundary_id : mesh_deformation_objects)
{
std::set<types::boundary_id> boundary_id_set;
boundary_id_set.insert(boundary_id.first);
for (const auto &model : boundary_id.second)
{
AffineConstraints<double> current_plugin_constraints(mesh_vertex_constraints.get_local_lines(),
mesh_vertex_constraints.get_local_lines());
model->compute_velocity_constraints_on_boundary(mesh_deformation_dof_handler,
current_plugin_constraints,
boundary_id_set);
...copy current_plugin_constraints into plugin_constraints...
}
}
Here, we initialize the AffineConstraints
objects with two copies of mesh_vertex_constraints.get_local_lines()
, which is initialized via mesh_vertex_constraints.reinit(mesh_deformation_dof_handler.locally_owned_dofs(), mesh_locally_relevant);
and so we use the "locally relevant indices" for both index sets. This is on the safe side, and plugins can fill information on both locally owned and ghost DoFs. This is fine, but it assumes that plugins actually have information about ghost DoFs too.
Wouldn't it be safer if we initialized the constraints object with (locally owned, locally relevant)
and then later on called make_consistent_in_parallel()
? I'm concerned, for example, that once you fill the missing pieces of #6584, we interpolate back onto the DoFs on one cell where only some of the DoFs are locally owned and some are owned by a neighboring ghost cell. I would feel more comfortable if we called make_consistent_in_parallel()
to support that, and for that the set of "locally owned" DoFs stored in the AffineConstraints
object must be non-overlapping with other processes (which currently it isn't because we use locally_relevant
for both arguments of the constructor).