itaps-parallel [Fwd: Re: Parallel Interface philosophical comments]

[Tim Tautges]

[Forwarding for archival]

-------- Original Message --------
Subject: Re: Parallel Interface philosophical comments
Date: Tue, 23 Oct 2007 15:09:07 -0400 (EDT)
From: Onkar Sahni <osahni at scorec.rpi.edu>
To: Devine, Karen D. <kddevin at sandia.gov>
CC: Tim Tautges <tautges at mcs.anl.gov>,   Mark Shephard 
<shephard at scorec.rpi.edu>,   Kenneth Jansen <kjansen at scorec.rpi.edu>, 
Ting Xie <txie at scorec.rpi.edu>,   Vitus Leung <vjleung at sandia.gov>, 
Carl Ollivier-Gooch <cfog at mech.ubc.ca>,   Lori A. Diachin 
<diachin2 at llnl.gov>,   Jason Kraftcheck <kraftche at cae.wisc.edu>, 
Knupp, Patrick <pknupp at sandia.gov>
References: <C338DFBB.B5CD%kddevin at sandia.gov> 
<471CA0EE.8020904 at mcs.anl.gov>

Hi all,

Here are some of my questions and comments on ITAPS parallel interface:

1) Is there a difference between "instance" and "handle" in ITAPS
terminology (or are there any definition for these)? (I may have missed it
if this was resolved/defined in previous ITAPS interfaces like iMesh).

2) For situations where we want to support multi-parts per 
processor/process:
(a) How do we want to distinguish between processor/process level
functionalities against part level ones (keeping user- and
implementation-convenience and efficiency in mind)? Ones which would fall
under processor level are, like list of parts on processor, MPI_Rank etc.,
whereas ones which would fall under part level are, like neighboring parts
(not procs.) etc. Further, there could be ones where users wants to
get/iterate mesh entities (and get adjacencies) at a processor and/or part
level.

(b) Assuming a part-handle is supported, how can user/application get
access to it (say on a processor where part resides)? Basically will there
be a way to directly access the part-handle (like part iterator at
iProcParts level) or user has to access it through tags/tag names, in
which case user has to figure out what is the tag/tag name for a
particular part (and who defines these tags/tag names).

3) How general we want to be in interface for different data
models/implementations (as in future we may want to incorporate/fit other
implementations), especially between serial and parallel data. Two
possibilities for data models I can think of are: (a) one (serial) data
model is enhanced to store parallel information and (b) serial one is
supplemented by a separate parallel one to support parallel
functionalities (in possibility (b) all parallel-specific information is
stored in a separate data to serial-specific data). We could design
interface that would fit both possibilities, this is the reason why we
included iPartMesh (section 3.4) level functions which are specific to
parallel functionalities in mesh (and passing handle to serial data in
these interface will not work for second possibility (b)). I do not know
how much relevant is this.

Let me know if you have questions.

Vitus, due to above questions I did not respond to your comments. I do not
know if above questions and comments make things clear. If you still have
anything specific please let us know.

Karen, Is there a way to create an email list for this subcommittee as if
we want to add (and remove) people (and it will keep record of all the
messages). I have added Ting in this response as she is also working on
this stuff from RPI side.

Thanks,
Onkar

> Hi all,
>    I'd like to re-iterate what I think should be the general behavior of
> functions in the parallel interface.  IMO, we should take advantage of
> the simple yet powerful data model we already have for iMesh.  That
> means using mesh sets for things which are obviously sets, and using the
> functions which already exist for accessing data in those sets.  I think
> it does make sense in certain cases to make convenience functions in the
> parallel interface for accessing e.g. all the sets which represent parts
> of a partition, on a current processor or globally, but I think we
> should minimize these.
>    Based on the general behavior described above, I think many of the
> functions proposed for global ids and parts/partitions already exist in
> iMesh.  For example, iPart_getGlobalID, iPart_createGlobalID,
> iProcParts_getPartIdArrOnProc, iProcParts iterator functions, etc.
>
> - tim
>
> --
> ================================================================
> "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
>
>




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