Software Coordinating Committee Conference Call
		       July 31, 2001 3:00 PM EDT
			  Recorder: C. DeTar

Present:

  Brower, Pochinski, DeTar, Simone, Holmgren, Mendez, Edwards, Mawhinney 

Absent: 

  Watson

** = action required

Main agenda item: Linear Algebra API
    See Brower block chart http://buphy.bu.edu/~brower/SciDAC/doc/chart.msg

    Brower: Big issue - combining communication with algebra
    Mawhinney: Pass class objects to Level 2?
    DeTar: How do we guarantee assembler code pluggability?  Is class
      byte structure a declared standard?
    Edwards: SZIN written mainly at Level 2 
    Mawhinney: QCDOC interfaces written at a higher level - Level 3
    Brower: (1) We say level 2 requires a layout - or -
            (2) We keep the same semantics but support a 
                variety of layouts?
    Edewards: What layouts are we talking about?
    DeTar: Let's list the attributes we need to describe.
    Brower: Need to know size, pattern in x,y,z,t (and L_s?)
    DeTar: What if we store all red sites together?
    Pochinski: Can't be sure strides between data elements 
           are always efficient.
    Mawhinney: Can't hope for good performance at this level.  Level 3 best.
    Edwards: Yes, can't get most of performance, but good way to encapsulate.
    Edwards: Would like to pass layout information to Level 2.
    Brower: We want to say, Level 2 knows everything about the lattice.
    DeTar: Suppose we focus first on just the local lattice-wide linalg
       (Brower Block chart Level 2, lower left)
    Edwards: Example of information needed:  Just the volume.
    Edwards: Could we agree to lay out reds together? What about QCDOC?
    Mawhinney: For QCDOC chose a couple of storage orders for high
              performance so require remapping, but could accept
              arranging reds together.  Message passing via block
              strides was not compatible with red/black.
    Brower: Let's say we assume a canonical internal Level 2 order.
    Mawhinney: Perhaps we say performance at level 2 not so important
               get performance at level 3.
    DeTar: So we can agree we expect a gather before a shift.
    Edwards: Agreed.
    Brower: We should list the functions we want at level 2
    Pochinsky: Suppose we say we write remapping interfaces above and
         below level 2 and write level 2 in standard internal form.
    Edwards: We could make level 2 handle any order.
    Brower: What operations at level 2?
            Apply any number of operations and shift
    DeTar: That's many hundreds of operations.  Let's start with a
           small set and see how it goes.  Can't we just code the
           ones that are time-critical and let the user build the
           rest from Level 1?
    Brower: The idea is to make Level 2 the main user interface.
    Mawhinney: Are we saying the user should conform to the internal
          Level 2 order from the highest level?
    Brower: So are we agreed that we want to specify the internal data order?
    DeTar: Would prefer not to specify a particular x,y,z,t ordering,
           but would segregate red-black at level 2 and have the user
           pass details about the rest of the layout.
    Brower: Have to sign off soon. Where from here?
    Mawhinney: Need to have specifications so Columbia can proceed
           with message passing API,  Having Linalg specs would
           also help.
    Brower: Subcommittee to work out Level 2 internal order.

    ** Subcommittee to propose an example for Level 2
    ** Subcommittee to work out deadlines for deliverables

Next call on Aug 9 or 10, time to be announced.
    Mawhinney on vacation, so may be absent.

Call concluded at 5:00 PM EDT.