iRel.h interface update [was iRel proposal: removing non-one-to-one relation functions]

[Tim Tautges]

[Sorry for the radio silence, was directing a mtg last Thurs and Fri and had a busy weekend...]

I'll try and comment on the various issues running around here, in no particular order...

1. One of the most fundamental issues here, raised by Jason this time around, is the question of how to represent 
collections of entities.  If this was only a question of how to pass these collections through the interface, we could 
do that with arrays, like we do in iMesh, and the argument would be over.  However, we also need to maintain these 
collections in state.  Currently, the way the iMesh and iGeom specs support collections is with entity sets.  What 
Seegyoung seems to be suggesting with EntArr is another type of collection.  How is this different from EntitySet, 
besides just not being an EntitySet?  Will we need to support query and modify functions on these things?  What 
EntitySet functionality will we not have to support on them?

2. The point of having Entity Set in the ITAPS interfaces was to provide a general collection mechanism to support the 
very many uses for them.  Yes, RPI does not use them for anything, because they have semantic-specific data types for 
their various uses (by semantic-specific here, I mean a type specific to the use of a collection, e.g. a specific 
"boundary condition" collection).  But, this is one thing we've been through many times before, and IIRC have decided we 
don't want to support semantic-specific data types.

3. As Jason suggested (recently, as well as several times in the past), it would be a simple matter to use different 
implementations of the EntitySet interface depending on the semantics of those sets.  Mark B implied on Thurs that 
that's how they planned to implement iRel.  For example, why not use C++ inheritance for this?  Yes, the downside might 
be that these types of EntitySets would not support many of the current interface functions for EntitySet; however, I 
don't think a proliferation of semantic-specific collection types would be such a good solution either.  If it's the 
EntitySet modification functions that are a problem here, maybe we could consider a const-type EntitySet instead?  Or, a 
qualifier saying whether parent/child relations are supported, much like we have already for list- and set-type EntitySets?

4. So much of this discussion revolves around the perception that EntitySets cannot be implemented efficiently.  This 
comes primarily from RPI; however, the last time Jason looked, their implementation was based on linked lists.  Mark or 
Seegyoung, have you ever considered that maybe that's not such a good implementation?  Presumably you know other ways of 
implementing collections efficiently, since you already have such things for parts, classification, and other things. 
Also, we've demonstrated that it's possible to implement EntitySet efficiently, whether it's ordered or not.  It sounds 
obnoxious for me to be describing that so starkly, but I don't recall this being discussed up to now.

5. Finally, the whole issue of "efficiently supporting classification" was the whole point of the long discussions 
around Christmas time, and was the reason for adding support for iterators to iRel.  Also, at the bootcamp, we requested 
use cases, and provided one from the shape optimization work (since replaced with a simpler one for straight 
classification query).  I still haven't seen one written up from RPI or Simmetrix.  It would really help to see such a 
thing.

- tim

On 10/30/2010 01:28 PM, seol at scorec.rpi.edu wrote:
>> I think we're talking at cross purposes. The *only* differences between my position and Seegyoung's are that 1) I
>> proposed adding something like "SetArr" for symmetry, and 2) I moved the suggested flag ("EntArr") to a different
>> enumeration because doing so more closely reflects established terminology in relational databases. Unless you think
>> #1 would be difficult/impossible to implement (which it may be, I don't know the internals of your software), we
>> appear to be arguing about the name of a parameter.
>>
>> I can't speak for Tim, Jason, or anyone else at ANL or UW, but I'm agreeing with Seegyoung's proposal in every respect
>> except the naming scheme.
>
> I will start interacting with Jim in terms of iRel modification for better service of classification.
> Once we figure out a solution that meets the needs for both "itaps-set"-based and "c-array"-based implementations, we
> will bring into the group.
>
> Mark M,
>
> I am thinking about interacting with Jim through ITAPS conference number and/or emails. I assume using conference
> number is fine.
>
> Seegyoung
>
>>
>> - Jim
>>
>> On 10/28/10, Mark Shephard<shephard at scorec.rpi.edu>  wrote:
>>
>>> Jim,
>>>
>>> There is no disagreement that some of the suggestions are not optimal. However, when a very simple added function
>>> that would do exactly what was needed was suggested Tim indicated it, and as near as I and others can tell anything
>>> like it, was simply not acceptable to him.
>>>
>>> I believe that the early emails on the iRel problems by Mark Beall and papers that go back to the 90's have clearly
>>> defined the simple capability requested. To this point any of the suggestions from the MOAB team that come close to
>>> supporting the need you are calling an unacceptable hack. If you do not like any of them, then please work with
>>> Seegyoung on defining something that will work for all.
>>>
>>> Note that if we ever want to converge, the solution has to consider needs other than what one understands at this
>>> point in time to be a good implementation without hacks which is heavily based on the ITAPS interface
>>> implementations they work with. I can assure you that using sets as defined in iMesh do things we do very cleanly
>>> during mesh modifications would look very much like a hack. However, for other things, many of which MOAB focuses
>>> on, sets are a nice way to do it. What is common, that is in the ITAPS interfaces, needs to have some consideration
>>> of the needs of all implementations that are actually being used to do things.
>>>
>>> It would be nice to actually focus the iRel discussion on support of relations as they are used in simulations using
>>> unstructured meshes. That is let everyone state their requirements for relations and then define something that
>>> meets all of them. I though that irrespective of if specific options were "hacks" or not, Jason's email from earlier
>>> was in that direction. I also though that the suggestions made in Seegyoung 3:15am email were also in that direction
>>> (while trying to not change much of what was in place).
>>>
>>> Again, I request that you and Seegyoung work on something that you can both accept and then present it to the rest
>>> of us. This is the approach taken by Tim and I to define iGeom and that seamed to work. If successful at a minimum
>>> it should give us a starting point that can be build on that will work. In my opinion the seamingly simple nature of
>>> supporting relations, which is the stated goal of iRel, should be much easier that iGeom.
>>>
>>> Mark
>>>
>>> On 10/28/10 8:07 PM, James Porter wrote:
>>>> On Thu, 2010-10-28 at 18:58 -0400, seol at scorec.rpi.edu wrote:
>>>>>> On Thu, 2010-10-28 at 03:12 -0400, seol at scorec.rpi.edu wrote:
>>>>>>> 4. adding "EntArr" to "Relation Type" and removing iRel_getEntSetIter&   iRel_getEntArrSetIterArr
>>>>>>>
>>>>>>>      CURRENT Relation Type: Ent, Set, Both (Ent&Set)
>>>>>>>      NEW: Ent, Set, Both (Ent&Set), EntArr
>>>>>>
>>>>>> Assuming we end up agreeing that directly encoding one-to-many
>>>>>> relationships in iRel (instead of relying on iMesh/iGeom to give us this
>>>>>> though sets and/or iterators), I don't think this is a good way to go
>>>>>> about doing it as it's really just a hack to work around implementations
>>>>>> that don't support sets.
>>>>>
>>>>> vice versa. supporting set-only relation type is not a good way either as it requires a hack to work around
>>>>> implementation that don't use sets as a way of grouping of multiple data
>>>>
>>>> You're talking about hacks to an implementation. I mean hacks to the
>>>> interface; the EntArr proposal seems to be operating under the premise
>>>> that we shouldn't change any of the other parts of iRel to help you guys
>>>> out, so you have to "bolt on" a new feature. Really, the current way
>>>> isn't good for you guys, but EntArr doesn't help us in any way. We'd end
>>>> up with two parallel interfaces that the "other guys" would have no use
>>>> for except as a compatibility layer.
>>>>
>>>> The problem here is that iRel obviously needs to support a one-to-many
>>>> relation *somehow*, and currently, it tries to do this by piggybacking
>>>> on sets from iMesh/iGeom. That's what the "Set" relation type is.
>>>> Obviously this is bad for implementations that don't use sets, but I
>>>> think it's bad in general. It makes the implementation less clear, and
>>>> if we want to support one-to-many relations (without deferring
>>>> *completely* to iMesh/iGeom sets), we should commit to that instead of
>>>> doing it partway (EntArr doesn't help one-to-many-sets, for instance).
>>>>
>>>> Besides, there's no logical difference between "RelationType = {Ent,
>>>> Set, EntArr, SetArr}" and "RelationType = {Ent, Set}, CardinalityType =
>>>> {One, Many}"*, but the latter way pushes iRel closer to "traditional"
>>>> relational DBs, which can only be a good thing, if for no other reason
>>>> than that it's easier to write documentation for.
>>>>
>>>> * I'm ignoring Both for now, just for simplicity.
>>>>
>>>>>> Don't take the above suggestion as endorsement, though. As the
>>>>>> maintainer of (currently) the only iRel implementation, I should note
>>>>>> that doing this (either your way or mine) will significantly increase
>>>>>> the complexity and decrease the potential for interoperability** of iRel
>>>>>> unless the iMesh and iGeom specs are updated as well.
>>>>>
>>>>> It's not clear why not having EntArr relation type. Please describe the following.
>>>>>     - how iRel, iMesh and iGeom should be updated further by having EntArr relation type.
>>>>
>>>> Again, I'm not saying that something equivalent to "EntArr" is bad, but
>>>> that calling it that is limiting to us (there's no "SetArr"). Pulling it
>>>> out into a "cardinality" flag does the same thing but reads better.
>>>>
>>>> However, either EntArr or my cardinality alternative would require us to
>>>> significantly change how our iRel implementation works. If we stick with
>>>> represent "many" as just a set, then we have to add a lot of extra logic
>>>> to handle creating a one-to-many relation that isn't already backed by a
>>>> set. The code for EntEntArr relations is already fairly brittle in
>>>> Lasso, and I'd rather it not get worse.
>>>>
>>>> The "clean" alternative is to store the "many" directly on a tag, but
>>>> that would mean we need variable-length tags in iMesh/iGeom or we have
>>>> to fall back to MOAB's native interface, which would make it more
>>>> difficult to use Lasso with any other implementation (or to port it
>>>> over).
>>>>
>>>>>     - why EntArr and Set are not othorgonal so iRel shouldn't have EntArr relation type losing the generality
>>> (limiting
>>>>> its capability to support one-to-(set)many only).
>>>>
>>>> I'm not sure what exactly you mean by this, but if two things are
>>>> orthogonal, as you seem to be suggesting, I think it makes sense for
>>>> them to be represented as different parameters.
>>>>
>>>>>     - why MOAB/Lasso cannot support EntArr relation type to account for FMDB-like implementation as we do support
>>> set
>>>>> relation type to account for MOAB-like implementation in all other interfaces.
>>>>
>>>> I haven't said that we can't do this, only that it makes things
>>>> significantly more complicated for us. As I already mentioned, my
>>>> alternative doesn't actually make things any simpler for us, it just
>>>> makes the interface clearer.
>>>>
>>>> - Jim
>>>>
>>
>
>
>

-- 
================================================================
"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