ARSC T3E Users' Newsletter 174, July 30, 1999

PGHPF -Msmp Option

Doug Miles of The Portland Group suggests that T3E HPF users try the pghpf option, "-Msmp". From his message;

It generally helps quite a bit performance-wise -- it causes the compiler to try to do comms via direct manipulation of the E-registers rather than via shmem-based library calls. The comms overhead is often significantly lower with -Msmp.

In my trivial test, the -Msmp option gave a 7x speedup, but we'd love to hear results from users with big HPF codes.

CUG T3E Workshop, Oct 7-8

T3E Users: here's a conference for you!

CUG (The Cray User Group) has scheduled an intensive T3E Workshop for October 7-8, 1999, in Princeton, New Jersey. Go to http://www.cug.org/ for registration and details. The following is from the web page:

Workshop Goals

The Cray T3E has been an outstanding success in the field of massively parallel computation. What are these successes? What is the future for these machines and codes? The Workshop will feature applications, software updates, and plans for the future. Application Programmers, Managers, and System Administrators should attend.

Where and When

The Cray User Group T3E Workshop will be held in Princeton, New Jersey on October 7 and 8, 1999. It will begin with a reception on the evening of October 6th and there will be a workshop dinner on October 7th. Sponsors for the Conference are CUG, SGI and IDA Center for Communications Research, Princeton.

Registration

Registration fees for the meeting are:

  • $195 for CUG members
  • $695 for the first person from a non-member site ( includes a membership in CUG for one year, January 1, through December 31, 2000)
  • $195 for additional attendees from non-member sites.

The registration form is available on line.

Technical Program

The meeting will be one-track for two days starting at 8:30 on Thursday, October 7th. Planned sessions include:

  • User applications
  • Tutorials
  • Optimization
  • Roadmap and software update
  • Scheduling on the T3E
  • Libraries and other third party projects

There is room for additional talks. Please contact a member of the Program Committee with your abstract. The Preliminary Technical Program will be available from this web site later in the summer.

Monitoring T3E NQS Queues and System Utilization

We haven't tried this tool, but it looks interesting. (Taken from: http://www.fz-juelich.de/zam/trend/ )

> Trend Overview
> 
> Trend allows you to supervise the run, wait, and NQS batch queues as
> well as the system utilization of a CRAY T3E system. The Trend system
> is a distributed client/server application which consists of:
> 
>   1. a Trend demon process running on the Cray T3E system to supervise. The
>      demon captures all necessary data once a minute and transfers it to,
> 
>   2. a (conventional) WWW server.
> 
>   3. The Trend display clients run on the user workstations and get their
>      data from the WWW server.
> 
> The main reason for this design was to keep the additional load on the
> Cray T3E as minimal as possible, even if Trend is heavily used. Using a
> conventional WWW server instead of a specialized server has several
> benefits: WWW servers are designed to efficiently distribute data in a
> secure way, allow access control, are very common and already
> installed, keep access logs, and finally, any WWW browser can be used
> to access the Trend data from anywhere in the world.
> 
> The user visible part of the Trend system is the user clients.
> Currently, are implemented:
> 
>    * trend, a platform specific X11 client implemented in Tcl/Tk
>    * jtrend, a portable client implemented in Java
> 

Quick-Tip Q & A


A:{{ I've been handed a large Fortran 77 program, and need to get it
     going.  F90, however, is finicky about type consistency and won't
     compile it.  This example shows one of my problems:

         program test
         implicit none
         integer*4  int4
         integer*8  int8
         integer*8  res8

         int4 = 4
         int8 = 5
         res8 = mod (int8, int4)

         print*, res8
         end

   Here's the error printout from the f90 compiler:

        yukon$ f90 test.f             
                 res8 = mod (int8, int4)
                        ^                
          cf90-774 f90: ERROR TEST, File = test.f, Line = 9, Column = 15 
            Improper intrinsic argument type or inconsistent types.

   Any suggestions? }}


##################################################################

Many thanks to Ed Anderson of Lockheed Martin Technical Services and
NESC for these solutions:

####
The example in this week's ARSC newsletter about improper intrinsic types is a common Fortran 90 pitfall. A Fortran 90 purist would say that the types don't match and you should change your program to make sure this doesn't happen. There are three less extreme solutions:
  1. Use the compiler option f90 -s cf77types modtest.f. The compiler gives you a warning, but it works. This is Cray-specific.
  2. Use a macro expansion to massage the types of the arguments to the MOD function. This is kind of dangerous because macros are case sensitive, while Fortran itself is not. It may also be Cray-specific.
    
    #define MOD(x,y) mod(int(x),int(y))
    !     Compile with f90 -F test1.F
          program test
          integer*4  int4
          integer*8  int8
          integer*8  res8
    
          int4 = 4
          int8 = 5
          res8 = MOD(int8, int4)
    
          print*, res8
    
          end
    
  3. For object oriented programming fans, overloading the MOD function is the way to go. The downside is you would have to add USE statements in all the subroutines where the MOD function is giving you trouble.
    
          module GMOD
          interface mod
             module procedure gmod48
             module procedure gmod84
          end interface
          contains
             integer(kind=8) function gmod48( i4, j8 )
             integer(kind=4) :: i4
             integer(kind=8) :: i8, j8
             i8 = i4
             gmod48 = mod(i8,j8)
             return
             end function gmod48
    
             integer(kind=8) function gmod84( i8, j4 )
             integer(kind=4) :: j4
             integer(kind=8) :: i8, j8
             j8 = j4
             gmod84 = mod(i8,j8)
             return
             end function gmod84
          end module GMOD
    
          program test
          use GMOD
          integer*4  int4
          integer*8  int8
          integer*8  res8
    
          int4 = 4
          int8 = 5
          res8 = mod (int8, int4)
    
          print*, res8
    
          end
    
This and other Fortran 90 pitfalls are discussed in a presentation I gave here at NESC:

http://persimmon.nesc.epa.gov/docs/NESC/unicos10.html


Q: When I try to submit jobs, I get the following response:

     t3e$ qsub -q mpp job.script
       NQS local daemon is not present at local host.
       Retry later.

   What should I do? 

[ 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