itaps-parallel Proposal for handling queries with parts, sets, and partitions

[Mark Shephard]

Tim,

I have never talked "data model" I have always spoke of functionality 
and API functions and have always contended that I have no concern about 
ones internal data model. Much of the discussion that got all this stuff 
confused to begin with with what (instanses vs whatever vs whatever) is 
forcing too much details of implementation data models into the process 
of defining the API and its functions. As far as I am concerned we are 
not keeping an eye on providing actual functionalities that are of use.

Our only concern is the interface functions and we have always responded 
to the discussion of that topic. Onkar, Ting and others here have 
provided documents on possible functions and will continue to respond to 
discussion of the API functions. We are not in a position to respond on 
how others that use various internal representation approaches address 
their implementation (much of the recent discussion). We can say what we 
can implement and can iterate with people on changes to the functions 
such that we get a set that works for all.

Mark

Tim Tautges wrote:
> But the language and constructs used to answer the questions (and to ask 
> the questions) is what we call the data model.  For example, the data 
> model says we pass references to entities back and forth using handles. 
>  As proposed by you, the data model for parts refers to them using 
> integer ids.  I think those ids could just as easily be handles, and 
> your implementation could implement those handles as integers.
> 
> As for how those are actually represented underneath, I strongly agree 
> we shouldn't force implementations to use one thing or another.  I'm 
> just saying the handles used to refer to parts and partitions should 
> also be usable in the other functions that deal with sets.  I wasn't 
> very careful in making this distinction in my writeup I sent earlier.
> 
> So, to go back to my original question, and back to what we had agreed 
> going out of the last bootcamp: why can't we pass part/partition handles 
> into existing functions in place of set handles, and have them 
> interpreted specially if they happen to be part/partition handles? Mark, 
> that wouldn't force you to actually represent parts/partitions as sets; 
> you could interpret set handles in a specific range as part/partition ids.
> 
> This would make the question of efficient booleans on the results 
> completely separable from the parallel interface discussion, as well as 
> allowing us to use our current function set dealing with entity sets to 
> also apply to parts/partitions.
> 
> - tim
> 
> Mark Shephard wrote:
>> Tim,
>>
>> No that is not true!!! The questions asked by an interface do not 
>> require specific information be stored. It requires the ability to 
>> answer the question!!!!! We very much use a partition model without 
>> sets or explicit storage of reverse classification. Reasons for this 
>> are explained in various papers. However, knowing that is less the 
>> issue. The reason for interface API is to allow people to answer the 
>> questions, not force them to use specific structures.
>>
>> Mark
>>
>> Tim Tautges wrote:
>>> Then why do we need functions operating on parts or partitions at 
>>> all? Those are reverse classification-type queries, right?
>>>
>>> - tim
>>>
>>> Mark Shephard wrote:
>>>>
>>>>
>>>> Since the first thing that was agreed to is that there would be the 
>>>> ability to deal parts that does not require an implementation to do 
>>>> things via sets (reverse classification), I sure hope we are not 
>>>> getting this issue confused again. As discussed in some technical 
>>>> detail at the boot camp, there are two high level approaches one 
>>>> based on classification (no use of sets) and reverse classification 
>>>> (what sets do well). All the SCOREC tools that are being used for 
>>>> parallel adaptive simulations, and (in the past) for parallel mesh 
>>>> generation, are based on a classification approach.
>>>>
>>>> Onkar Sahni wrote:
>>>>>> So again, I go back to asking: what are the core needs that 
>>>>>> prevent us
>>>>>> from using sets as both parts and partitions?  The entity set 
>>>>>> mechanism
>>>>>> was designed with this specific usage in mind.
>>>>>
>>>>> If "sets as both parts and partitions" mean using entity-sets then 
>>>>> we have
>>>>> already discussed this in great detail. I think the question in 
>>>>> discussion
>>>>> is irrespective of how one implements parts and partitions? If I
>>>>> understood the question right then we need to answer queries which 
>>>>> involve
>>>>> a specific part and a specific entity-set (where entity-set may 
>>>>> span more
>>>>> than one part, may be local to a process). Now, if it is implied that
>>>>> choosing entity-sets for both parts and partitions allows to use set
>>>>> operations (booleans), outside the interface explicitly by 
>>>>> applications,
>>>>> to answer such queries well then applications might as well do it 
>>>>> in other
>>>>> equivalent ways (for example, loop over entities in set and ask 
>>>>> residence
>>>>> parts to get entities in the entity-sey belonging to a specific part).
>>>>>
>>>>> - Onkar
>>>>>
>>>>
>>>>
>>>
>>
>>
>