Hello Wolfgang,

I went through the functions again and would be grateful if you could tell 
me if I have got understood anything wrong here:

In file p4est_wrappers.cc from line 46: 
1. As before, I would like to iterate over all the ghost layers to identify 
the cells over which I need to exchange the indices. The function that I 
think I would need to modify would be the 
compute_vertices_with_ghost_neighbors() which calls the p4est_iterate 
function. Considering one of the callbacks of this function, 
find_ghosts_corner() which takes the sides (of type dealii::internal::p4est
::iter<dim>::corner_side) variable and checks if any of the sides of that 
corner belong to a ghost cell using the cell_from_quad function. 


In this function, there are two for loops (line 64 to 74 and line 84 to 
97). First loop returns the ghost cell and gets the subdomain_id of that 
cell into the sc_array subids and the second loop adds this subdomain_id 
information to the vertices_with_ghost_neighbors.

I was wondering if it possible to also do something like this in the first 
loop as well:

                 
                  for (j = 0; j < nsubs; j++)
                  {
                    (*vertices_with_ghost_neighbors)[cell->vertex_index(
sides[i].corner)]
                    .insert (subdomain_ids[j]);
                  }


so that even the ghost cells to the first layer of ghost cells are added to 
the vertices_with_ghost_neighbors. Would this work ? Is there a better way ?

Thank you,
Pratik.
 

On Thursday, April 12, 2018 at 1:57:32 AM UTC-4, 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.

Reply via email to