ARSC HPC Users' Newsletter 270, June 13, 2003



ARSC X1 Update and Intro

ARSC technical and user services staff are now using "klondike". We're preparing it for users, getting to know it, and testing it. Several user codes have been ported for testing purposes.

A user called this week regarding the X1. He's developing a code, and wanted the basics of the system, to help program accordingly. So, here's a quick programmer's overview of the X1:

  1. Vector CPUs and high memory bandwidth. (Like the SV1ex and SX-6.)
  2. Scalable architecture with single system image. (Like the T3E.)
  3. CPUs grouped in shared memory "nodes". (Like the IBM SP.)
  4. Worksharing and parallel programming models available:
    1. OpenMP (across CPUs within a shared memory node)
    2. MPI (across any CPUs on the system)
    3. Co-array Fortran (across any CPUs on the system)
    4. UPC (across any CPUs on the system)
    5. SHMEM (across any CPUs on the system)
    6. "Hybrid." For example:
      1. MPI for internode communication,
      2. OpenMP for intranode shared-memory worksharing
      3. Co-Array Fortran or SHMEM for MPI bottlenecks.

For best performance, number 1 is first on the list. Your code should have a high vector fraction. ARSC analysts will be happy to work with you, helping test and assess your code, and work on optimizations for the X1. Also, this newsletter will be heavy with X1 articles as we ramp up, so don't miss an issue!


Leone Thierman has posted another time-lapse movie: assembling klondike. It's a QT movie, 6.5 MB, about 3 1/2 minutes:


IBM SP Batch Queues

As previously announced, the LoadLeveler class structure on icehawk was updated.

Excerpt from Icehawk, "news queues":
  The maximum number of nodes that can be used by jobs in any class
  except "special" is 24.  (96 processors). 

  Unless the system is idle only one job per user will start -- others
  will wait in the queue. Even if idle max jobs per user is 3.

  We recommend job chaining instead of simultaneous submissions.  For
  more information on job chaining see our HPC Newsletter articles:
          /arsc/support/news/hpcnews/hpcnews259/index.xml and

  Time partitioning:
  8 "quick turnaround" hours (0600 AK time/1000 Eastern to 1400 AK
  time/1800 Eastern) are reserved daily. During this period no short job
  should wait more than 4 hours to execute unless special work
  interrupts job flow.  Killable jobs may be allowed during this period
  but only if they will not interfere with short work.

  During the remaining 16 hours preference is given to longer work.

  In general, "short" and "killable" jobs will run throughout the day,
  though these classes may not always be starting new work. Killable
  work may be killed at any time to facilitate the flow of large or
  short jobs, depending on the time of day.  Short jobs will run at
  night, though they have a lower priority than large jobs so large work
  will run first when that class is active. The hours when large jobs
  will start are restricted to the 8 hour period between 14:00 and 22:00
  AK time so we can guarantee that "large" work will finish by the next
  quick turnaround period.

  Available classes:
  Summary: use 
    - "short" if your job will complete in 4 hours
    - "killable" if your job uses restart files 
    - "work" for I/O involving mass storage 
    - "large" only for longer runs without restart capability

  Class Name      Max Time        Intended Purpose
  ----------      ---------       --------------------------------------
  work            4 hours         data transfers to/from icehawk1,2,3
                                  nodes.  (archived mass storage mounted
                                  on icehawk nodes only).

  short           4 hours         production jobs which will finish in
                                  <= 4 hours.  Starts all day except
                                  14:00-18:00 drain to ensure larger
                                  jobs get a chance.

  large           8 hours         longer jobs which cannot be restarted.
                                  Started 1400 AK/1800 Eastern to
                                  2200 AK/0200 Eastern only.

  killable        8 hours         long jobs which can be restarted.
                                  killable at any time to facilitate
                                  job flow. 

  special         48 hours        "special case" runs only --jobs  that
                                  exceed the conditions of the normal job
                                  classes either in wallclock time or
                                  number of processors.

  Please contact the ARSC Help Desk ( for access to
  "special" and let us know with as much advance notice as possible when
  you intend to use it.

[ This is only half of "news queues". Read the news item for details on "killable" vs "large". Also, we welcome feedback and suggestions on the class/queue structures on all our systems.]


2003 ScicomP 8

ScicomP 8 will be held in Minneapolis, Minnesota:

August 5-8 2003

Early Registration Deadline:

July 11, 2003

For registration, the agenda, tutorials, etc., see:

What is SCICOMP? From: :

The IBM System Scientific Computing User Group, SCICOMP, is an international organization of scientific/technical users of IBM systems. The purpose of SCICOMP is to share information on software tools and techniques for developing scientific applications that achieve maximum performance and scalability on systems, and to gather and provide feedback to IBM to influence the evolution of their systems.


ARSC Summer Tours: Wednesdays at 1pm

This year our Summer Tours are being held in the Discovery Lab in the Rasmussen Library. As in past years: Wednesdays 1pm. For more info on our tour, and all summer tours at UAF, see:


Book Reviews

[ Here're the latest book reviews from Guy Robinson. If *YOU* read a good science or computer book and care to review it, let us know! Don't worry, we're not going to grade it. ]

Minds, Machines, and the Multiverse: The Quest for the Quantum Computer. By Julian Brown. Publisher Simon and Schuster.

This presents a good background for those already familiar with programming and quantum physics about the challenges facing the building and operation of a quantum computer. You've perhaps heard that these systems are going to revolutionize certain areas of computing and that great steps are being made in making them a practical reality. This book not only covers the physics and mathematics involved but addresses some of the philosophical ideas behind what really powerful computers might be used for and how this might impact our understandings of intelligence.

Best American Science and Nature Writing, 2000. By: Quammen and Bilger. Publisher: Houghton Mifflin Co.

Found this remaindered in a bookstore in DC and just glanced at a few pages and thought it would be good reading on a flight. I'm always interested in the different ways science is written up by all interested parties. It contains a number of essays taken from other publications which cover a varied collection of topics. These can be read with different viewpoints, an interest in the science and the activity, the potential impact of the science on culture, and the way the author is getting across ideas. Many of the items are taken from magazines like New Yorker and the Atlantic and a few from science mainstream.

There is actually a series of these, not just a new one each year but also some different topics.

The Zen of Proposal Writing. By; Reeds. Publisher: Three Rivers Press.

If you've ever written a proposal you know that it involves a lot more than putting words on paper. This provides a good overview of the activities and interactions and many of the basic principles are covered about getting messages across to readers and how to work in a team creating a document describing a plan. It doesn't really matter if you're facing your first proposal activity or if you've written hundreds of successful proposals, this book can serve to focus your activities in a light hearted manner.


Quick-Tip Q & A

 A:[[ I had, yes, note past tense... a couple files to save, several to
  [[ delete, and some of those to delete had permission 400.  They looked
  [[ something like this:
  [[ $ ll
  [[  total 144
  [[  -rw-------   1 saduser  sadgroup    4280 May 23 15:36 d
  [[  -rw-------   1 saduser  sadgroup     535 May 23 15:36 e
  [[  -rw-------   1 saduser  sadgroup   17120 May 23 15:35 f
  [[  -r--------   1 saduser  sadgroup    8560 May 23 15:35 a
  [[  -r--------   1 saduser  sadgroup    2140 May 23 15:35 c
  [[  -r--------   1 saduser  sadgroup    1070 May 23 15:35 b
  [[ To simplify my life, I did this, 
  [[   rm -i -f ?
  [[ I expected "rm" to ask about each file before deleting it, and to
  [[ take care of the "400" files automatically. Oh well..  it blasted
  [[ them all, and didn't even ask.
  [[ If there's a question in all this, maybe you could answer it.  I'm
  [[ too upset to think.

   According to the "man" page, the order of the -i and -f matters. 
   Whichever comes last overrides the other:
     "rm -f -i ..."  --  ASKS 
     "rm -i -f ..."  --  DOESN'T ASK 
   We'd suggest you try to avoid "-f" and always take care when using
   wildcards with "rm".

Q: Here's one person's definition of "code-blindness", grabbed off the

     "... the inability to actually work out what on earth your code is
     doing, even though you were wholly responsible for it..."

   Programmers: do you have a technique for snapping yourself out of
   code-blindness, or avoiding it in the first place?

[[ Answers, Questions, and Tips Graciously Accepted ]]

Current Editors:
Ed Kornkven ARSC HPC Specialist ph: 907-450-8669
Kate Hedstrom ARSC Oceanographic Specialist ph: 907-450-8678
Arctic Region Supercomputing Center
University of Alaska Fairbanks
PO Box 756020
Fairbanks AK 99775-6020
E-mail Subscriptions: Archives:
    Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.
Back to Top