Wolfgang,
Thank you for your reply. If I understand it correctly, in step 4 of the
ParallelDistributed::distribute_dofs() function in the dof_handler.cc file
you compute and flag the cells that have ghost neighbours by looking at
only the vertices by calling the function
compute_vertices_with_ghost_neighbors() as you say above.
This uses the internal::p4est::p4est_iterate function to iterate the member
variable of the struct FindGhosts.vertices_with_ghosts_neighbors which is a
map of the cells and its subdomain id's through the find_ghost_faces() and
find_ghost_corners() for 2d and find_ghost_edges() functions as well for 3d
and flag those cells which have a face, corner or edge with.a ghost cell ?
I should be able to use this p4est_iterate function to search through the
cells (even ghosts) and add them to the map right ? I am not sure how to do
this. Could you please give me some pointers on this ?
If I understand correctly, the function p4est_iterate takes these function
pointers (find_ghost_faces() ... ) and user structs ( FindGhosts )and
iterates it through the parallel_forest. But I am not sure how to write a
function that searches through the ghost cells and flags them and if that
is all is needed for this and how do I make sure that the appropriate pairs
are flagged for receiving and sending from and to the appropriate domains ?
Thank you very much,
Pratik.
On Thursday, April 12, 2018 at 7:57:32 AM UTC+2, Wolfgang Bangerth wrote:
>
>
> > 1. I tried out the p4est_ghost_expand as Wolfgang suggested, but it
> gives me
> > an error because for some reason I get
> > if(cell->is_ghost){cell->user_flag_set()==true} after the calls
> > communicate_dof_indices_on_marked_cells() in dof_handler_policy.cc line
> 3875.
> > I believe the function communicate_dof_indices_on_marked_cells() in line
> 3492
> > in the same file exchanges the dof indices (sending the local cells that
> are
> > ghost somewhere else and receiving its ghost cells from other procs) but
> the
> > unpack function should identify all the cells marked as ghost and
> receive the
> > corresponding indices from the pack function, right ? Or have I
> misunderstood
> > something here ?
>
> Hm, good point. When we decide who each process needs to send the locally
> owned DoF indices to (so that they can be set on ghost cells on the
> receiving
> process), we determine the cells in question by asking whether one of
> their
> vertices is adjacent to a ghost cell -- in other words, whether a cell is
> at
> the boundary of the locally owned subdomain.
>
> But if you have more than one layer of ghost cells, then this is not
> enough. I
> think you need to extend the logic in a way where each process sends a
> list of
> its ghost cells to the owning process of these cells, and then gets the
> information back for exactly those cells. That may be a little bit of
> work,
> but I don't think it's going to be terribly difficult to implement. Let us
> know if you need help with this.
>
>
> > 2. All places in example 40 (my reference) for the matrix and rhs
> assembly,
> > you use the locally_relevant_dofs and locally_owned_dofs. As you say in
> the
> > Glossary
> > <
> http://dealii.org/developer/doxygen/deal.II/DEALGlossary.html#GlossParallelScaling>,
>
>
> > for locally_active_dofs
> >
> > " Since degrees of freedom are owned by only one processor, degrees of
> freedom
> > on interfaces between cells owned by different processors may be owned
> by one
> > or the other, so not all degrees of freedom on a locally owned cell are
> also
> > locally owned degrees of freedom."
> >
> > And hence you assemble your local matrices with the locally_owned_dofs.
> But
> > for the overlapped decomposition, I need to assemble matrices including
> the
> > "ghost cells" . In my case, they wouldn't be ghost cells but locally
> owned
> > cells but duplicated between logically overlapping processes. I am not
> really
> > sure how to go about doing this.
>
> This is what I tried to explain in my previous email: on each process, you
> need a separate enumeration of all degrees of freedom that live on that
> process (either on locally owned or ghost cells). This enumeration must be
> independent of the "global" enumeration we typically use in deal.II which
> uniquely splits up all DoF indices among the processors.
>
> Best
> W.
>
> --
> ------------------------------------------------------------------------
> Wolfgang Bangerth email: bang...@colostate.edu
> <javascript:>
> www: http://www.math.colostate.edu/~bangerth/
>
>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
