<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<span style="color: rgb(0, 0, 0); font-family: sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; background-color: rgb(251, 252,
253); font-size: medium; display: inline ! important; float:
none;">In the documentation (of Intersection) about
boundarySegmentIndex() I read this:<br>
"Handling physical boundaries:<br>
Data (like the type of boundary) can be attached to physical
boundaries either using global coordinates or the intersection's
boundary segment index.<br>
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.<br>
Note that the boundary segment index is not persistent over
dynamic load balancing."<br>
<br>
In my code, the grid (AluCubeGrid<3,3>) as 54 boundary
intersections like a cube grid with 3^3 elements.</span><br>
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.<br>
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.<br>
With this piece of code:<br>
LeafElementIterator endit =
leafGridView.end<0,Dune::InteriorBorder_Partition>();<br>
for(LeafElementIterator it =
leafGridView.begin<0,Dune::InteriorBorder_Partition>(); it !=
endit; ++it)<br>
{<br>
LeafElementIterator::Entity& entity = *it;<br>
LeafGridView::IntersectionIterator iend =
leafGridView.iend(entity);<br>
for(LeafGridView::IntersectionIterator ii =
leafGridView.ibegin(entity); ii != iend; ++ii)<br>
{<br>
const LeafGridView::IntersectionIterator::Intersection
& in = *ii;<br>
if(in.boundary())<br>
{<br>
std::cout << "rank: " << helper.rank()
<< " boundaryIdx: " << in.boundarySegmentIndex()
<< std::endl;<br>
}<br>
}<br>
}<br>
std::cout << "rank: " << helper.rank() << "BS
= " << grid.numBoundarySegments() << std::endl;<br>
<br>
I ask for boundary intersection indices and for the number of
boundary segments.<br>
But the answer is quite weird.<br>
Rank 0 answers:<br>
rank: 0 boundaryIdx: 32<br>
rank: 0 boundaryIdx: 31<br>
rank: 0 boundaryIdx: 30<br>
rank: 0 boundaryIdx: 6<br>
rank: 0 boundaryIdx: 18<br>
rank: 0 boundaryIdx: 33<br>
rank: 0 boundaryIdx: 7<br>
rank: 0 boundaryIdx: 19<br>
rank: 0 boundaryIdx: 35<br>
rank: 0 boundaryIdx: 21<br>
rank: 0 boundaryIdx: 37<br>
rank: 0 boundaryIdx: 13<br>
rank: 0 boundaryIdx: 23<br>
rank: 0 boundaryIdx: 40<br>
rank: 0 boundaryIdx: 39<br>
rank: 0 boundaryIdx: 8<br>
rank: 0 boundaryIdx: 41<br>
rank: 0 boundaryIdx: 9<br>
rank: 0 boundaryIdx: 42<br>
rank: 0 boundaryIdx: 43<br>
rank: 0 boundaryIdx: 15<br>
rank: 0 boundaryIdx: 46<br>
rank: 0 boundaryIdx: 45<br>
rank: 0 boundaryIdx: 51<br>
rank: 0 boundaryIdx: 10<br>
rank: 0 boundaryIdx: 24<br>
rank: 0 boundaryIdx: 47<br>
rank: 0 boundaryIdx: 11<br>
rank: 0 boundaryIdx: 25<br>
rank: 0 boundaryIdx: 48<br>
rank: 0 boundaryIdx: 27<br>
rank: 0 boundaryIdx: 49<br>
rank: 0 boundaryIdx: 17<br>
rank: 0 boundaryIdx: 29 (I add here their number: 34)<br>
rank: 0BS = 46<br>
And Rank 1:<br>
rank: 1 boundaryIdx: 1<br>
rank: 1 boundaryIdx: 0<br>
rank: 1 boundaryIdx: 2<br>
rank: 1 boundaryIdx: 4<br>
rank: 1 boundaryIdx: 6<br>
rank: 1 boundaryIdx: 3<br>
rank: 1 boundaryIdx: 7<br>
rank: 1 boundaryIdx: 5<br>
rank: 1 boundaryIdx: 8<br>
rank: 1 boundaryIdx: 9<br>
rank: 1 boundaryIdx: 10<br>
rank: 1 boundaryIdx: 11<br>
rank: 1 boundaryIdx: 12<br>
rank: 1 boundaryIdx: 16<br>
rank: 1 boundaryIdx: 17<br>
rank: 1 boundaryIdx: 13<br>
rank: 1 boundaryIdx: 14<br>
rank: 1 boundaryIdx: 18<br>
rank: 1 boundaryIdx: 15<br>
rank: 1 boundaryIdx: 19 (I add here their number: 20)<br>
rank: 1BS = 32<br>
<br>
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<br>
"<span style="color: rgb(0, 0, 0); font-family: sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; background-color: rgb(251, 252,
253); font-size: medium; display: inline ! important; float:
none;">The boundary segment indices form a local, zero-based,
contiguous set of integer values</span>"<br>
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:<br>
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.<br>
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:<br>
"<span style="color: rgb(0, 0, 0); font-family: sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; background-color: rgb(251, 252,
253); font-size: medium; display: inline ! important; float:
none;">Each boundary segment on the macro level is assigned a
unique index from this set, which is inherited by child boundary
segments.</span>"<br>
<br>
Any suggestions, please??<br>
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.<br>
Thank you for any help.<br>
Bests,<br>
<br>
<br>
Marco<br>
<br>
<br>
<br>
Il 11/01/2013 12:00, <a class="moz-txt-link-abbreviated" href="mailto:dune-request@dune-project.org">dune-request@dune-project.org</a> ha scritto:
<blockquote
cite="mid:mailman.4.1357902002.23251.dune@dune-project.org"
type="cite">
<pre wrap="">Send Dune mailing list submissions to
<a class="moz-txt-link-abbreviated" href="mailto:dune@dune-project.org">dune@dune-project.org</a>
To subscribe or unsubscribe via the World Wide Web, visit
<a class="moz-txt-link-freetext" href="http://lists.dune-project.org/mailman/listinfo/dune">http://lists.dune-project.org/mailman/listinfo/dune</a>
or, via email, send a message with subject or body 'help' to
<a class="moz-txt-link-abbreviated" href="mailto:dune-request@dune-project.org">dune-request@dune-project.org</a>
You can reach the person managing the list at
<a class="moz-txt-link-abbreviated" href="mailto:dune-owner@dune-project.org">dune-owner@dune-project.org</a>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dune digest..."
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">Today's Topics:
1. Re: geometrygrid and PSurface (Oliver Sander)
2. boundarySegmentIndex (Marco Cisternino)
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Dune mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dune@dune-project.org">Dune@dune-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.dune-project.org/mailman/listinfo/dune">http://lists.dune-project.org/mailman/listinfo/dune</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Marco Cisternino, Ph.D.
Optimad Engineering s.r.l.
<a class="moz-txt-link-abbreviated" href="http://www.optimad.it">www.optimad.it</a>
<a class="moz-txt-link-abbreviated" href="mailto:marco.cisternino@optimad.it">marco.cisternino@optimad.it</a>
+3901119719782</pre>
</body>
</html>