[deal.II] Re: Marking cells at interface between subdomains

2023-03-21 Thread jose.a...@gmail.com
Hi Peter,

Thanks a lot for the suggestion. With it I think I managed to achieved the 
desired effect. First, I populated a 
LinearAlgebra::distributed::Vector with the material ids and called 
the update_ghost_values() method afterwards. In a second 
active_cell_iterator I used said vector and the global_active_cell_index() 
of each cell pair for the boolean comparison of the material id. I could 
not do a visual verification due to the assertion data_vector.size() == 
triangulation->n_active_cells() inside the add_data_vector() method with 
DataVectorType::type_cell_data as third argument, i.e., 

data_out.add_data_vector(
  cell_is_at_interface,
  "cell_is_at_interface",
  dealii::DataOut_DoFData, dim, 
dim>::DataVectorType::type_cell_data);

The assertion does not hold for a distributed vector as 
n_global_active_cells > n_active_cells. Maybe this is not the correct 
method for LinearAlgebra::distributed::Vector? Nevertheless, I 
instead counted the amount of times the boolean comparison was true and it 
coincides with what it is expected from the amount of global refinements of 
the unit square (with 3 global refinements there are a total of 16 cells at 
the interface) and I checked the x-coordinate of the cells' center to 
verify that it is indeed at the interface.

It seems that when working in parallel out of the methods 
CellAccessor::material_id(), CellAccessor::active_fe_index() and 
CellAccessor::global_active_cell_index(), only the latter returns the 
correct value when called from a neighbor cell outside the locally owned 
subdomain. I could observe this when printing the global_active_cell_index, 
active_fe_index and the material_id pairs each the the boolean comparison 
was true. Here are the results in serial

Global active cell index pair ( 5, 16) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair ( 7, 18) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (13, 24) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (15, 26) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (16,  5) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)
Global active cell index pair (18,  7) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)
Global active cell index pair (24, 13) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)
Global active cell index pair (26, 15) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)
Global active cell index pair (37, 48) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (39, 50) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (45, 56) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (47, 58) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (48, 37) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)
Global active cell index pair (50, 39) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)
Global active cell index pair (56, 45) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)
Global active cell index pair (58, 47) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)

and in parallel (-np 3)

Global active cell index pair (24, 13) with active_fe_index pair ( 2, 
 0) and material_id pair ( 2,  0)
Global active cell index pair (26, 15) with active_fe_index pair ( 2, 
 0) and material_id pair ( 2,  0)
Global active cell index pair (37, 48) with active_fe_index pair ( 1, 
 0) and material_id pair ( 1,  0)
Global active cell index pair (45, 56) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (47, 58) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (48, 37) with active_fe_index pair ( 2, 
 0) and material_id pair ( 2,  0)
Global active cell index pair (50, 39) with active_fe_index pair ( 2, 
 0) and material_id pair ( 2,  0)
Global active cell index pair (56, 45) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)
Global active cell index pair (58, 47) with active_fe_index pair ( 2, 
 1) and material_id pair ( 2,  1)
Global active cell index pair ( 5, 16) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair ( 7, 18) with active_fe_index pair ( 1, 
 2) and material_id pair ( 1,  2)
Global active cell index pair (13, 24) with active_fe_index pair ( 1, 
 0) and material_id pair ( 1,  0)
Global active cell index pair (15, 26) with active_fe_index pair ( 1, 
 0) and material_id pair ( 1,  0)
Global active cell index pair (16,  5) with 

[deal.II] Re: Marking cells at interface between subdomains

2023-03-21 Thread Peter Munch


Hi Jose,

not sure. You could use 
Triangulation::global_active_cell_index_partitioner() to initialize a 
distributed vector, access it via CellAccessor::global_active_cell_index(), 
and update the ghost values.

Peter
On Tuesday, March 21, 2023 at 10:47:14 AM UTC+1 jose.a...@gmail.com wrote:

> Hello dealii community,
>
> I am working on a problem with several subdomains. At the interface 
> between them a boundary integral is to be evaluated. I am identifying the 
> interface by comparing the material_id of neighboring cells (or their 
> active_fe_index as I am using a different FESystem per subdomain). In order 
> to speed up the search during assembly, a Vector is previously 
> filled with 1.0 at the cells where the material_id/active_fe_index differ. 
> This approach works in serial but in parallel the material_id() call of a 
> neighbor cell outside the locally owned subdomain always returns 0 (An 
> assertion is missing here). As such, not only the interface between 
> subdomains is marked but also the interface between locally owned 
> subdomains, as shown in the attached picture
>
> My question is, if there is an equivalent to locally owned and relevant 
> dofs for the case of cells, i.e., locally owned and relevant cells such 
> that the material_id/active_fe_index of the neighboring cell outside the 
> locally owned subdomain can be read? Alternatively, is there a built-in 
> method/member which can be used for my purpose or someone has already done 
> it through another approach?
>
> Attached is also the MWE used to obtain the attached screenshot.
>
> Cheers,
> Jose
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/ea5b77e3-50f4-48bb-8269-238e4712a62en%40googlegroups.com.