BNL Plans (Bob)

Here's an overview of the software projects we have before us for
QCDSP and QCDOC.  The personnel involved are denoted by:

  CU	- Columbia
  RB	- Riken/BNL
  UK@CU	- UKQCD personnel located primarily at CU
  UK	- UKQCD (including personnel at EPCC)
  SDAC	- SciDAC supported software personnel at BNL



1.  Evolving Columbia Physics System (CPS) to support ongoing research
    activities on QCDSP machines.  We have many new and ongoing
    projects and new measurements and techniques are continually
    being added to the existing code.  CU, RB.

2.  A more advanced scheme for getting myriad input parameters into
    the code is probably needed.  This is likely a common point for
    the US community.  CU, RB, SDAC.

3.  Evolving the CPS code base and build system to compile on a larger
    number of platforms.  The code is all C++, except for a few kernels
    in assembly, but there are a few steps needed to make it more
    generic.  In particular, uniform support for either single or
    double precision arithmetic is needed.  For QCDSP, it has only had
    to be single precision.  CU, UK@CU, UK, SDAC.

    Included in this, and a priority, is to have it all compile
    for the PPC440.  This is a vital step in checking our hardware
    ASIC design.  CU, UK

3.  Adding some optimized kernels to the CPS code for hardware other
    than QCDSP.  No current plan to optimize communication calls for
    other hardware.  This would make CPS run reasonably well on
    any platform, provided the local lattice volume per node was large
    enough to hide network latency.  UK@CU, UK, SDAC.

4.  Putting in MPI support "behind" the QCDSP/QCDOC communication calls,
    so CPS will run on any machine with MPI.  Best performance will
    be achieved by running with the native QCDSP/QCDOC communication
    calls. UK, SDAC.

5.  Development of operating system for QCDOC.  We have 4, commercial
    PPC405 boards and a dual processor UltraSparc, configured as
    4 QCDOC nodes will be.  We have a first pass OS, which resets
    the 405 boards, loads a boot kernel to them via Ethernet/JTAG
    and then has the boot kernel execute a sample program.  The host
    side of this OS is a multithreaded program that handles the
    ethernet connections and provides the user interface.  The 440
    core for QCDOC differs in only minor ways from the 405, from the
    OS point of view.
    
    This is a priority, since once QCDOC chips are available, they
    can only be fully tested if there is enough software to run
    a non-trivial machine of at least a few hundred nodes.  CU, UK@CU.

    Input into this OS development to support a larger base of users
    and to make this OS consistent with US community standards for
    a physics run-time environment is a vital.  Also documentation
    must be written and updated.  CU, SDAC.

6.  For QCDSP, a beta version of our parallel file system is now
    available.  This will be phased into production running on QCDSP
    over the next few months.  The CPS code will be enhanced to use
    this file system, including temporary storage of propagators.
    CU, RB.

    This is an important common point with the US community, as our
    common standard for parallel file systems for QCD is developed.
    SDAC.

7.  Compiling the MILC code for QCDOC.  This needs to be done before
    the design is finalized, to insure that MILC code is supported.
    It will also give an additional code base for ASIC verification.
    SDAC.

8.  Making sure that CPS is compatible with the evolving US QCD
    code standard.  SDAC.