itaps-parallel Phone conf today

[Mark Shephard]

Tim Tautges wrote:
> With all due respect, no, I do not intend to stop talking about the data 
> model.  As I have spoken about many times in talks (and not nearly 
> enough in papers, I guess), the data model is extremely important to our 
> project.  In fact, I believe it is as important as the API.  Until tools 
> exchange tool-specific data in terms of the ITAPS data model we have 
> chosen, we will not have true interoperability.
> 
> I would also assert that the geometric modeling tools are a good example 
> of the failure of API's to provide interoperability.  Each of the 
> commercial geometric modelers has its own API, but they are not 
> interoperable, even after smoothing the differences between just the API 
> functions with common functionality.  For example, one API (ACIS, or 
> Parasolids) tells you how to get bounding vertices from faces, so you 
> write your application to count on that.  Then, that application does 
> not work on the next modeler and its API (e.g. ProToolkit), because that 
> modeler doesn't provide vertices in the first place.

We have found the solid modelers API very robust and have worked well 
with them.

> 
> Another example coming up soon is our parallel interface and the 
> interoperability of tools built on that interface.  If that interface 
> were written in terms of our existing data model, and if the iMesh and 
> iGeom entity type-based functions were moved down to iBase, I could 
> write a single partitioning tool that applied to both mesh and geometry 
> equally well, with only a different function for determining the weights 
> of nodes and edges in the graph.  Same goes for visualization, boundary 
> condition editing, and lots of other functions we both know are part of 
> a "real" simulation process.  Incidentally, that's one of the reasons I 
> still advocate keeping around the SIDL interface (because that provides 
> polymorphism necessary to write abstract tools like that).

I see no real point here. To me this is a matter of the API, not how I 
do or do not store my data.

> 
> - tim
> 
> 
> Mark Shephard wrote:
>>
>>
>> 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)?
>>
>>
>