Mesh set question

[Tim Tautges]

Carl Ollivier-Gooch wrote:

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

One of the implications of what we're developing in itaps is that multiple services may be applied to a given data base, 
and those services may leave data and metadata around on the mesh.  We all agree we should avoid the combinatorial 
problem of all services needing to code to all implementations' native interfaces (thus the common interface).  Getting 
multiple services working on a database, though, also means that we can't require each service to understand the 
metadata potentially left there by other services.  What we can do is provide a way for the application, which often 
knows about all the services it's calling, to specify the proper behavior when handling this metadata, in the language 
or data model used by the interfaces.

For example... I've written a copy/move/merge mesh capability in MeshKit, to help mesh these large fuel pin assemblies 
and lattices of assemblies.  Performing this operation on actual mesh entities is trivial.  Properly handling metadata 
that comes with typical meshes is not.  However, these behaviors can be abstracted and specified in terms of our data 
model.  In the copy/move/merge case, I use the notion of "copy" and "expand" set types; "copy" sets having entities 
which get copied themselves get copied, and given the copies as contents.  For expand sets, the new entities get added 
to those.  Criteria for determining whether a set is copy or expand can be specified by passing the sets themselves or 
tag types (and optionally values) which identify the sets.  Using this scheme, it's a very simple matter to have my 
service do "the right thing" with material sets (expand), neumann bcs (expand), geometric volumes (copy), parts (copy), 
reactor assemblies (copy), and lots of other things.  This is all without knowing the purpose of all these sets.

In summary: I don't believe it's possible to define the "right" behavior for sets under mesh modification at the mesh 
interface level, because the semantics of what the sets represent and how they behave can vary infinitely with 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.
> 
> 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.

There are examples where you'll want to do this without iRel too.  For example, material types and boundary conditions. 
   This is the point where Mark will say that he requires geometry to track these too, but not the only way to do it. 
In fact, you can abstract this such that the application calling the adapt service can specify rules for modifying sets, 
without the adapt service needing to know the set semantics, while also preserving the ability to relate to the geometry 
subsequently.  That may not always be the right way to do it, but I think it can also be said that there are non-trivial 
cases where that is the right way to do things.

Again, I think we need to think more abstractly here.  Classification and reverse classification are only one 
application of relations; even calling something "reverse" is specific to the semantics of how the mesh is generated and 
adapted.  Thinking of these things in terms of generic sets greatly reduces the number of operations you have to support 
to implement those semantics.

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

"ever" is a pretty strong statement.  I won't go trolling through old emails, as I'm sorely tempted to do here.  But, I 
can say that I had a hard enough time convincing people that sets were even needed or even useful, so we may not have 
spent much time on the deeper question about what to do with them under modification.

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

At best, that statement is way stronger than it should be ("no way"?  c'mon...).  First, you're arguing from the 
standpoint of a very specific kind of mesh modification.  There are many other kinds of mesh modification, and for some 
of those I've already demonstrated that they can be done through iMesh, and done efficiently.  copy/move is one of them 
(the merge is more complicated, but I'll ignore that for now).  Smoothing is another.  Furthermore, your statement is 
based on one type of implementation; I think one could implement refinement/coarsening in such a way that sets are 
handled properly, in a way that was not too burdensome on the application.

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

We can't specify these types of rules at the interface spec level, because that will overconstrain some implementations 
and use cases.  For maximum interoperability, one could implement the service to provide options for the application to 
select.  For example, an option for whether the service deletes entities from sets before deleting the entity itself, or 
not.  The first case would work better on an implementation that was minimal and efficient in time and space (e.g. MOAB 
under certain conditions).  The second would be better for implementations that already had a rich observer capability 
(e.g. GRUMMP, or MOAB under other conditions).

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

But dense and sparse tags are only the tip of the iceberg.  There are all sorts of load/save behaviors that are 
appropriate in an options string, that are inappropriate for binding into the interface semantics.  And, having a 
(reasonably) compact data model and api really does simplify the implementation of new capability on top of iMesh.

And c'mon, you made it that far in my message but passed up the chance to ridicule my obscure Vonnegut reference? :)

- tim

> 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