Mesh set question

[Mark Shephard]

Carl,

Just to be sure I followed your comment on the problem with 
classification, I assume you are referring to times when one wants to do 
something like traverse the mesh faces on a model face (for example to 
calculate contributions to a surface load). At those time what we 
historically referred to keeping the list of faces on a model face as 
reverse classification as the thing that is wanted. (Note, reverse 
classification can be limited to maintaining just the list of equal 
order order entities classified on a model entity.)

I am not sure if this is too much of a simplification, but during things 
like mesh adaptation, classification is the relations used all the time 
and when we go to analysis applications it is reverse classification 
that we want. Although I have not really gone through the process of 
trying to prove that these two relationships can effectively cover 
everything we need to do, I think there is a strong possibility that in 
fact that they may be the simple generalization that can deal with all 
issues. I would not mind having a serious conservation and analysis of 
this question. If we then believe it is correct, defining how we may 
implement things where implementations may be able to convert between 
them as needed by the various classes of applications, or keep both for 
some applications may be of interest. (I even have some reason to 
believe that dealing with this well may also be key to effective 
reduced, but still complete mesh representations.)

Mark

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