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

[Mark Shephard]

Jason,

Seegyoung can provide more detailed technical answers to your questions. 
However, here is a high level answer (which has been stated more than 
onc e): Yes we support the ITAPS requirements for sets and we could 
potentially do things the way you indicated. However, the computational 
cost associated with that would make the procedures we have for mesh 
adaptation and other functions that change the mesh many time slower.

It has always been a common goal in ITAPS to we find solutions that 
allow implementations to do be used at what they are good at in a way 
that does not kill any of them at what they are good at. For example, we 
have added all the set support capabilities to FMDB even though there is 
not a single functional use case presented that we do not already 
support in some other way with FMDB and other tools we have.

It seams clear that there are multiple options for being able to have 
iRel support all ITAPS relation needs in a way that is useful for all 
implementations. The current specification is not quite there yet.

Mark

On 10/28/10 4:51 PM, Jason Kraftcheck wrote:
> 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
>