[Dune] boundaries and ids

[Marco Cisternino]

I would like to say more about my problem:
I build my factory on process 0 adding vertices, elements and boundary. 
Then I create the grid.
Before loadbalancong the grid, I ask all the boundary intersections for 
their boundary ids.
And their boundary ids are wrong, better, not the boundary id I set in 
insertBoundary.

pseudo-code:
for(every line in my grid.bnd)
     read the vertices in vertex vector;
     read the boundaryId
     
factory_.insertBoundary(Dune::GeometryType(Dune::GeometryType::cube,dim-1),vertices,boundaryId);

factory_.createGrid()

for(every element)
     for(every intersection)
         intersection.boundaryId()

In a cube of 3x3x3 element I set 9 boundary intersection with id = 1 but 
I get 24 boundary intersections with boundaryId=1.
The result is the same after load balancing the grid on 2 processes.
What didn't I understand about boundaryId?

Thanks.

Marco



Il 05/03/2013 19:42, Marco Cisternino ha scritto:
> Hi duners,
> I have a problem with boundaries and integer ids.
> I'm using ALUGrid<3,3> and I create my grid from PROStar files(.cel 
> .vrt and .bnd) using a modification of mine of the starcdreader.hh.
> I use Dune 2.1.1.
> I use insertVertex, insertElement methods of the factory and I can 
> build my grid successfully. I didn't modified the part of 
> starcdreader.hh which does this.
> I added some lines of code to insert boundary faces and integers 
> labels (id) to apply boundary conditions.
> My problem is in the use of insertBoundary, specifically:
> insertBoundary(const GeometryType & geometry, const std::vector< 
> VertexId > & faceVertices, const int id)
>
> The smallest example I can think is a grid made of just one element:
> the vrt file:
> 1 0.475528 0 -0.154508 (index of the vertex and its position in 3D)
> 2 0 0.475528 -0.154508
> 3 0.293893 0 0.404508
> 4 0 0.293893 0.404508
> 5 0.951057 0 -0.309017
> 6 0 0.951057 -0.309017
> 7 0.587785 0 0.809017
> 8 0 0.587785 0.809017
> the cel file
> 1 1 2 4 3 5 6 8 7 1 1 1.0 (index of the element, 8 integers for the 
> vertices, 2 integers I don't use and one double for data to be 
> attached to the element)
> and the bnd file
> 1 1 3 7 5 1 0 PI01 (index of the boundary face 4 integers for the 
> vertices, the ID, one integer I don't use, a string for my boundary 
> conditions)
> 2 2 4 8 6 2 0 PO01
> 3 1 2 6 5 3 0 WA01
> 4 3 4 8 7 4 0 WA01
> 5 1 2 4 3 5 0 WA01
> 6 5 6 8 7 6 0 WA01
>
> When I read my bnd file I read the index, the vertices of the face 
> (putting them in a vector called vertices) and the ID (putting it in a 
> integer variable called boundaryId). Then I call:
> factory_.insertBoundary(Dune::GeometryType(Dune::GeometryType::cube,dim-1),vertices,boundaryId);
> Everything seems to go in the right way: compiler compiles, the code 
> runs without errors, BUT
> when I visit boundary intersection and I ask for
> intersection.boundaryId()
> the answer is not what I expected: for the case above the answer is 1, 
> no matter the boundary intersection I ask (I should get 1 2 3 4 5 6, 
> not necessarily in this order).
> Where's my mistake??
> I thought there was a way to label boundary faces(intersections) and I 
> thought the label would be communicated during amr and load balancing 
> automatically. Am I wrong??
>
> I hope that someone will be so kind to help me, because this is 
> crucial for my code.
>
> Thanks a lot for any hint.
>
> Bests,
>
> Marco
>
>
>
>
>
> -- 
> ------------------------------------
> Marco Cisternino, Ph.D.
> OPTIMAD Engineering s.r.l.
> Via Giacinto Collegno 18
> 10143 Torino - Italy
> www.optimad.it
> marco.cisternino at optimad.it
> +39 011 19719782
> ------------------------------------

-- 
------------------------------------
Marco Cisternino, Ph.D.
OPTIMAD Engineering s.r.l.
Via Giacinto Collegno 18
10143 Torino - Italy
www.optimad.it
marco.cisternino at optimad.it
+39 011 19719782
------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20130306/182e5515/attachment.htm>