itaps-parallel Phone conf today

[Tim Tautges]

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.

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

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

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