Software Coordinating Committee Conference Call
		       August 14, 2003 3:00 PM EDT
			  Recorder: C. DeTar

Present:
  Osborn, DeTar, Brower, Edwards, Simone, Mawhinney
  (Advertised as the I/O subcommittee.)

=====================================================================

       #0.  Benchmarking

    DeTar:  As for benchmarking the MD code, it seems more useful to
            quote wallclock time to do one step.  This is a function
            of the number of CG iterations.  So it depends on quark mass
            and whether the starting lattice is equilibrated.
    Brower: It would be important, however, to see the breakdown of
            time spent in the inverter and the fermion force term.
    Brower: We need information for several granularities.  
            Can we get information about the number of CG iterations
            vs quark mass?
**  DeTar:  We have this for Asqtad.  I can provide it.  But not for clover dynamical.
**  Brower: I will see about getting this for clover dynamical.
    DeTar:  What if we quote the MD timing as a linear function
            a + b*Ncgiters?

       #1.  Eric visit to Columbia mid September

    Mawhinney: The first motherboard should be assembled in the next
            week or so.  So assuming it arrives bug free, the timing
            is good.  Should have a 64 processor motherboard by
            mid-Sept time.  Even if that time slips, there are single
            processors on test jigs that Eric can make productive use
            of.  Zbigniew "Zbyszk" Sroczynski (UK) will be at Columbia
            at the same time developing the fermion force term under
            CPS.  Chulwoo will be available to help.

        #2. Level 3 inverters

    Mawhinney: We need to deal with the storage order.  How should the
            API work?
    DeTar:  We have specified QDP callback functions to determine where
            the data is.  The Level 3 inverter should take these
            and do the remapping and the inverse mapping.
            The inverter can check on first call to be sure that
            the data order conforms to what it expects.
    Mawhinney: What about data order?
    DeTar:  We have qla accessor macros in qla.h that are generic
            for getting components of a composite type.
    Mawhinney: Would a non-QDP user be willing to provide these
            macros?
    DeTar:  There are three options: (1) QDP user - use the qla
            definitions of the accessors.  (2) non-QDP standard user -
            use the standard accessors.  (3) non-QDP non-standard user -
            must then provide them.
    Mawhinney: I would prefer not to make the Level 3 code depend on
            QDP or QLA.  Instead a stack of callback accessor
            functions.  Define a "medium raw" order for bytes within a
            site which the Level 3 interface would assume.  We have
            three entries: (1) Canonical order call (2) Noncanonical
            with a stack of accessor functions. (3) Full QDP interface
            taking QDP fields.
    DeTar:  Should the format specify double or single precision?
    Mawhinney: Perhaps through a flag in the calling sequence.

    We agreed to this for QCDOC.

    DeTar:  Are we including the site layout in the definition of
            "canonical order"?  What if a user has nonstandard 
            site layout, but canonical byte order within a site?
            Could we add (4) canonical byte order within a site
            but discovery for sites?
    Mawhinney: This would come later.
**  Mawhinney: So what is the medium raw layout?  Could we agree on this?


       #3. Benchmarks: single precision vs double

    Mawhinney: Double precision is more natural for QCDOC.  Single
       for clusters.
    Brower: The benchmarks should reflect the normal operating
       conditions for the machine.  So QCDOC can quote double
       and clusters single for now.

       #4. I/O

    Edwards: What is the time frame for the C interface?
    Simone: Currently can take any xpath query and convert to a string.
      Still need to convert to types.
      Still need extra write pieces to build trees.
    Edwards: Need to reconcile functionality.
    Simone: I am planning to build in the possibility of
      changing values in a tree and then serializing.
    Osborn: I would also like to have this feature.
    Edwards: There is a way to do that with my C++ version, but
      only in the process of copying input to output - not by
      storing a tree in memory and then manipulating it.
    DeTar: We need to schedule another discussion.

     We agreed to 4 PM EDT tomorrow.  Edwards to initiate the call.

=====================================================================
Committee conference concluded at 5:05 PM EDT.  
Next plenary call August 21 at 3 PM EDT.