The dofmap indices of neighbor element out of the local range in parallel DG methods.

[Ricardotu]

Hello, in DG method we often need to use soln(neighbor_indices) in the residual function, it's works ok. How is it ensure that neighbor_indices do not surpass the control range of the local processor? For instance, consider a mesh with 4 elements and 16 degrees of freedom, utilizing two processors. on every processor, solution local size is about 8, but neighbor_indicesrange is
[0, 16).
when i want to use in my funciton, it went wrong in std::cout << (*alphaEdown)(neighbor_dof_indices_dg0[0]) << std::endl; in two processor but successfully in one processor. my code is quite bulky; I've removed most of it, retaining the essential details.:

void lavg(std::unique_ptr<NumericVector<Number>> &H0,
          std::unique_ptr<NumericVector<Number>> &H1,
          std::unique_ptr<NumericVector<Number>> &S0,
          std::unique_ptr<NumericVector<Number>> &S1, EquationSystems &es)
{
  TransientNonlinearImplicitSystem &sys =
      es.get_system<TransientNonlinearImplicitSystem>("twophase");
  ExplicitSystem &dg0_sys = es.get_system<ExplicitSystem>("dg0_sys");
  
  const MeshBase &mesh = es.get_mesh();
  std::unique_ptr<NumericVector<Number>> alphaEdown = S0->zero_clone();
  std::vector<dof_id_type> neighbor_dof_indices_dg0;
  for (const auto &elem : mesh.active_local_element_ptr_range())
  {
    dof_map_dg0.dof_indices(elem, dof_indices_dg0);
    alphaEdown->set(dof_indices_dg0[0], std::min(1.0, ````);
  }
  alphaEdown->close();

  for (const auto &elem : mesh.active_local_element_ptr_range())
  {
    dof_map_dg0.dof_indices(elem, dof_indices_dg0);

    for (auto side : elem->side_index_range())
    {
      if (elem->neighbor_ptr(side) == nullptr)
      {
     `````
      }
      else
      {
        dof_map_dg0.dof_indices(neighbor, neighbor_dof_indices_dg0);
        std::cout << (*alphaEdown)(neighbor_dof_indices_dg0[0]) << std::endl;
      }
    }
  }
}```

[jwpeterson]

I think the answer here depends on what kind of vector S0 is. Since alphaEdown is copied from that, it will have the same ParallelType (two possibilities are PARALLEL, GHOSTED). If it's a PARALLEL vector, then it won't necessarily have access to set all DOFs of active_local elements.

[Ricardotu]

 It is a copy of system.solution, which has one MONOMIAL 0 order variable.在 2023年12月22日，00:43，John W. Peterson ***@***.***> 写道： I think the answer here depends on what kind of vector S0 is. Since alphaEdown is copied from that, it will have the same ParallelType (two possibilities are PARALLEL, GHOSTED). If it's a PARALLEL vector, then it won't necessarily have access to set all DOFs of active_local elements. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[lindsayad]

system.solution is a PARALLEL vector. You probably want to query system.current_local_solution instead