Discussed some of Ken's charts to be presented at HPEC. See HPEC ppt file for details of how we reorganized implementation approaches chart.
 

Discussion about implementation
 

Tony: suggests having design doc / (SRS) ready by Jan 1 to spin up a grad student
 
 

Discussing Cain_Lebak_Proposal
 

Randy: what about VSIPL_blocks?

James: can be created internally - UI gives views back to the user

Arkady: what about multiple channels sharing a block of memory?

• in and out channels share a buffer
• input buffer filled by 2 incoming channels

Randy: must do admit/release - don't forget that

Tony: multiple objects stored in single memory block requires multiple synchronization points - but VSIPL only has 1 - the memory block level admit/release

Ken: goal  is to make interface simple - probably doesn't handle above cases yet

Ken: regarding admit/release, the hope is that the channel operations can do admit/release

Myra: maybe channel operations (e.g.,get) can take a parameter indicating whether you really want to have the data admitted

Tony: prefers to define the memory view and block constructs ourselves, and then worry about VSIPL equivalence later. Could be basis for lower-middleware that could be common to MPIRT, VSIPL, DR, ...

Arkady: maybe we want non-element-length offsets to define the start of each data slice - argument for making something better than VSIPL
 

Also need to handle >3 dimensions - VSIPL doesn't. Need generic N-dimensional view object
 

*** Terminology problems:

Arkady: keep partitioning terminology, and then don't use it again - block is a partitioning terminology, so don't use it again

for this discussion, we'll use Cain_Proposal terminology -address specification later

Arkady: Cain_Proposal is missing iterator (get_next, ...)

Tony: don't force user into iterator/random access approach to getting data slices. Want to support element-wise data parallel operations like sum reduce, max reduce, etc. Don't want to have to use high level API for that.
 

Nathan: wants to remove data type specification from GDO, defer until much much later in the process

Tony: advantage of this is object reuse for data with similar shapes

Nathan: move data type support out of "CORE" spec. Move it into "adapter" subset of Standalone.
 
 

Nathan: alternate proposal for how to build up DR operations in general:

60 columns, 100 rows global data
Divide 60 cols by 3 procs, block fashion
Divide 100 rows by 4 procs, block fashion

Dist_Create (dimsize=60, procs=3 (or ANY), part_type=BLOCK, layout_order=0,  ATOM ,&row)
Dist_Create (dimsize=100, procs=4, part_type=BLOCK, layout_order=1, row, &matrix)
Later_Call (matrix, process_group, datatype)

this gets rid of a lot of arrays and scattered information that the user would have to create with original approach
 

Tony: why can't we have both ways of specifying things (current approach and this one)
 

Group decision: DRI_Distribution_Create - group argument is now group_size
Cleans up the "CORE" specification

Dennis: get_blockinfo call - the returned structure has element_size in it - so we'll need to get rid of that (because we haven't bound the datatype yet)
Myra: also impacts calc_local_size routine - return #elements
 

**** Meeting consensus

Data reorg working meeting, 2 days October @MITRE

• one month from now would be optimal
• Randy Judd schedule
• Ken Cain schedule

Official meeting #1
Week of November 27 in Orlando (coincides with CORBA activity)
1.5 days MPIRT
1.5 days DR
 
 

ACTION ITEM FOR KEN: Get softcopy of latest Mercury  layout proposal
 

**** Mercury Layout proposal (Arkady charts)