From detar@dirac.physics.utah.edu  Fri Mar 22 16:30:25 2002
Date: Fri, 22 Mar 2002 14:30:23 -0700 (MST)
From: Carleton DeTar <detar@physics.utah.edu>
To: edwards@jlab.org
CC: detar@physics.utah.edu, brower@BUCRF20.bu.edu, osborn@physics.utah.edu
Subject: QDP/ QLA Discussion
X-IMAPbase: 1208658860 0000000001
X-UID: 1                                                  
Status: O
Content-Length: 2173

Hi Robert,

I called, but you were out.

Here are points we need to discuss...

QDP

1. Where the data types live.  I believe we agreed that to keep it
   simple, they would live on all sites, even if we intended to use
   only a subset - say even sites.  Can we make this firm?

2. Consequence of shifts from a subset of one field to another field.
   I believe we agreed that there would be no guarantees that the
   values on nonparticipating sites in the destination field would be
   preserved -- that one should expect that the entire destination
   field was reset before receiving the shifted data.

3. Predefined types.  Some members of the committee didn't like
   James's way of constructing a gauge field as an array of four SU(3)
   matrix fields, meaning that the four fields for a single site would
   not be stored contiguously.  If we try to define a gauge-field type
   where each member is a set of four SU(3) matrices, we complicate
   the arithmetic seriously, since we will need operations between
   SU(3) matrix types and gauge-field types.

   Our predefined types have to be kept to a small set - at least with
   our present scheme.

4. I did a cursory glance through the MILC code to see to what extent
   the code could be brought into conformity with our current view of
   Level 2.  While a great many algorithms could be made to conform,
   there are many places where we do things that are slightly outside
   the current scheme.  So I would recommend

   a. Making it easy to remove and reinsert selected fields into
      Level 2 data types.

   b. Making it easy to define subsets for masking operations.

   c. Allowing the definition of custom data types and providing for
      callback functions to define arithmetic on them.

      The last approach might also be used to define all arithmetic
      operations on Level 2.



QLA

1.  After our discussion about imaginative layouts for Level 2 data I
    needed assurances that Level 1 QLA is still going to operate on
    arrays of elementary types, such as an array of SU(3) matrices,
    laid out as matrix, matrix, matrix.

I will have more, but have to run.

Regards,
Carleton