ARSC HPC Users' Newsletter 270, June 13, 2003

Contents

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:

Vector CPUs and high memory bandwidth. (Like the SV1ex and SX-6.)

Scalable architecture with single system image. (Like the T3E.)

CPUs grouped in shared memory "nodes". (Like the IBM SP.)

Worksharing and parallel programming models available:

OpenMP (across CPUs within a shared memory node)

MPI (across any CPUs on the system)

Co-array Fortran (across any CPUs on the system)

UPC (across any CPUs on the system)

SHMEM (across any CPUs on the system)

"Hybrid." For example:

MPI for internode communication,

OpenMP for intranode shared-memory worksharing

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!

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
/arsc/support/news/t3enews/t3enews176/index.xml
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 (consult@arsc.edu) 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.]

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.

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.

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
web:
"... 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?

The University of Alaska Fairbanks is an affirmative action/equal
opportunity employer and educational institution and is a part of the University
of Alaska system.
Arctic Region Supercomputing Center (ARSC) |PO Box 756020, Fairbanks, AK 99775 | voice: 907-450-8602 | fax: 907-450-8601 | Supporting high performance computational research in science and engineering with emphasis on high latitudes and the arctic.
For questions or comments regarding this website, contact info@arsc.edu