[Dune] boundarySegmentIndex

Marco Cisternino marco.cisternino at optimad.it
Fri Jan 11 17:30:47 CET 2013


In the documentation (of Intersection) about boundarySegmentIndex() I 
read this:
"Handling physical boundaries:
Data (like the type of boundary) can be attached to physical boundaries 
either using global coordinates or the intersection's boundary segment 
index.
The boundary segment indices form a local, zero-based, contiguous set of 
integer values. Each boundary segment on the macro level is assigned a 
unique index from this set, which is inherited by child boundary 
segments. The size of the boundary segment index set (i.e., the number 
of boundary indices on the macro level) can be determined through the 
method Grid::numBoundarySegments.
Note that the boundary segment index is not persistent over dynamic load 
balancing."

In my code, the grid (AluCubeGrid<3,3>) as 54 boundary intersections 
like a cube grid with 3^3 elements.
I launch the code on 2 processes. I expected that the sum of the two 
values given by the method numBoundarySegments() were 54, but it's not.
After the reading from input file and balancing the grid, the two 
processes should have, looking at the VTK output file, 34 and 20 
boundary intersections.
With this piece of code:
     LeafElementIterator endit = 
leafGridView.end<0,Dune::InteriorBorder_Partition>();
     for(LeafElementIterator it = 
leafGridView.begin<0,Dune::InteriorBorder_Partition>(); it != endit; ++it)
       {
         LeafElementIterator::Entity& entity = *it;
         LeafGridView::IntersectionIterator iend = 
leafGridView.iend(entity);
         for(LeafGridView::IntersectionIterator ii = 
leafGridView.ibegin(entity); ii != iend; ++ii)
           {
             const LeafGridView::IntersectionIterator::Intersection & in 
= *ii;
             if(in.boundary())
               {
             std::cout << "rank: " << helper.rank() << " boundaryIdx: " 
<< in.boundarySegmentIndex() << std::endl;
               }
           }
       }
     std::cout << "rank: " << helper.rank() << "BS = " << 
grid.numBoundarySegments() << std::endl;

I ask for boundary intersection indices and for the number of boundary 
segments.
But the answer is quite weird.
Rank 0 answers:
rank: 0 boundaryIdx: 32
rank: 0 boundaryIdx: 31
rank: 0 boundaryIdx: 30
rank: 0 boundaryIdx: 6
rank: 0 boundaryIdx: 18
rank: 0 boundaryIdx: 33
rank: 0 boundaryIdx: 7
rank: 0 boundaryIdx: 19
rank: 0 boundaryIdx: 35
rank: 0 boundaryIdx: 21
rank: 0 boundaryIdx: 37
rank: 0 boundaryIdx: 13
rank: 0 boundaryIdx: 23
rank: 0 boundaryIdx: 40
rank: 0 boundaryIdx: 39
rank: 0 boundaryIdx: 8
rank: 0 boundaryIdx: 41
rank: 0 boundaryIdx: 9
rank: 0 boundaryIdx: 42
rank: 0 boundaryIdx: 43
rank: 0 boundaryIdx: 15
rank: 0 boundaryIdx: 46
rank: 0 boundaryIdx: 45
rank: 0 boundaryIdx: 51
rank: 0 boundaryIdx: 10
rank: 0 boundaryIdx: 24
rank: 0 boundaryIdx: 47
rank: 0 boundaryIdx: 11
rank: 0 boundaryIdx: 25
rank: 0 boundaryIdx: 48
rank: 0 boundaryIdx: 27
rank: 0 boundaryIdx: 49
rank: 0 boundaryIdx: 17
rank: 0 boundaryIdx: 29 (I add here their number: 34)
rank: 0BS = 46
And Rank 1:
rank: 1 boundaryIdx: 1
rank: 1 boundaryIdx: 0
rank: 1 boundaryIdx: 2
rank: 1 boundaryIdx: 4
rank: 1 boundaryIdx: 6
rank: 1 boundaryIdx: 3
rank: 1 boundaryIdx: 7
rank: 1 boundaryIdx: 5
rank: 1 boundaryIdx: 8
rank: 1 boundaryIdx: 9
rank: 1 boundaryIdx: 10
rank: 1 boundaryIdx: 11
rank: 1 boundaryIdx: 12
rank: 1 boundaryIdx: 16
rank: 1 boundaryIdx: 17
rank: 1 boundaryIdx: 13
rank: 1 boundaryIdx: 14
rank: 1 boundaryIdx: 18
rank: 1 boundaryIdx: 15
rank: 1 boundaryIdx: 19 (I add here their number: 20)
rank: 1BS = 32

The number of boundary segments is not exactly the number of boundary 
segments on the whole grid, but rather the number on boundary segments 
of the process sub-domain!! Moreover, while the indices of rank 1 are 
consistent with the documentation
"The boundary segment indices form a local, zero-based, contiguous set 
of integer values"
and the number of boundary intersections is exactly the number I can see 
in the VTK file (20), I really don't understand what's happening to rank 0:
the number of boundary intersections is correct (34), but the number of 
boundary segments is again the number of the boundary segments of the 
subdomain(46), but, more weirdly, the indices are meaningless!!!  As you 
can see, some of them are indexed with integers bigger than not only 34 
but also 46.
If I repeat this procedure after a local refinement the method 
numBoundarySegments gives exactly the same values and the indices are 
crazy, absolutely far from what the documentation says:
"Each boundary segment on the macro level is assigned a unique index 
from this set, which is inherited by child boundary segments."

Any suggestions, please??
I don't care too much about the values given by numBoundarySegments, 
even if it would comfortable to have good results, but I don't know how 
to store boundary conditions without a consistent index set.
Thank you for any help.
Bests,


Marco



Il 11/01/2013 12:00, dune-request at dune-project.org ha scritto:
> Send Dune mailing list submissions to
> 	dune at dune-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.dune-project.org/mailman/listinfo/dune
> or, via email, send a message with subject or body 'help' to
> 	dune-request at dune-project.org
>
> You can reach the person managing the list at
> 	dune-owner at dune-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dune digest..."
>
>
> Today's Topics:
>
>     1. Re: geometrygrid and PSurface (Oliver Sander)
>     2. boundarySegmentIndex (Marco Cisternino)
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune

-- 
Marco Cisternino, Ph.D.
Optimad Engineering s.r.l.
www.optimad.it
marco.cisternino at optimad.it
+3901119719782

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20130111/0f6dfb33/attachment-0001.html>


More information about the Dune mailing list