[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.htm>
More information about the Dune
mailing list