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

[Mark Shephard]

We agree to look at it differently. So long as we define interface 
functions we can all live with.

Tim Tautges wrote:
> The data model as I refer to it isn't about internal representation, 
> it's part of the interface spec (I assert that it precedes the 
> interface, in fact).  I use the term "data structure" to refer to 
> internal representation.
> 
> - tim
> 
> Mark Shephard wrote:
>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>