itaps-parallel Phone conf today

[Mark Shephard]

In yesterdays phone call we yet again went back to the discussion on 
data model vs API. As near as I can tell iMesh, iGeom, etc. are API’s 
where there are agreed to functions that take specific information as 
input and provide specific information as answers to the question. For 
example, the one we keep discussing is give me the group of mesh faces 
that meet two conditions (one example, but only one example, of which is 
the mesh faces in a specific part and has a specific BC).  This can be 
discussed at the API level quite independently of one does it with 
carrying out Booleans of sets of does something else underneath to 
provide the answer to the question.

The geometric modeling tools have done this well for many years focused 
on the API end of it and no one has problems with it.

Since it is quite clear that different ITAPS groups have very different 
data models for how they do thing which are actually driven by valid 
concepts, that have also been discussed many times before, can we please 
focus on the API level and quite telling each other we have to adopt a 
specific data model.

Mark

Devine, Karen D. wrote:
> My calendar shows that we have a phone conference scheduled for today at
> 1:30pm PST.  Please let me know if you expect to miss this meeting (or if
> you think my calendar is incorrect).
> 
> There has been lots of good discussion since our last meeting.  Please take
> time to review it before the phone conference.
> 
> Below are topics for discussion.
> 
> -  Tim asked that we clarify the questions we are addressing.  He listed the
> following:
> 
>     1) Do we want to do booleans on query results below the interface level?
>      An example query would be "What are all regions in some set in a
>     particular part?"
> 
>     2) How do we express and query sets spread across processors?
> 
>     3) How do we refer to parts and partitions in the interface, and which
>     functions do we use to get information about them?
> 
> So far, our efforts have been addressing (3) and, more recently, (1).  With
> respect to (3), we have agreed to provide helper-functions that expose
> partition and part information through the interface.  These
> helper-functions are natural for an application to use and allow the
> greatest flexibility for the implementations.  With respect to (1), we
> identified the need to answer queries such as the example Tim provided.
> Several options were proposed to answer these queries (see below).  Tim
> noted that similar capability could be useful for intersections of multiple
> entity sets.  We have not deeply explored question (2) yet, and unless there
> is a reason to do so immediately, I'd like to resolve (3) and (1) before we
> start into (2).
> 
> -  I'd like to try to reach agreement on a solution to question (1) above.
> Our original idea of overloading the mesh instance argument is insufficient
> for answering these queries, especially in a multiplexing environment.  Carl
> summarized three options; I'd like to discuss the pros/cons of each.
> 
>> a)  Adding args to about 10 functions, for both serial and parallel.
>> Requires: universal agreement about what a null handle is, or else
>> definition of an implementation-specific global variable that apps can
>> use to find out what the null handle is for that impl.  Also, for every
>> call, the function has to identify which args it was passed and dispatch
>> accordingly (creating more functions internal to the interface,
>> probably, but not user-visible).  Changes to serial code.
>>
>> b)  Leaving those 10 functions alone in serial, and adding parallel
>> versions.  Requires: adding probably one function for each of the
>> originals in the parallel interface.  My guess from the current document
>> on parallel is that we'll be looking at >100 functions already, so this
>> may or may not be considered significant. Serial code left untouched.
>>
>> c)  Adding some magic to squish three args into one in parallel.
>> Requires: A function to squish (and unsquish, internally) the args;
>> therefore, extra effort for the app and impl for each of those 10
>> functions every time they're called (even in serial, probably).
>> Depending on how the squishing is done, risk of handle collision.
>> Changes to serial code.
> 
> -  Finally, I'd like to get clarity on how decisions are made in ITAPS.
> When the iMesh interface was defined, for example, was unanimous agreement
> needed on a function before it was accepted?  Or was a vote taken (as I
> believe CCA does)?  
> 
>