ARSC HPC Users' Newsletter 246, May 31, 2002

(Brief) CUG Report

CUG SUMMIT 2002 was hosted by the University of Manchester (England) last week, The venue was the neo-gothic Manchester Town Hall, an impressive building of marble columns, archways, Italian tile, and elegance, completed in 1887. It was a privilege to spend a week in this building.

Monday and Tuesday were devoted to SGI presentations, Thursday and Friday, to Cray. Wednesday was a day of overlap, mostly for general keynote addresses and CUG business.

The time's ripe for increasing the degree of separation between the two vendors within CUG, one way or another. This will be a challenge and opportunity for CUG and the vendors this year. A new CUG president was elected, and it is ARSC's own, Barbara Horner-Miller.

Both vendors remain committed to their high-end customers, and cited their own R&D budgets as evidence.

SGI plans for the Origin 3000 include increasing MIPS chip density, cache size, and clock speed, doubling the number of processors per brick, and improving network and memory bandwidth for better scaling. They're also excited about the OpenGL Vizserver product for remote visualization.

Cray is pouring most of it's effort into the SV2, due for first customer ship this fall. The SV2 will have high-performance vector processors and memory bandwidth, in a distributed shared memory architecture, with T3E-like scalability. Cray is also working hard on bioinformatics software and applications for the Cray MTA-2.

Unix Tools for Portable Applications, Part II of IV

[ Many thanks to Kate Hedstrom of ARSC for contributing this series of articles. ]

The "makemake" Makefile generator

In the last issue, we talked about Makefiles and how to write them. In this age of computers, many people have worked hard on the problem of automatically creating Makefiles. Some of these tools are called makemake, the newest of which is for C and C++ only. However, there is one for Fortran (both f77 and f90) at:

http://www.math.unm.edu/~wester/

The web site contains both the script and a postscript document describing it. The script is written in Perl; the description has a brief introduction to Perl.

There is also a creation myth from Easter Island starring Makemake as the creator.

Fortran 77 example

Recall that last time we described the Makefile for a project consisting of three source files and one include file. Running makemake in the directory containing the source code:


    makemake model

generates the following Makefile:

PROG =  model

SRCS =  init.f main.f plot.f

OBJS =  init.o main.o plot.o

LIBS =  

CC = cc
CFLAGS = -O
FC = f77
FFLAGS = -O
F90 = f90
F90FLAGS = -O
LDFLAGS = -s

all: $(PROG)

$(PROG): $(OBJS)
        $(FC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)

clean:
        rm -f $(PROG) $(OBJS) *.mod

.SUFFIXES: $(SUFFIXES) .f90

.f90.o:
        $(F90) $(F90FLAGS) -c $<

init.o: commons.h
main.o: commons.h
plot.o: commons.h

Recall that we start with our macros (in upper case). It finds the SRCS list by searching the current directory for *.f90 *.f *.F and *.c. The first target here is "all", pointing to $(PROG), so invoking "make", "make all" and "make model" will all do the same thing. We also have a suffix rule for .f90 files, just in case, and it automatically generates the include file dependencies. This works as long as the Fortran files use the Fortran style of include:


      include 'commons.h'
not the C style:

#include "commons.h"

However, it will search C files for the C includes. It also does its very best to provide the Fortran 90 module dependencies.

This Makefile is an excellent start, but if you need to link to external libraries or use the xlf or g77 compiler, you will have to edit the Makefile accordingly.

Fortran 90 example

A friend wrote a graphics program containing a number of modules. The source filenames must have a .f90 extension for makemake to find the modules in them. Here is the resulting Makefile:


PROG =  drawcoast

SRCS =  contcolr.f90 contscript.f90 drawcoast.f90 gksstuff.f90 grid.f90 \
        kinds.f90 labels.f90 mapack.f90 neighbors.f90 numbering.f90

OBJS =  contcolr.o contscript.o drawcoast.o gksstuff.o grid.o kinds.o \
        labels.o mapack.o neighbors.o numbering.o

LIBS =  

CC = cc
CFLAGS = -O
FC = f77
FFLAGS = -O
F90 = f90
F90FLAGS = -O
LDFLAGS = -s

all: $(PROG)

$(PROG): $(OBJS)
        $(F90) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)

clean:
        rm -f $(PROG) $(OBJS) *.mod

.SUFFIXES: $(SUFFIXES) .f90

.f90.o:
        $(F90) $(F90FLAGS) -c $<

contcolr.o: contscript.o
contscript.o: kinds.o
drawcoast.o: contcolr.o contscript.o gksstuff.o grid.o labels.o mapack.o
grid.o: contscript.o neighbors.o
labels.o: contscript.o
mapack.o: contcolr.o contscript.o
neighbors.o: kinds.o
numbering.o: kinds.o

The last eight lines here contain the module dependency information. The file kinds.f90 contains module kinds, which is used by several of the other files. The kinds module file (kinds.mod or KINDS.mod) must exist when the using routines are compiled. These dependencies guarantee that kinds.f90 will be compiled first.

Cray modules

On the Cray, the default is to store the module information in kinds.o rather than in KINDS.mod. The compiler must be told to look in kinds.o when compiling the using routines. Makemake will generate the correct commands if you ask it to. This is done through an optional second argument, which is a hint about which compiler you will be using. Invoking:


  makemake drawcoast cray


produces these modified dependencies:


contcolr.o: contscript.o
        $(F90) $(F90FLAGS) -c -p contscript.o contcolr.f90
contscript.o: kinds.o
        $(F90) $(F90FLAGS) -c -p kinds.o contscript.f90
drawcoast.o: contcolr.o contscript.o gksstuff.o grid.o labels.o mapack.o
        $(F90) $(F90FLAGS) -c -p contcolr.o -p contscript.o -p gksstuff.o -p \
                grid.o -p labels.o -p mapack.o drawcoast.f90

On the other hand, the -em compiler option will cause the Cray compiler to produce the module files like any "normal" compiler. This is my preference when using modules on the Cray.

Conclusion

Makemake is a quick and easy tool for creating a first cut at a Makefile. It picks up many of the include and use dependencies needed to keep your Makefile honest. However, if I were to use it extensively, I would doubtless modify it a bit. I would add a search for C-style includes to .F files and recognition of the IBM compilers.

Next time I'll present a brief introduction to the power tools of Makefile creation - gnu automake and autoconf.

Quick-Tip Q & A


A:[[ I thought I'd use the Fortran 90 compiler to compile some Fortran 90 
  [[ code. Silly me. This is on the IBM SP, and it complains:
  [[
  [[ ICEHAWK1$ xlf90 prog.f90
  [[   xlf90: 1501-218 file prog.f90 contains an incorrect file suffix
  [[   ld: 0711-715 ERROR: File prog.f90 cannot be processed.
  [[     The file must be an object file, an import file, or an archive.
  [[ 
  [[ So, what do I do now?


  # 
  # Thanks to Ed Anderson:
  # 
  
This is an easy one:

  xlf -qsuffix=f=f90 hello.f90


You may also have to tell make to accept the f90 suffix:


files = hellof90.o

.SUFFIXES: .f90

a.out: $(files)
        xlf -o $@ $(files)

.f90.o:
        xlf -qsuffix=f=f90 -c $<




Q: The "goto" in this fortran loop, with the label applied to the enddo 
   statement, acts like "continue" in a C "for" loop.  Everything
   between the "goto" and the end of the loop is skipped for the current
   iteration.

       do n=1,m
         :
         if (i .eq. j) goto 100
         :
100    enddo

   Isn't there a cleaner way to do this?   

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