Skip to content

Incorrect constraints in mesh deformation manager? #6589

@bangerth

Description

@bangerth

@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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions