[MOAB-dev] MBSkinner -- skin orientation

[Jason Kraftcheck]

Roman Putanowicz wrote:
> 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 actual bug was that it never returned the edges that where 'reversed'
with respect to the element they are adjacent to.  As there were no explicit
edges yet for the first call, it created all of the edges on the skin with a
'forward' orientation.  For subsequent calls on adjacent domains some of the
edges already existed with a reverse orientation.  It wasn't returning
those.  So the fix didn't introduce a new "feature", it fixed a bug related
to an existing 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)?
> 

The skinner always returns any edges that already exist on the skin.  You
can optionally request that the skin edges be returned in two groups:
"forward" and "reversed."

[snip]

> 
> 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).
> 

It isn't erratic.  The skin is not 'oriented' in the sense that you mean it.
 It will always return any existing edges on the skin, regardless of their
orientation.  You may optionally request that any edges with a 'reverse'
orientation be returned in a separate MBRange from those with a forward
orientation.


> To sum up:
>  a) is the skin oriented?

No.  If you want an oriented skin, either create new edges from those in the
'output_reverse_handles' range, or use MBInterface::set_connectivity to
reverse the existing ones.

>  b) if a) is true then why intersection of skins of two adjacent subdomains
>     is not empty?
> 

If you request that the 'reverse' edges be returned in a separate MBRange,
then the intersection of the 'forward' MBRanges for two adjacent domains
will be empty, and the intersection of the 'reverse' MBRanges will be empty,
but the intersection between the 'forward' MBRange of one domain with the
'reverse' MBRange of the other will contain edges on the intersection.

- jason