Mesh set question

[Tim Tautges]

Carl Ollivier-Gooch wrote:
> 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?
> 

In this case I view the service as the application.

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

I think that for mesh modification there probably is a fairly small set of defined semantics, and I would probably
choose to make those some sort of utility within the service.  There are many other, non-set examples of this sort of idea.

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

Actually, my memory doesn't blow up.  Since I keep containing set handles in the same list as adjacent entities, I don't
pay extra for the list itself.  In most cases, a given entity is in at most one of the sets of which there are millions,
so it's a small number of extra bytes per entity.

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

I think that's also a responsibility of the application/service.  The mesh/geometry interfaces should not depend on
iRel, nor on the other interfaces to which they may be related.

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

Actually, I've been thinking of and considering these issues for over 10 years, and have been talking about them ever
since ITAPS began.  If you wondered why I was so anal about sets and relations being done in a particular way, this is
one of the reasons why.  For example, the need for both memory efficiency and cpu time efficiency, often at different
times in the same application, are why we have entity-set and both-set types of relations.  One thing that's not in the
current iRel interface is a function for switching between entity-set, entity-entity, and both-set types of relations.
This is something we need, to be able to support e.g. calling a MeshAdapt service without incurring the memory cost of
maintaining all that information after the service is done (a better example is an element quality-based smoother, where
vertices get moved back to the geometric entities after they're moved).

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

We've discussed this issue before.  The question is, do we want to allow at least some diversity in implementations to
be accessed through iMesh.  There are many ways of handling the case where options are interpreted by some
implementations and not others (though I think the best way would be another value of error code).  Allowing an
application to access options in this way allows them to #ifdef based on the implementation to access those options,
without requiring them to use implementation-dependent types and functions in those blocks of code.

I'm not sure if anybody besides me (on our team, anyway) has started developing *new* code based on iMesh.  I've been 
doing more of that lately in MeshKit.  There are many specific things which make iMesh less convenient for these tools 
than directly using MOAB.  I'm sure Mark and Carl would say the same thing about writing tools based on their 
implementations.  Allowing these tools to call specialized behaviors in their implementations, through iMesh, may 
determine whether these tools get implemented on iMesh or not.  I think it's of much value to implement based on iMesh, 
but to allow specializations in specific cases through the use of options.  I know this next analogy is close to 
hyperbole, but these kind of limitations are the kind of thing you'd get from Diana Moon Glampers (wikipedia it, it's 
actually quite relevant in this discussion...)

- tim


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

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706