ARSC HPC Users' Newsletter 285, January 23, 2004

"Discovery Tuesdays"

Join ARSC researchers and staff the first Tuesday of each month at 1 pm for seminars about projects currently underway in the Discovery Lab. Learn about current work in the field of virtual reality, how you might use the lab to enhance your research or teaching endeavors, and how UAF researchers are contributing to state-of-the-art science.

The first seminar will be:

SUBJECT: "Interactivity and Discovery Lab Application Design"
PRESENTER: Dr. Chris Hartman, Joint Appointee, ARSC/Computer Science
DATE: February 3, 2004, 1pm
LOCATION: Rasmuson Library, room 375 (ARSC Discovery Lab)

Future topics will include art, space weather, and bioinformatics.

ARSC Training and UAF Physics Computational Science Course

In the past, ARSC staff have been offered individual training sessions on a variety of topics. For the Spring 2004 semester, ARSC is trying a new format by supporting a 3 credit, semester long course: PHYS693, "Core Skills in Computational Science."

This course will include most of the established ARSC training, but will delve deeper. It also features lectures from Physics Department faculty members, new material from ARSC staff, labs, exercises, and outside reading.

The core skills class provides intensive training for enrolled students, while still providing distinct modules for ARSC users and researchers with limited time and/or specify interests. (The homework will, of course, be optional for attenders who are not enrolled for University credit).

All classes will be held from 9:15-11:15 AM in Gruening 211 on the Fairbanks main campus. Those interested in attending individual sessions throughout the semester MUST pre-register by sending an email to

Class Schedule:

    Introduction to ARSC & HPC

    Skills to Run Codes, Part 1

    Skills to Run Codes, Part 2

    Skills to Run Codes, Part 3

    Skills to Run Codes, Part 4

    Introduction to Fortran

    Performance Programming, Part 1

    Performance Programming, Part 2

    Performance Programming, Part 3

    Parallel Shared Memory Programming, Part 1

    Parallel Shared Memory Programming, Part 2

    Parallel Shared Memory Programming, Part 3

    Parallel Shared Memory Programming Example

    Parallel Distributed Memory Programming, Part 1

    Parallel Distributed Memory Programming, Part 2

    Parallel Distributed Memory Programming, Part 3

    Parallel Distributed Memory Programming Example

    Validation and Examples

    Storage and Managing Data

    Visualization and Complex Data Presentation, Part 1

    Visualization and Complex Data Presentation, Part 2

    Visualization and Complex Data Presentation, Part 3

    Visualization and Complex Data Presentation Examples


See: for future updates and more information.

Portable Direct Unformatted I/O in Fortran

[ Thanks to Andrew Lee of ARSC for this article. ]

The Fortran standard specifies that the units for record length (recl) for direct assess unformatted files is compiler dependent. On some systems, such as the Cray X1, the recl unit is bytes. On others, such as the SX-6, the default recl unit is words. This isn't an issue until you start porting codes and files between systems where the recl units are different.

The SX-6 allows the recl unit to be changed at run-time using the environment variable, F_RECLUNIT. F_RECLUNIT can take on either of the settings, "WORD" or "BYTE." For more on this, see the SX-6 on-line Fortran manual or HPC Newsletter #260

Not all systems have an option to make the compiler conform to your code. Plus, when writing a portable code, it's best to avoid platform dependent compiler options and settings as much as possible.

This is where the Fortran INQUIRE statement is useful. The following code sample shows use of INQUIRE with the keyword IOLENGTH. It assigns the variable "reclength" the size of the variable "record_in" in recl units. As shown, the subsequent open statement with RECL=reclength will be correct when reading "record_in" records, whether the recl units are bytes, words, nibbles, or whatever.

  integer,parameter :: i_size = 50, j_size=100
  real*8 :: record_in(i_size,j_size)
  integer :: reclength

  inquire(iolength = reclength) record_in
  open(unit=10,file='file_in', &
  read(10,rec=1) record_in

Here's a quick demonstration of Fortran's INQUIRE as well as the SX-6 F_RECLUNIT environment variable. It shows how changing the recl units changes the value of recl, although the actual size of the record remains the same:

  sx6$ cat recl_test.f90
    program recl_test
      integer,parameter :: i_size = 50, j_size=100
      real*8 :: record_in(i_size,j_size)
      integer :: reclength
      inquire(iolength = reclength) record_in
  sx6$ export  F_RECLUNIT=WORD      
  sx6$ ./recl_test                  
  sx6$ export  F_RECLUNIT=BYTE
  sx6$ ./recl_test           

Solving the recl unit problem is, of course, only one step to correctly reading an unformatted file which was generated on some other platform. Other issues include data representation (e.g., IEEE vs Cray floating point), variable size (e.g., 4 byte vs 8 byte), and record blocking (e.g., f77 vs cos).

Book Review: "A Computer Called LEO"

[ Many thanks to Guy Robinson for this review. ]

Full Title: "A Computer Called LEO: Lyons Teashops and the World's First Office Computer."
Author: Georgina Ferry
ISBN: 1-84115-185-8

This book chronicles the development by Lyons Teashops of what is known as the world's first office computer. A key part of Lyons business was the supply of cakes and buns to many thousands of customers in its own teashops and elsewhere, managers needed accurate information on sales and orders to ensure this business was run at a profit. Applying scientific management principles had resulted in detailed information being collected at all levels. This data was then collated by thousands of clerks using manual and early electronic adding machines. Lyons managers sought a better way to generate these reports, and to hopefully reduce the tedious work of the clerks involved so that they might be freed to attend to the business itself.

At this time several groups were involved in the construction of a variety of computing engines, seeking to take advantages of the advances in electronics that occurred during the Second World War.

Lyons staff considered carefully what parts of their business might benefit from a computer, and then they went seeking a system that would meet their needs. Eventually additional funding was offered to a group from Cambridge working on a machine for scientific computations. At this stage many of the features of modern computers were still to be developed, the book covers these briefly but pays particular attention to the needs of the business user. The need to complete complex tasks to a business driven schedule drove the development of many of the aspects of computers we now take for granted. Due to the hard work and inventiveness of the many people involved the machine was soon in production, taking on an increasing variety of tasks and completing them reliably, and in record times. The book draws particular attention to how Lyons applied the same rigour of process from the business reporting to the development of machine equivalents.

After this internal success Lyons determined that there were other companies that might benefit from their approach and embarked on selling machines. Lyons differed in approach to many of the other companies that were emerging as providers of computers at the time, they would spent a considerable time working with customers to find out their needs, understand their processes, and then work with them to develop solutions. Very often there were changes to the business process to aid the inclusion of the machine. At its height Lyons was selling a great many machines to leading companies in the UK. However international competition and the costs of maintaining leadership in a rapidly advancing technological field was too much of a challenge for a small company. Eventually the project began to encounter difficulties and following a series of mergers and partnerships this impressive leadership in the application of technology was lost.

This book provides an insight into the workings of a successful project to apply a new technology in a new arena. Many of the people named in the project were the pioneers of the application of computers and the principles they applied within the projects at Lyons set the standards for operations today. I will leave it to others to determine if the goal of reducing the tedium of work was achieved by the application of computers in business.

Quick-Tip Q & A

A:[[ My overworked nephew, the elementary school teacher, emailed yet 
  [[ another arithmetic assignment to his 6th graders without knowing the
  [[ answers first. I'd like to help him out. Is there a quick way I can
  [[ compute the answers for him?  The problems all have the same basic
  [[ format, as shown in this sample from his ASCII email:
  [[ myworkstation$ 
  [[ myworkstation$ tail -n 12 mathproblems.txt
  [[  14)  Division problems:
  [[      56 / 2.34 = ________
  [[      2.34 / 56 = ________
  [[  15)  Multiplication: 
  [[      33.3 * 12.3 = ________
  [[      12 * 22 * 8 = ________
  [[      33.3 * 12.3 * 12 * 22 * 8 = ________
  [[  Extra Credit:
  [[      1 + 2 + 3 + (4) * 2 = ________
  [[      1 + 2 + (3 + 4) * 2 = ________
  [[      1 + (2 + 3 + 4) * 2 = ________

  # Once again, we have lots of variety... Perl, Python, and bc.

  # Thanks to Rich Griswold:
  Here's a perl script that'll do the job.  It's pretty short, but I'm
  sure a true perl guru could do it with a tenth the amount of code :)

  #!/usr/bin/perl -w
  foreach ( <STDIN> ) {
    if ( $_ =~ /=/ ) {
      $e = $_;
      $e =~ s/=.+$//;
      $e = eval $e;
      $_ =~ s/_+$/$e/;
    print $_;

  # From Kate Hedstrom
  As always, I would use Perl:

  beluga% more homework
  #!/usr/bin/perl -w

  use strict;
  while(<>) {
     if (/(.*)=/) {
        print "$1= ";
        print eval($1);
        print "\n";

  beluga% homework prob.set
      14)  Division problems:
          56 / 2.34 = 23.9316239316239
          2.34 / 56 = 0.0417857142857143
      15)  Multiplication:
          33.3 * 12.3 = 409.59
          12 * 22 * 8 = 2112
          33.3 * 12.3 * 12 * 22 * 8 = 865054.08
      Extra Credit:
          1 + 2 + 3 + (4) * 2 = 14
          1 + 2 + (3 + 4) * 2 = 17
          1 + (2 + 3 + 4) * 2 = 19

  The "while(<>)" syntax reads each line of input in turn, making it the
  default in all search and print operations. First, we search for the
  "=" in the problems. If one is found, evaluate everything before the
  "=" and print it, after printing the expression being evaluated.
  Otherwise, print the line unchanged.

  # From the editor.
  The magic is that little "e" after the s///.  The "e" says to evaluate
  the text of the replacement string as if it were perl code:

  $  perl -p -e 's/(.*)=.*/"$1 = ".eval($1)/e' mathproblems.txt

  # From Martin Luthi:
  Python is the software you want to use. It's interactive, it's
  flexible, it's powerful, it's readable, it's great!

  Here the solution for your problem:


  solution = []
  for line in open('problemfile.txt'):
      idx = line.find('=')  # if this is an equation
      if idx > 0:
          solution.append( '%s= %s \n' % (line[:idx], eval(line[:idx])) )



  Of course you can condense this even more, but this would make the
  program harder to read. 

  Python is free software and available at: "". 
  A nice distribution for Windows users is available at:

  # Greg Newby
  Let's presume that all the items to be solved have the same form as
  above: a problem followed by an equals sign and a set of dashes.  So,
  we just need to grab the "problem" part, and send it to a program that
  can properly interpret and solve it.

  One such problem that's widely available is "bc", an arbitrary
  precision calculator program for Unix and Linux systems.  Unlike a
  somewhat more common program, "dc", bc doesn't use reverse Polish
  notation (RPN), and can handle virtually any standard arithmetic or
  algebraic syntax.

  Since we want to make sure we get proper floating point decimal output
  (not truncated or rounded), we'll preface our first bc command with
  "scale=5" for 5 decimal places.  "man bc" for more details.

  In my example, I saved the file with the problems to "mathproblems.txt"

  ( echo "scale=5" ; grep = mathproblems.txt 
 sed 's/= ________//' ) 

  The last part, "
 bc" is the pipe that takes the input from the first
  part.  I'm running it in a subshell (the parentheses) so that
  everything on the left goes as one sequence to one "bc" command.  This
  might not be the ideal output, since it will just list answers, not
  the problems or their numbers - but making prettier output (which
  would probably involve calling "bc" for each problem separately) is
  left as an exercise for the Unix/Linux programmer.

  The middle part of the statement will make sure that only the lines
  with problems are considered (those with an "="), and strip out the
  unneeded "= ______".


Q: [  Here's one from Guy Robinson.  No computers allowed!  ]

  After many years of abuse, the multiply unit of my favourite 
  calculator finally gave out. 

  As I've been tasked to compute the squares of all numbers from 
  1 to 100, I'm really not looking forward to typing in 99 and then
  +99, 98 times or pressing the repeat key. I guess I'd also have
  to repeat the calculation to make sure I'd really got the right
  answer to add to the effort! Any suggestions as to a better way
  to do this with fewer key presses and perhaps less chances of
  making a mistake?

    ps:  My calculator is pretty simple, it doesn't have a log
         function.  ;-)

[[ 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