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

[Tim Tautges]

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

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706