[MOAB-dev] Changing the options format in iMesh

[Jason Kraftcheck]

On 11/15/2010 05:49 PM, Tim Tautges wrote:
>
>
> On 11/15/2010 03:29 PM, James Porter wrote:
>> On Mon, 2010-11-15 at 14:12 -0600, Tim Tautges wrote:
>>> So how many of the failures are due to not supporting septahedrons?
>>
>> Here's a tentative list of what's failing for us in iMesh_unitTest. I'm
>> not 100% sure about the reasons yet, but I'm reasonably confident:
>>
>> - (17) No support for septahedrons
>
> Based on feedback from Mark Shephard, I think we'll be adding these. Now
> I just need to remember where they're defined...
>

It's a degenerate hex where one edge is collapsed (6 faces and 7 
vertices.)  The name is misleading.  Or at least that's what I recall 
from when I first tried to find out what it was upon encountering the 
type in the TSTTM interface.  It's been a while, so I could be 
mis-remembering.

>> - (19) Set ops (intersect, etc) don't seem to create a set of the type
>> passed in (i.e. same isList value)
>
> This sounds like a MOAB bug to me; any comments?
>

I agree.

>> - (6) Set ops don't seem to work when one of the inputs is the root set
>
> Another bug, since the result is a new set.
>

I agree that it is a bug.  I'm not sure what you mean by the latter half 
of that statement.  The result of all of the set Boolean operations is 
always a new set.  Did you mean that if it was not a new set (modified 
the input set) then the behavior could not be supported for the root set 
in some cases?

>> - (18) Possible issues with iterators over sets with duplicate elements?
>
> Argh, I probably originated the problem, I recall using ranges for
> iterators, which won't work for list-type sets.
>

We probably need a separate list iterator implementation.  Using a 
range-based iterator for lists is clearly wrong for the ordering, but 
using a list-based iterator for ranges would be unnecessarily expensive 
(memory-wise) for many cases.

- jason