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:
- 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!
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 /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 (email@example.com) 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: http://www.spscicomp.org/index.html :
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:
[ 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 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?
[[ Answers, Questions, and Tips Graciously Accepted ]]
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
Subscribe to (or unsubscribe from) the e-mail edition of the
ARSC HPC Users' Newsletter.
Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.