itaps-parallel Phone conf today

[Leung, Vitus]

Sorry, I must have copied the wrong time into my calendar.  My notes have 1:30P.

Vitus

-----Original Message-----
From: owner-itaps-parallel at mcs.anl.gov on behalf of Devine, Karen D.
Sent: Mon 1/7/2008 11:32 AM
To: itaps-parallel at mcs.anl.gov
Subject: itaps-parallel Phone conf today
 

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/itaps-parallel/attachments/20080107/3c41b776/attachment.htm>