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

[seol at scorec.rpi.edu]

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