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

[Jason Kraftcheck]

On 10/28/2010 03:10 PM, Mark Shephard wrote:
> On 10/28/10 3:59 PM, James Porter wrote:
>> On Thu, 2010-10-28 at 03:12 -0400, seol at scorec.rpi.edu wrote:

>>
>>> This avails non set-dominant impementation to support "iRel"
>>> effectively without interfering set-dominant
>>> implementation and not against neither of "interchangeability" and
>>> "interoperability".
>>
>> I must confess that my knowledge of other ITAPS implementations is
>> limited, but are you suggesting that a) you wouldn't support the
>> set-based functions in iRel at all, or b) that you'd support them, but
>> they wouldn't be the optimal way of working with data in your
>> implementation?
> 
> We support all the set functions. However, controlling everything by
> sets becomes quite computationally intensive when you are doing lots of
> local mesh modification, which is exactly what users of out
> implementations are doing. Thus although we support sets, the
> applications we support typically use sets in specific ways that cause
> no complexity with the sets that are in place.
> 

But do you support the the iRel functions that operate on set handles?
Specifically, MOAB/CGM/IRel do something where classification is between an
entity set on the MOAB side and an entity on the GGM side.  There are
functions in the iRel interface tailored to this model:  get the *set* of
mesh entities classified against a given geometric entity.  From what I've
gathered from discussions so far FMDB does not do classification this way.
So when you say that you support all the set functionality in the iRel
interface, do you mean:
a) That you can provide classification data in this way.  For example
   returning some kind of a virtual entity set handle for which queries
   for set contents will return some group of entities classified to a
   particular geometric entity?
b) Provide iRel functionality for an application to classify sets against
   entities but don't support querying mesh->geom classification that
   way?
c) Neither of the above?

thanks,

- jason