Mesh set question

[Carl Ollivier-Gooch]

Tim Tautges wrote:
> 
> 
> Mark Shephard wrote:
>> Is there documentation on the rules for mesh sets under mesh 
>> modification?
>>
>> For example what happens in the following case:
>>
>> 2-D mesh and I want to swap an edge between two mesh faces that are in 
>> different mesh sets.
>>
>> Which mesh set do the new faces go into, or do they not go into either 
>> mesh set?
>>
>> Mark
>>
> 
> The proper behavior under these circumstances is application-dependent.  
> There are no rules right now governing what happens under mesh 
> modification.

The problem is that the -application- may know the rules, but there's no 
way it can let various -services- know what those rules are.  And even 
if we had a default definition that you can only modify within a set 
(all "before" ents that will be changed are in the set, and all "after" 
ents that are new are in that set, too), you still have the problem that 
there's no way to find out what sets an entity is in to do the checks. 
This basically gets us into a state where set membership has to be 
maintained by applications, not by services --- and services may butcher 
things rather badly.  Or is there some reasonable way to do this that I 
haven't thought of?

As Mark pointed out, this is the problem with having sets be general 
sets rather than something mesh semantics.  I'm not saying that there's 
a reasonable collection of mesh semantics that covers the realistic use 
cases, just pointing out that, without knowing what the set means, an 
implementation or service has no hope of maintaining the set, even if 
it's willing to pay a price for the entity->set info.

> Even more important (and I think you raised this issue recently too), 
> what happens when entities get deleted is also currently undefined.  In 
> MOAB, sets can be created either as "tracking" or not; for tracking 
> sets, deleted entities get removed, for non-tracking sets, they don't.  
> This is under the philosophy of maximizing choice for applications; a 
> tracking set imposes a cost of at least handle_size per entity per 
> tracking set (could be more, if you're interested in the details feel 
> free to ask.)

I currently check every set every time I delete an entity.  That's 
because I didn't envision the sorts of things Tim talks about, with 
millions of sets.  In that case, my run time blows up.  But if those are 
tracking sets, MOAB's memory blows up (and the runtime is also big), so 
it's a potential problem either way.

The easiest solution, of course, is not to use iMesh sets at all. ;-)

Oh, and by the way: the same problems occur with classification, but 
presumably iRel implementations will have two-way maps between (say) 
mesh and geometry entities, so the search will at least be quick when 
you need to delete an entity.  (Assuming you have all iRel instance 
handles available, which you can't really count on at present.  We could 
modify the spec to insist that iMesh and iGeom and i??? instances keep 
track of all iRel instances that they're associated with, and then the 
classification problem would be taken care of.)

Bottom line (IMO):  we definitely didn't think through all the 
consequences of mesh modification early enough, and now we've got a bit 
of a mess.

> PS - this is yet another reason I think we need an option string on our 
> set and tag creation functions.  Other reasons include being able to 
> specify sparse or dense on tag creation.  If people are interested in 
> that, I'd gladly write a proposal for an interface change.

While this is a problem that we may well conclude requires a solution 
(rather than just ignoring it), I don't think an option string is the 
right way to go.  We presumably would have a small, finite number of 
options that we can specify with booleans or enums.  If different 
implementations allow different option strings that turn on special 
functionality unique to that implementation, then we lose 
interoperability.

Yes, I know, this is potentially an issue for load and save as well, and 
I wouldn't say no to getting rid of that option string, too: I know I 
don't use it for anything I can't live without, and I'm sure no one else 
would recognize the same option strings I do.

And, on that cheery note, I'm off for dinner.

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Associate Professor                                 Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------