All,

            Date:     04/12/07
            Day:      Thursdays
            Time:     1pm    to      3pm
            Participants:   18
            Telephone Number: 617-452-5208


USQCD reveiw in May:

The USQCD project is being reviewed by the DOE at JLab on
May 14-15, 2007. While the SciDAC software component is not
the major focus of  the review, it is still important. I will give a short
report on  SciDAC softare and Kostas will report on user experience.

For this meeting I would like to collect upto date infromation  ---
particularly performance & code readiness for the Cray XT4 and the
BlueGene/L, workflow plans and  threaded software requirements.



=============== Agenda ======================



1. Finalize Propagator File Format --- see appended note from Carleton,
      also posted at http://super.bu.edu/~brower/ccs as usual
     (Carleton, Osborn, Bob M, et al)

2. Multi-threading/Mulit-core plans:
    (Robert, Jie, Andrew, Rob et al)

3. Et al.


Rich


-- 
Richard C. Brower
Physics Department --- Boston University
590 Commonwealth Ave. Boston, MA 02215
Office: Physics Research Building, Room 581
Tele:    617 353 6052 (BU)
         617 253 2599 (MIT)
         617 833 5811 (CELL)
Fax:     617 358 2487
Email: brower@bu.edu
       brower@lns.mit.edu



============== Propagator Format  Note from Carleton ==============
Hi Folks,

>From our discussion on Thursday, I believe we were left with three
propagator formats for our initial use cases.  Let's just look at the
record content and the required metadata before we get into byte
order.

I am not completely happy with the names I have given the file
formats, so please suggest better ones if you can.

Note that this proposal does not involve changes to QIO.  The higher
level codes (QDP, MILC, CPS, QDP++) would need to support them and
figure out how to distinguish them.  QIO provides enough functionality
that the required higher level support should be easy.

Regards,
Carleton

---------------------------------------------------------------------
Record content and order
---------------------------------------------------------------------

1. USQCD_DiracFermion_ScalarSource_12Sink

   Here the source is given by one complex scalar field and the same
   scalar field is used for each source color and spin.

   Logical record 1: The complex scalar source
      (Do we allow a single-precision source and double precision solutions?)

   Logical records 2 - 13: DiracFermion sink fields
       Solutions for each choice of source color and spin

2. USQCD_DiracFermion_Source_Sink_Pairs

   Here we specify the full source field and its solution field.
   There can be any number of such pairs.

   Logical record 1: DiracFermion field (source)
       Source #1
   Logical record 2: DiracFermion field (sink)
       Solution #1
   Logical record 3: DiracFermion field (source)
       Source #2
   Logical record 4: DiracFermion field (sink)
       Solution #2
   etc.

3. LHPC_DiracPropagator

   Logical record 1:

     Here a single record contains the full propagator.

     (Should we require a complex scalar field for the source as
      we did in type 1?)

---------------------------------------------------------------------
Required metadata
---------------------------------------------------------------------

The QIO format has file and logical record XML strings.  We would use
both.  The file XML string should have the following required fields:

      file type (see name above)
      prevailing precision (32 or 64 -- or we could use F and D)

Then for the individual file formats above we would have

1. USQCD_DiracFermion_ScalarSource_12Sink

    Nothing required for the source
    For the sink field, for safety, we probably need the source

       spin
       color

    even though we adopt a standard order for the records.

2. USQCD_DiracFermion_Source_Sink_Pairs

    In the file XML do we need to specify the number of source/sink
    pairs expected?  QIO has the capability of appending to a file, so
    if we specify it in the file XML, that number would not be
    updated.

    Since all the records are DiracFermion fields, it is probably a
    good idea to distinguish:

        "sink" or "source"

---------------------------------------------------------------------
Optional metadata
---------------------------------------------------------------------

Beyond these required fields for any of the user XML, we would allow
an additional optional tag that nests any collaboration metadata.  For
example, in the file XML, it would be a good idea to identify the
corresponding gauge field file and specify and gauge fixing, etc.