Mesh set question

[Carl Ollivier-Gooch]

Tim Tautges wrote:
> 
> 
> 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

That doesn't solve anything, though.  Here's the problem:  some 
application creates a bunch of sets that mean something to it.  Then the 
application calls a swapping service that has no idea what those sets 
mean, because the service is naturally meant to be application 
independent.  What should the swapping service do?  It can't be wired to 
understand AppXYZ's sets, because then it won't work on AppPQR's sets, 
which mean something else.  Should it ignore set membership, forcing the 
app to rebuild all those sets after swapping?  Swap only 
highest-dimensional entities such that if entity A is in set Z, entity B 
(and how ever many others) are also in set Z?  Something else?  And how 
does the service do this with our current interface?

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

The semantics that make the most sense to me, at least at first glance, 
for modification are classification / reverse classification, which I 
(as a service writer) would run through iRel rather than looking at sets 
anyway.  And in any case, working on a classification basis will 
necessarily trash other sets.

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

I can see this either way, I guess, although it does make an extra call 
in app/service code to have to update classification instead of getting 
auto-delete and create-with-classification.

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

I stand by my statement.  The interaction of sets and tags with mesh 
modification is something that I don't recall ever discussing, and our 
current interface provides no way for a service that does mesh 
modification to correctly and efficiently handle sets that the 
application that called it thinks are important (even if given enough 
info to be correct, a service can't be efficient).  We can choose to 
dump this problem on the application programmers, but it -is- a problem.

The easiest fix is to document that the sets may be garbage on return 
and caveat app.  Intermediate would be to ignore sets in mesh 
modification, but to remove ents from sets if they get deleted 
(otherwise you can't re-use that memory without potentially putting an 
entity in the wrong set).

As for tags, nuking tags on an entity at deletion time is easy, but 
dealing with tag -values- that are entities being deleted is not (and if 
the handle gets re-used, there's no way for the app to know later that 
the tag value is almost certainly wrong).

Yes, I know, these two paras implies that mesh modification services may 
be invalidating entity handles.  I see no obvious ways around this that 
don't waste memory like crazy.

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

I haven't done any careful analysis, but I'm pretty sure I could factor 
all or nearly all the services that GRUMMP provides into things that 
would be implementable through iMesh.  Certainly that was true for 
swapping, although admittedly that service ignores the set and tag 
issues in question here.  But then, GRUMMP doesn't have native sets (or 
didn't, pre-TSTT) and only rudimentary tags.

I agree that there's a place for specifying things like dense/sparse 
tags (here I think there's something like consensus, but maybe not...) 
and, no doubt, some others.  (This example, at least, is one where a 
boolean will do fine.)  I think, though, that we should add these on a 
case-by-case basis when there's a compelling efficiency (of time or 
space) argument, rather than adding a blanket string argument.  The 
latter gets us quickly into the situation where a lot of apps will be 
written in a way that they can only run with one implementation and/or 
apps will have to have lots of special case code in them.  If there's an 
efficiency argument to be made, presumably multiple implementations will 
benefit from providing hints, and we should do this in as uniform a way 
as possible.  I, for one, would welcome concrete proposals, with the 
efficiency argument, for things like this, because I think there is 
definitely room for improvement.

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