[MOAB-dev] MBSkinner -- skin orientation

Roman Putanowicz putanowr at l5.pk.edu.pl
Sun Feb 14 16:20:19 CST 2010


Hi,

Recent patch by Jason to MBSkinner fixed the problem with not complete
skinns in consecutive calls for skin of different subdomains but I believe
that it introduced a "feature".

The basic question is if the skin computed by MBSkinner is supposed
to be oriented (e.g. the skin normal points inside domain for all the edges,
or outside but that is detail)?

If so then the intersection of the skin of two adjacent domains should
be empty set, as on the interface between these subdomains the edges 
will have opposite orientation (so they will be different edges).

Now however, if I take the intersection of the skins of the two 
adjacent subdomains I will get the edges on the interface.

This case is illustrated in the attached picture (there is also data
and the test program source code).

Before the fix in order to get the common interface edges I had to do
the call sequence like this:

mesh.get_entities_by_dimension(s2, 2, elems);
skinner.find_skin(elems, false, bedges2);
elems.clear();
mesh.get_entities_by_dimension(s1, 2, elems)r
skinner.find_skin(elems, false, dummy, &bedges1, true, false); /* HERE */
MBRange sharedEdges = intersect(bedges1, bedges2);

and with the call in line /*HERE*/ I received the skin edges of the subdomain 
s1 with reverse orientation.

Now however, the behaviour of the find_skinn methods is more erratic
because in the  call to method:

MBErrorCode   find_skin (const MBRange &entities, bool get_vertices, MBRange
&output_handles, MBRange *output_reverse_handles=0, bool
create_vert_elem_adjs=false, bool create_skin_elements=true)

the treatment of edges (oriented or not) depends on the argument
output_reverse_handles (if 0 then are treated like not oriented 
if not zero the like oriented).

To sum up:
 a) is the skin oriented?
 b) if a) is true then why intersection of skins of two adjacent subdomains
    is not empty?

I might have misuse the interface or interpret the thing in a wrong way,
thus I would be grateful for clarification on the subject.

Best regards,

Roman

PS. In the attached code there are calls to 2D viewer for MOAB 
based on g2 library. If anybody is interested I can share the code.
One day I plan to pack it as a library but this is still deep on the
"to do" stack :)
-- 
Roman Putanowicz  < putanowr at l5.pk.edu.pl  >
Institute for Computational Civil Engng (L-5)
Dept. of Civil Engng, Cracow Univ. of Technology
www.l5.pk.edu.pl, tel. +48 12 628 2569, fax 2034
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itest.cxx
Type: text/x-c++src
Size: 2597 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100214/1a342c48/attachment-0001.cxx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: two_domains.png
Type: image/png
Size: 15876 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100214/1a342c48/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twoddomains.msh
Type: model/mesh
Size: 11544 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20100214/1a342c48/attachment-0001.msh>


More information about the moab-dev mailing list