Fortran Source, Summer 2000

Volume 16, Issue 2

LF95 v5.6 Released!
Maintaining Fortran Programs - 1
Fortran and the Space Program
Using LF95 Linux Express with Linux Clusters
Technical Support Policy

CEO's Letter
News Briefs
  Buy IMSL, Update Your LF90 or LF95 - Free!
  Lahey and Canaima Partnership
  Winteracter Enhancements
  GINO for Linux
Lahey Product Information

LF95 v5.6 Released!

Lahey Computer Systems is pleased to announce the release of Lahey/Fujitsu Fortran 95 v5.6 for the Windows operating system. Based on Polyhedron Software’s test suite, version 5.6 offers the best diagnostics of any Fortran 95 language system, improved Fortran 90 performance, and dramatically faster file I/O.

“The new version is the *first* compiler to score 100% on our [Polyhedron’s] diagnostic tests – including all of the runtime undefined variable tests, assumed-size array bound violations, non-conforming array assignment and dangling pointer errors. It also shows some significant performance improvements on our Fortran 90 benchmarks.” — John Appleyard, Polyhedron Software

New features in 5.6 include:

  • Diagnostic capabilities:

  • LF95 now passes 100% of Polyhedron’s diagnostic tests. New diagnostics include the following:
    – Enhanced runtime and compile--time diagnostics for -CHK option.
    – Global compile diagnostics with new -CHKGLOBAL option.

  • File I/O speed improvements

  • Two to four times faster than competing compilers on unformatted sequential and direct files. Faster on formatted sequential too.

  • Execution speed improvements:

  • Loop optimization is improved when -O1 is specified; FORALL and DOT_PRODUCT statement processing is faster; and evaluation of the exponentiation operator (**) is faster.

  • New OPEN statement specifier:

  • Convert big endian and IBM/370 file formats and the corresponding specifier in OPEN and INQUIRE statements.

  • Windows 2000 compatibility.
  • Fortran 2000 Standard(proposed) feature:

  • ALLOCATABLE attributes on array components of structures, dummy arrays, and function results.

  • Additional -CHK arguments to control compiler diagnostics:

  • Includes checking for uninitialized variables!

  • -MLDEFAULT option:

  • Ability to set default target language name-decoration/calling convention for all program units.

  • Ability to exclude non-standard Lahey intrinsic procedures with new -NLI option:

  • Helps avoid name conflicts in porting projects.

  • Character variable length:

  • Limit is increased from 65,000 to 2,147,483,647 characters.

  • VOLATILE statement and attribute porting extensions.
  • Variable format expression porting extension (VAX).
  • f90SQL-Lite:

  • A library of Fortran-callable procedures that allows you to read data from and write data to databases and spreadsheets.

  • Additional Lahey ED Developer toolbar buttons:

  • “Optimized LF95 build,” “Debug LF95 Build,” and “Technical Support Questionnaire.”

  • File splitter:

  • LFsplit divides each program unit into separate source files. LFsplit fixes a problem that prevented extremely large source files from compiling successfully. In most cases, splitting a large source file into smaller files improves compile speed.

  • More mixed-language programming examples.
  • Technical Support Questionnaire program:

  • Automatically guides you through the gathering of appropriate information for formulating technical support inquiries.

  • Automatic online updates:

  • From Lahey’s web site (during and after installation).

  • Revised User’s Guide.
  • Updated Winteracter Starter Kit (WiSK).
  • Additional features in SSL2 (Scientific Subroutine Library).
  • Improvements to Sampler Tool.
  • Improvements to Coverage Tool.

For more information about LF95 v5.6, please visit\lf95.htm or contact our sales department at

Maintaining Fortran Programs - 1
by Thomas M. Lahey

This is the first in a series of articles on steps you can take to maintain (I resist using the word port) a Fortran program. A side effect: Implementing these changes will serve to familiarize you with some of the more fundamental features of Modern Fortran. As additional articles are written, they will be made available on the Lahey web site,

There are few Fortran programmers who are not involved in maintaining programs originally written a decade or more ago. This assertion is based on responses made to the Lahey Workshop Questionnaire. If the workshop participants are representative, then, for all practical purposes every Fortran programmer does maintenance. More than forty percent of the average workshop participant’s time is spent maintaining programs, typically on more than one platform.

Some of the programs were created using FORTRAN I, but my impression is that most began life as FORTRAN IV,the predecessor to FORTRAN 77.

In the past, program maintenance consisted of debugging and enhancing .For decades, our programs ran on a single mainframe and distribution was comparatively limited. Nowadays, thanks to the ubiquitous PC with the Linux, Unix, or Windows operating system plus distribution via the World Wide Web, maintenance places many more demands on the programmer. In addition, the evolution of operating systems, programming languages, chips, and graphics has greatly impacted what needs to be done.

Consider the evolution of the operating system. As recently as the early 1990s,Fortran programmers concentrated on FORMAT statements. I/O may have required ten to fifteen percent of a project. Today, thanks to GUIs and graphics, we spend at least one-third of the project coding I/O – this aspect of the project has more than doubled!

Next, consider the evolution of the chip. We’ve gone from the 8080 (64K,no floating point)to the 8086 (640K, who would ever need more than that? )plus the 8087 to the Pentium (how much memory do you want?) with floating point included. The chip evolution has had greater impact than the OS on how we should be programming. In comparing the two, chip and OS ,I believe the chip to have been more positive. For instance, what we had to do in the past to make a program fit is no longer a consideration. That is, EQUIVALENCE and overlays need no longer be considerations in making a program “fit ” in available memory.

But it is the evolution of the Fortran language and how it impacts program maintenance that is the focus of this series of articles.

Assumption: You use an editor that can do global replacements, i.e., the editor can search a directory and any subdirectories to find strings and replace them with other strings.

Assumption: You have a Modern Fortran (90 or 95)language system.

Suggestion: Save two copies of the program source file(s) with one or more data sets. These steps help ensure that you do not introduce bugs into the program. After you have implemented one of the ideas below ,compile and execute the program. If the program answers are correct, update one of the copies of your saved source. This step reduces the time it will take you to correct any bugs you have introduced. If you wait until the end to recompile, you will have to scratch your head over where you introduced the bug(s).

Suggestion: As a starting point,compile your program with the –F90 switch for LF90 or –F95 for LF95.(If you have access to both Lahey language systems consider doing both. LF90 and LF95 source checkers are available at the Lahey website.) Any diagnostics will give you an idea how far the program has strayed from the standard. Consider eliminating as many of these diagnostics as possible, some of which will be redundant with the suggestions below.

The projects identified below are listed in order of increasing complexity. Note, however, that these projects are merely suggestions. You know your program best and are responsible for what you decide to do to it.

The following transformations are all global edits, i.e., possibly across more than one source file, possibly in more than one directory.

  • Eliminate nonstandard extensions that don’t accomplish anything, e.g., INTEGER*4, REAL*4, and LOGICAL*4 should become INTEGER, REAL, and LOGICAL. For REAL, consider doing some numerical analysis and using the SELECTED_REAL_KIND intrinsic function. This last step is in preparation for the 64-bit chips that are coming.
  • Convert the .OP. relational operators to the corresponding symbols, e.g. , .GT. becomes > and .GE. becomes >=. Your program will be smaller.
  • Replace REAL**8 and DOUBLE PRECISION with REAL( KIND( 0D0 ) ) – standard conforming.
    Even better: Do some numerical analysis and use the SELECTED_REAL_KIND intrinsic function instead of the KIND function.
  • Replace COMPLEX**16 and DOUBLE COMPLEX with COMPLEX( KIND ( 0D0 ))– standard conforming. Again, consider using the SELECTED_REAL_KIND intrinsic function.
  • Replace INTEGER**1 and INTEGER*2 with INTEGER – program could execute faster. This change requires some caution; EQUIVALENCE considerations could enter into it.
  • Replace LOGICAL**1 and LOGICAL*2 with LOGICAL – program could execute faster. This change requires some caution; EQUIVALENCE considerations could enter into it.
  • Names. In programs written before Fortran 90, standard conforming names were at most six alphanumeric characters, all letters capital. Consider “modernizing ” the names, i.e., use up to 32 characters that can be caps, lowers, underline, and digits - more readable program.

That's it for the first set of changes. The next article will show how to convert COMMON to a module with some of the pitfalls.

Please e-mail any response to this article at

Fortran and the Space Program
(Back to Contents)

These days, fewer and fewer engineers remember, firsthand, the glory days of the space program, culminating in the historic Apollo moon landing. Fewer still recall just how intimate was the connection between three converging new technologies: Space science, computer science, and Fortran. In the earliest days of the space program, computers were nonexistent, and Fortran was barely so. When I joined NASA in 1959, to say that computing facilities were primitive would be an understatement. Like every new NASA engineer, I was given a standard, government issue, 18" slide rule. The standard "computer" was a 50-pound, mechanical marvel, the Friden calculator. Spreadsheets were something you did by hand, using the Friden; trig functions were something you got from a book of tables; and graphs required drafting instruments, french curves, and a sharp pencil. You could tell a lot about an engineer by the quality of the graphs he drew.

Laugh if you like, but it was mostly slide rules, spreadsheets and graphs, not computers, that launched Alan Shephard and John Glenn into space. NASA’s Langley Research center had one (1) computer, a 32k IBM 702. My first dynamic simulation, for a solid-state rocket booster, was written in assembly language, mainly because that’s all we had. As for things like lunar and interplanetary simulations, there were maybe 10 in the entire country. When you consider the challenge of writing a precision simulation in assembly language using, say, 5th-order Adams-Moulton integration, you can appreciate why there weren’t many of them.

By 1969, the year of the Moon landing, aerospace companies all over the country had IBM 7094’s, Univac 1108’s, and CDC 6600’s coming out their ears, all busily grinding out solutions of complex trajectory problems, and virtually all written in Fortran. Fueled by the Apollo effort, we had computing power to spare, and dynamic simulations were a dime a dozen. Each of us had an N-body simulation to help solve Apollo trajectories, and many were being used to plan the next step: Mars. Thousands of engineers, worldwide, pored over fan-fold printouts and X-Y plots.

As computers evolved, mathematical methods evolved with them. At the beginning of the space program, we used what existed, which were methods developed by astronomers to compute the orbits of comets. They were methods intended to be used by hand, and they often involved decisions concerning precision, signs of results, etc., that required human intelligence to make. They also tended to make heavy use of spherical trig. The methods did not translate well into computer programs. So we developed new methods that depended on vector math, and algebraic rather than trig-based solutions; things the computer was good at. The patched-conic method, the unified two-body theory, the f-g series solutions, Deyst’s method, Lambert’s theorem methods, all were brand-new methods, better suited to computer solutions than manual ones. Practical application of the now-famous Kalman filter came straight out of the Apollo program inspired by the need for efficient midcourse guidance. I think it’s no exaggeration to say that it was computer technology, not money or space science, that helped us land on the Moon.

And Fortran was right in the middle of it. What made Fortran so important? It was designed, from the get-go, to help programmers solve math problems. If there was something we had in abundance, it was math problems, and Fortran was the perfect tool to help us solve them quickly AND efficiently.

Two features of Fortran were of special significance. One was the subroutine with calling lists. Though the notions of modularity and reusable software were still thirty years away, we knew a good thing when we saw it. We were all building subroutine libraries, and using them to build bigger ones. My very first Fortran "program" was the ubiquitous vector add routine:

      DIMENSION A(1), B(1), C(1)
      DO 10, I=1, N
10      C(I) = A(I) + B(I)

I still use that same routine to this very day.

The second "feature" was not really a feature, but an accidental result of the primitive state of compiler technology. The original Fortran passed all parameters by reference, not value. To identify a passed parameter as an array, you had to mention it in a dimension statement. But we quickly learned that the size didn't matter; the compiler didn’t do range checking. It only needed to know that the variable was an array. This meant that we could use tricky constructs like the dimension statement above to operate on vectors of any size. Doing the same with matrices was a little trickier, because we had to do our own 2-d to 1-d indexing conversion, but we did it.

By the time Fortran IV came along, this practice had become so popular that it couldn’t have been removed from the language, even if they wanted to. So they formalized the syntax into something called "variable dimensions," AKA conformant arrays. Now it was possible to write general functions operating on two-dimensional arrays:

      DIMENSION A(L, M), B(M, N), C(L, N)
      DO 20 I = 1, L
        DO 20 J = 1, N
          SUM = 0.0
        DO 10 K = 1, M
10        SUM = SUM + A(I, K) * B(K, J)
20        C(I, J) = SUM

Today, some people consider Fortran passé. More modern languages like Pascal and C are the rage and object-based languages like C++ even more so. To this day, not one of them support conformant arrays. Why is this? Frankly, I consider this a national disgrace. Surely, if Fortran could support the concept in 1967, some compiler wizard could figure out how to do it in C++, in the year 2000. I can only conclude that the people who design modern languages don't really care much about (or even understand) the needs of those of us who still do numerical computing. That's why Fortran remains the premiere language for number crunching.

I first encountered Lahey Fortran in its 16-bit guise, back around 1986. I had been trying to sell my company on the idea of using PC's for more serious computations, but they tended to still think of them as toys. The company had a massive, highly computation-intensive covariance analysis program, that had been written in Fortran and ran on a DEC VAX-11/780. To back up my claim that the PC was for serious number-crunching, I was challenged to convert the analysis program to run on a true PC/AT (1 Mb RAM, all of 6MHz clock. The only concession I got was a hardware math chip). After some shopping around, I chose Lahey Fortran mainly for its ability to compile quickly and generate tight code.

The program took some tinkering to get it to compile under Lahey. The first time I compiled it, I got hundreds of error messages. After tracking them down, it turned out that every single one was a legitimate error. Lahey had flagged programming errors, mostly type mismatches like implicit and inadvertent double-to-real conversions, that the DEC compiler had blithely accepted. In several cases, it flagged variables that were set but never used, and, worse yet, variables that were used but never set.

Once the bugs had all been corrected, the program compiled without a hitch. Interestingly enough, not only was it small enough to run in the AT's 640k RAM space (the DEC version had been 1.5Mb), but it also ran 2-3 times FASTER than on the VAX.

In bringing this system up and working out the bugs, I had occasion to call Lahey several times. I always found them to be extremely responsive and helpful, and the compiler itself was absolutely bulletproof. In the world of PC software in 1986 (or 2000, for that matter), I found this a refreshing state of affairs.

About a year later, Tyler Sperry, editor of Computer Language, asked me Magazine, to review the current crop of 32-bit Fortran compilers. I think I reviewed seven compilers, all told, and gave each an ordinal rating. Some of the other compilers clearly were mere ports from the VAX world, and it showed. The worst of them crashed and burned on some of my benchmarks. Others were so difficult to use I simply set them aside.

Lahey came out the clear victor, not just because of its speed and reliability, but also because it was nicely integrated with a development environment. Not surprisingly, from my experience both before and since, the compiler itself was rock solid. I've come to expect nothing less from Lahey.

This review became something of a cult classic because I pulled no punches; I told things as they were. Needless to say, Tyler took a lot of flak from the vendors I'd rated low. One told him that their sales had been cut in half. But Tyler stuck to his editorial guns and refused to bend to pressures to retract any of my comments. Interestingly enough, other software vendors - the ones who had good products, and knew it - found the approach a refreshing breath of fresh air. More than one told Tyler they wanted the magazine to review their product also, but only if I agreed to do the review. I found that attitude a most uplifting one.

Before closing, I should mention one other outstanding feature of Fortran: It changes. Other languages, like Algol and PL/1, have come and gone. Fortran is much more dynamic than C or Pascal; it continues to evolve, and change to meet new concepts like objects. That is a great part of its power. But most of all, Fortran has never forgotten its roots: It still remains a language for crunching numbers. And Windows programming to the contrary, sometimes it’s number crunching that we need.

Jack W. Crenshaw holds a Ph.D. in Physics from Auburn University. He has spent over 40 years in the aerospace program, beginning with seminal work on Project Apollo. He is currently a senior principal design engineer for ATK, Inc., a defense contractor. He does math-intensive software and system design. He is a contributing editor for Embedded Systems Programming Magazine, and his popular column, "Programmer's Toolbox," has enjoyed an 8-year run with no signs of letup. He is a sometimes president of Crenshaw Technologies, a software/systems consulting firm, and his book, "Software Toolbox for Embedded Systems," is due for release in August. In his "spare" time, Crenshaw raises ducks and chickens, and helps to rehabilitate wild orphan baby birds and animals of all kinds.

Winteracter Enhancements
(Back to Contents)

Winteracter v2.20 is now available! (Actually, it's been available since November 26, 1999.) If you haven’t upgraded to the latest version of Winteracter yet, you are missing out. Upgrades from earlier releases include a new manual with loads of new features:

Graphoria emulation
The emulation of Lahey's Graphoria library (of F77L and EM/32 fame) has been extended.

HelpEd is the newest addition to an already extensive set of visual development tools. Need to create Windows help files for your program? Use HelpEd to create and edit a topic list and an optional contents file. You can prepare help topic text using the built-in RTF editor (see Text Editor below) and build the finished help file from within HelpEd.

Text Editor
The built-in text editor now offers RTF (Rich Text Format) support for font style and formatting control. The editor includes a new print option.

Graphics Primitives
Full 24-bit color is now available. You can directly specify a 24-bit RGB value allowing up to 16 million simultaneous colors in Windows GDI, PostScript, PCX, BMP, CGM, Draw, PCL, and ESC/P2 output. There's also a new graduated color fill primitive, IgrPolygonGrad, that takes advantage of 24-bit color control. Line width control is available in screen output in addition to hardcopy.

Bitmap Files
The routines that save PCX and BMP files from raw data and from a virtual raster have both been extended to support the 24-bit color file formats. You can display PCX files of any color depth (previously only 256-color files could be viewed). On 16-, 24-, and 32-bit video drivers, PCX screen image files are now saved in 24-bit color mode.

Graphics Import
IGrReplayArea allows you to zoom in on a specified area of an image when importing HP-GL, HP-GL/2, CGM and PIC files. 24-bit color information is reproduced when importing HP-GL/2, CGM, WMF and HP-GL files. IGrLoadImage now automatically recognizes the input file type (PCX or BMP).

Presentation Graphics
Marker frequency can now be specified on line plots. Text-labeling on scale points is available on 3D surface and scatter plots. User scaling is available on histogram X axes and bar-chart Y axes. 3D surface plots allow for transparent tiles. The number of decimal points in scale values can be enforced. And plotting speed in 2D fill-based contour plots is substantially improved when a granularity value greater than one is requested. Whew!

You can now open child windows in a hidden state thereby delaying their appearance until converted to a text editor or bitmap viewer. You can now specify the border style of each field in a status bar.

Memory Bitmaps
The bitmap put and get routines now operate on the current "drawable" rather than simply the current window. This allows bitmaps to be displayed in dialog fields and bitmap-to-bitmap copying.

You can specify the color of specific columns, rows, or cells grid controls. The cut and copy facility in grid controls is extended to support multiple rows and columns. The currently selected tab in a tab control can now be interrogated directly. You can selectively disable individual tabs in a tab control. Fields can be selectively hidden at run-time. A common dialog is included for text file printing.

PCX files of any color depth can be viewed, printed, and converted. The picture field no longer requires a (potentially slow) redraw when exposed. Printing options are extended with greater control over PostScript, HP-GL, and HP-GL/2 output.

So, what is Winteracter anyway? Winteracter is a 32-bit Windows user-interface and graphics package for Fortran 9x developers. It's available on Windows 9x, NT, and 2000 for all the major Fortran 9x compilers. Winteracter is developed by Interactive Software Services Ltd. and available from Lahey. Click on Products at to check it out. Put a Windows front on that old Fortran code.

GINO for Linux
(Back to Contents)

GINO is the name of a collection of portable graphics and GUI development tools available on a wide range of platforms including Win95/Win98/Win2000/NT, Linux, UNIX and OpenVMS. GINO products offer everything from simple line-drawings to complex fully-interactive three-dimensional applications with a fully-featured GUI front-end.

GINO-F Bundle for Linux

Following on from the release of Lahey LF95 Linux Express, GINO-F Bundle has now been ported to LF95 Linux Express. The GINO-F Bundle under Linux comprises GINO F v4.3, GINOGRAF v4.2, GINOSURF v3.2 and GINOMENU v3.1 (compatible with GINOMENU under UNIX). GINOMENU v3.1 provides a unique programmable GUI with emulation styles of Windows 3.1, Windows 95 and MOTIF available. The Bundle is supplied with drivers for X-Windows, Postscript and JPEG and other drivers such as HPGL2, HP-Paintjet, Epson and Canon are also available. The GINO-F Bundle for Linux is routine-name compatible with the GINO-F Bundle for Windows providing seamless portability of applications between the two platforms.

Price: $2100 ($1470 for educational license.)

GINOMENU v4.0 for Windows

Tabbed Dialog Box
A new tabbed dialog box (or property sheet) can now be displayed, and automatic scroll bars are provided if too many tabs are defined for the visible area.

Tree Views
Create hierarchical selection structures with the new Tree View widget..

Dockable Toolbars
Toolbars can float or be docked.

Bubble help
Bubble help can now be attached to most widget types and when the mouse pauses over the widget, the text can be displayed either as a standard bubble or displayed in the status bar.

Mouse-sensitive Icons
Icons can now be set to mouse-sensitive and therefore can have three associated images; greyed-out, unselected and selected.

Panel Backgrounds
An enhancement to the panel widget allows users to set a background image to the widget using a resource bitmap.

Security Text
A new security text type has been added which echoes 'xxxx' when text is entered.

Price: $2100 ($1470 for educational license.)

Special Offer
Attendees of the F95/GINO Workshop qualify for significant discounts on GINO products. Read the notice in this newsletter for details.

Using LF95 Linux Express with Linux Clusters
(Back to Contents)

Linux versus Windows
What is the fastest way to start an argument? Religion? Politics? No, if you really want to spice things up just ask, "What is better, Windows or Linux?" Then step back -- you are sure to get a spirited answer. Each operating system has features that attract loyal, enthusiastic followers. Windows users will point to ease of use and main stream acceptance as the main attractions of Windows. Linux users will counter that the open architecture and performance of Linux make it the operating system of choice.

We hear anecdotal reports that Fortran compilers perform better under Linux than Windows on single processor systems. The reasons cited vary such as the way Linux handles disk I/O or the memory limitations of Windows. We decided to get an expert opinion on the subject. Dr. John Appleyard of Polyhedron performs benchmarks on all the major Fortran compilers for both Windows and Linux. The plusFORT analysis package produced by Polyhedron is the industry standard for analysis tools. According to Dr. Appleyard,

"My own view is that for most Fortran related tasks, the two O/Ss give similar performance. Our benchmarks, which emphasize CPU and memory speed, appear to confirm that. Differences may be more apparent in areas such as web-hosting and transaction processing, which require more from the operating system."

Linux Express
The debate will no doubt continue. On one point, though, there is no debate. The new LF95 Express for Linux has been enthusiastically accepted by the Linux community. For the first time, Linux power users have a high performance Fortran compiler for a price of only $249. We have received gratifying testimonials from all over the globe. A typical response comes from the University of Helsinki, an institute that ought to know a little bit about Linux.

"That was quick! We did receive LF95 next day! We have now installed the first two of them and our first impression is very positive. Compared to Gnu g77 (which we used before) LF95 is several times more effective and the debugging information is excellent. Installation was also very straightforward."

Jukka Piironen, Department of Astronomy, University of Helsinki

MPICH for Linux
There is one feature of Linux that has a clear edge over Windows. MPICH is an implementation of MPI (message passing interface) that allows Linux LF95
Express users to create parallel applications that can run on more that one processor. Knowledgeable users have successfully installed Express on their Linux cluster.

"Linux Express was easily installed on our K7 Beowulf. With the complete [online] manuals provided by Lahey, the learning curve was extremely short. Performance using Linux Express versus g77 has significantly increased."

Richard C. Martineau, Staff Scientist, Idaho National Engineering & Environmental Laboratory

We have reports of people using LF95 with MPICH on 64-node systems, with faster performance than other Fortran compilers. The word is spreading fast. We have received requests to document the process to use LF95 Express with MPICH. By popular demand here is the process:

Code and documentation for MPICH can be downloaded from

Once the package has been downloaded and unzipped, it can easily be configured for use with LF95 by using the configure script in the ~/mpich directory. Documentation for configure can be viewed by issuing the command: ./configure -help | more. Configuring MPICH for LF95 is straightforward, from the ~/mpich directory, issue the command: ./configure -fc=lf95 -f90=lf95 . This command will set lf95 as both the Fortran 77 compiler and the Fortran 90 compiler. It will find and test lf95 and generate a makefile to direct the actual building of MPICH. Before running make, the output of configure should be inspected for errors, and any problems found should be resolved. When we configured MPICH on our Redhat 6.0 system, no errors occurred. If errors are encountered, they most likely will involve older versions of packages required by MPICH. Downloading the latest stable version of the package in question will likely fix the problem.

Once configuration is complete, you can build MPICH by typing make. If the configure was successful, it is most likely the make will proceed without a hitch. Once the make is complete, you may have to modify a couple of files. The first is machines.LINUX in the ~/mpich/util/machines directory. This file should contain the domain name of every machine that will run your program, with one name per line. To start with, this file will only contain the name of the machine building MPICH, repeated several times. MPICH will run multiple jobs on the same machine if it is listed more than once. The second file that needs to be created or modified is the hosts.equiv file in the /etc directory of every machine that will run MPICH. This file should contain the domain name of the machine that contains MPICH. Each node must have the LD_LIBRARY_PATH set with the path to the LF95 runtime libraries resident on the machine that has MPICH installed.

A set of test routines comes with MPICH that can be used to validate the installation. Some simple tests are in the ~/mpich/examples/basic directory. You need to first build the fortran examples with the make utility. Do this with the commands make fpi and make fibon . You can run the examples using mpirun. For example, mpirun -np 4 fpi will run the fpi program on four processors. A more extensive test suite is in the ~/mpich/examples/test directory. These need to be configured with the command ./configure -cc=mpicc -fc=mpif77. You can then run the test suite by issuing the command make testing. Note that the test routines are still under development, and some difficulties might occur. If problems arise, first make sure you have the most up-to-date version, then contact the MPICH developers at for assistance.

Although you can use MPICH on systems with a variety of characteristics, performance is best when all the machines have identical hardware and software configurations, as in a Beowolf cluster. This greatly simplifies the problem of load balancing – deciding which machine gets the next piece of the job. When different hardware and software are used, the slowest machine will dictate performance.

MPICH provides a significant breakthrough in the availability and cost of high performance computing. LF95 and MPICH, when used with a larger cluster can provide supercomputing capabilities at a fraction of the cost of today’s supercomputers.

Technical Support Policy
(Back to Contents)

Technical Support
If you haven't already noticed we have made a few changes to Technical Support in the last few months. These changes have been implemented in an attempt to improve the quality of the Technical Support we provide to our customers.

We'll continue to offer FREE e-mail, fax, and postal mail support on current product releases. Free support will continue to be available for previous versions of a product for 60 days after the release of a new version.

Technical Support Policy
To expedite support services, we prefer to process queries via e-mail. E-mail communications receive higher priority service because of the speed that it allows us to communicate and the level of detail that can be provided quickly. We realize that when you have a problem you want help as fast as possible. The best way to ensure optimum response is to provide the following information with your problem.

  • Registered user name
  • Registered serial number
  • Product title and version (for example LF95 v5.5)
  • Patch level (for example h patch)
  • Operating system (for example Windows 98 or Redhat Linux v6.0)
  • A short source code example
  • This will allow us to reproduce the problem. Please make sure the source code is as short as possible to allow us to analyze your issue quickly. Attach the source code file to your e-mail to
  • Third-party products used
  • If you are using an add-on library (such as Winteracter) or productivity tool (such as Visual Analyzer), provide the name and version of this product. If your application is mixed-language (such as Fortran and Visual Basic), provide the name and version of the non-Fortran language system.
  • System environment settings

To save your environment variables in a text file, go to a command prompt and redirect the output of the SET command to a file:


Attach the SETCMD.OUT file to your e-mail to

  • Step-by-step problem description
    1. Tell us the sequence of commands or buttons used that lead up to the problem occurring. Remember, if we can't reproduce it, we can't fix it for you.
    2. Compiler, linker, or Make/Automake messages.
    3. While simply typing the complete error message is always an option, you can save extensive messages to a text file to send to us, if that is easier. To save the messages as a text file, from the command line redirect the command output as in the following example:

      your_command_line > CMD.OUT

      Attach the CMD.OUT file to your e-mail to If you are using the ED editor, run your compile command and attach the ERRS.* file of the working directory to your e-mail to

    4. Exact text of error message or Window message box.

Support is provided free to solve problems with our products, and to answer questions on how to use Lahey products. Support personnel are not available to teach programming, debug programs, or answer questions about the use of non-Lahey products or tools (such as MS Windows, MS Visual Basic, etc.). These services are provided on a paid consulting basis.

In our effort to provide better technical support, we will continue to streamline our procedures to meet the changing needs of our customers. Our goal is to automate the tech support process as much as possible in order to provide the fastest, most complete response possible to as many customers as possible. We will also be extensively modifying the FAQ section of our web site. By expanding and organizing this resource, many problems may be immediately resolved.

Currently, e-mail requests for support allow us to organize an efficient tech support department and allow for quick turnaround time if the pertinent information is provided. Furthermore, e-mail is the most cost affective way for our customers to communicate with us. Our porting services and consulting contracts are always available to help you to solve difficult technical challenges or to get your Fortran projects finished.

Fortran 95 and GINO Workshops
During the week of April 30 - May 4, 2001, Lahey Computer Systems, Inc. and Bradly Associates, Ltd. are conducting Fortran 95 and GINO Workshops. The workshops will be held at Lake Tahoe in Incline Village, Nevada, USA.

Fortran 95 Workshop, April 30 - May 2, 2001
Basic GINOMENU Workshop, May 3, 2001
GINO/OpenGL Workshop, May 3, 2001
GINO 5.0 Workshop, May 4, 2001
GINOMENU Studio Workshop, May 4, 2001

Workshop Tuition and Fees

To register or for more information contact Gloria Whitlock,, 1-800-548-4778, or 1-775-831-2500 x459.

Fortran 95 Workshop
The Fortran 95 Workshop is a six-session, hands-on, Fortran 95 workshop led by Thomas M. Lahey, CEO, Lahey Computer Systems, Inc.

Workshop Goals

  • To begin to port one of your own FORTRAN 77 programs to a Fortran 90/95 language system.
  • To learn how to incorporate the new Fortran 90/95 features into your Fortran programs.
Please note: This is a workshop, not a class. A valuable workshop component is the interaction with the other participants. Attendees are encouraged to become participants!

The workshop is limited to twelve experienced Fortran programmers.


  1. Bring a FORTRAN 77 production program of at most 50,000 lines.
  2. You should arrive having reviewed the proprietary papers.
  3. While at the workshop, participants use Pentium-class computers provided by Lahey. The Lahey/Fujitsu Fortran 95 language system will be installed on the computers. NOTE: If you prefer to use a different language system, you may bring your own notebook computer and Fortran 90 or 95 language system.

Three weeks before the workshop begins, paid participants will receive a notebook containing instructional documents for each session: proprietary papers prepared especially for the workshop and copies of published papers. At the workshop you will also receive a copy of the book Upgrading to Fortran 90, your personal copy of Essential Lahey Fortran 90, and a disk containing copies of the Fortran code discussed in the workshop.

Fortran 95 Workshop Agenda

Monday, April 30, 2001
8:00 - 9:00 a.m. - Registration and continental breakfast hosted by Lahey

9:00 a.m. - 12:00 noon - Session I
Programming style. Participants decide upon a style and set of Fortran features considering efficiency, obsolescence, and replacement code. Form 2 to 3 person teams. Port FORTRAN 77 code using Tom Lahey's recipe. Assignment: Chapters 6 and 9; have CONVERT process FORTRAN 77 code; review automatically processed code.

12:00 noon - 1:30 p.m. - Lunch break

1:30 - 5:00 p.m. - Session II
Fortran 90 paradigm. Emphasis on modules and KIND; discuss object-oriented programming and the Fortran 90 object-oriented features; have FORTRAN 77 code up and running under a Fortran 90 language system. Assignment: Chapters 3, 5, and 6; continue porting to Fortran 90.

Tuesday, May 1, 2001
8:00 - 8:30 a.m. - Continental breakfast hosted by Lahey

8:30 a.m. - 12:00 noon - Session III
MODULEs, derived types, derived-type constants, overloaded operators, module procedures. Assignment: Chapter 2.

12:00 noon - 1:30 p.m. - Lunch break

1:30 - 5:00 p.m. - Session IV
Array processing: expressions, constructors, and sections; formally define terms. Assignment: Chapters 4, 7, 8, and 10; review your program to define a derived type and operations on it; prepare for a discussion.

Wednesday, May 2, 2001
8:00 - 8:30 a.m. - Continental breakfast hosted by Lahey

8:30 a.m. - 12:00 noon - Session V
75 intrinsic procedures; concentrate on the array intrinsic functions. Assignment: Chapters 10 and 11; examine DO loops, determine which to convert to array expressions; convert COMMONs to a MODULE.

12:00 noon - 1:30 p.m. - Lunch break

1:30 - 5:00 p.m. - Session VI
Remaining features; discussion and critique. Assignment: CONTINUE TO GO TO and DO Fortran!

Basic GINOMENU Workshop
GINOMENU is a programmable Fortran GUI toolkit for creating portable applications under Windows 95/NT. All the standard building-blocks of Windows are available with the option of adding powerful graphics routines to enable the user to provide completely professional applications.

The Basic GINOMENU workshop will take the form of a hands-on tutorial looking at gradually building up a small "Hello World" program from scratch and developing it into a fully interactive Fortran GUI application under Windows 95.

Workshop Goal
To be able to write Fortran GUI applications under Windows using GINOMENU.

The workshop is limited to twelve persons.


  1. Experience in programming Fortran 77, 90 or 95.
  2. No experience in C or Windows programming is necessary.
  3. While at the workshop, participants use Pentium-class computers provided by Lahey. The Lahey/Fujitsu Fortran 95 language system will be installed on the computers. NOTE: If you prefer to use a different language system, you may bring your own notebook computer and Fortran 90 or 95 language system.

Basic GINOMENU Workshop Agenda

Thursday, May 3, 2001
8:00 - 8:30 a.m. - Registration and continental breakfast hosted by Bradly

8:30 - 10:30 a.m. - Session 1
Concepts of GUI programming
Your first GINOMENU program
Adding Menubars and Pull-down menus

10:30 - 10:45 a.m. - Coffee

10:45 a.m. - 12:00 noon - Session 2
GUI grid and coordinate system
Adding Common Dialogs - Browse, Colour
Error and Message Handling

12:00 noon - 1:30 p.m. - Lunch break

1:30 - 3:30 p.m. - Session 3
Adding Child widgets - text entries, panels, toggles, toolbars, icons etc.
Enquiring/Setting Widget Attributes

3:30 - 3:45 p.m. - Tea break

3:45 - 5:00 p.m. - Session 4
Interaction - Callbacks and the Action loop
Change Application to MDI in one easy step

GINO/OpenGL Workshop
The GINO/OpenGL workshop will take the form of a hands-on tutorial looking at using some of the 3D OpenGL facilities provided in GINO. The new facet primitive and new high-level objects such as spheres, cones, boxes and volumes will be explored together with lighting & shading, material properties, texture mapping and animation.

Workshop Goal
To understand the concepts of programming 3D graphics applications using facets and 3D objects and to display them with OpenGL lighting and shading functionality.

The workshop is limited to twelve persons.


  1. Existing knowledge of GINO is useful but not essential.
  2. Experience in programming Fortran 77, 90 or 95.
  3. No experience in C, Windows, or OpenGL programming is necessary.
  4. You will need to bring your own notebook computer and F90/F95 language system.

GINO/OpenGL Workshop Agenda

Thursday, May 3, 2001
8:00 - 8:30 a.m. - Registration and continental breakfast hosted by Bradly

8:30 - 9:30 a.m. - Introduction to the 3D World
An introduction to the world of 3D graphics with special attention to the viewing volume together with its mapping and clipping implications. The range of hidden surface techniques will be covered concentrating on the Z-buffering method used by GINO and OpenGL.

8:30 - 9:30 a.m. - 3D Drawing
An overview of the 3D drawing facilities provided by GINO will be covered, together with an in-depth look at the new facet primitive. The new high level objects and Bezier surfaces will also be explored in order to generate your first 3D picture.

10:30 - 10:45 a.m. - Coffee

10:45 a.m. - 12:00 noon - Lighting and Shading
The key session of this course will look at the different shading modes and their interaction with the facet primitive. Key techniques for increasing performance will uncover different culling and lighting methods as well as translucence. The four different light source types will also be tested to illuminate your scene.

12:00 noon - 1:30 p.m. - Lunch break

1:30 - 2:30 p.m. - Materials
After covering the basic colour matching of facets, two methods of material definition will be described. These include the material table and direct assignment bringing real colour, reflectivity and transparency to your objects.

2:30 - 3:30 p.m. - Texture Mapping
An explanation of texture mapping using basic examples. Use of overlay and blending modes together with other attributes will be covered. Both automatic and manual generation of texture coordinates will also be explained.

3:30 - 3:45 p.m. - Tea break

3:45 - 5:00 p.m. - Animation Different animation techniques will be covered and tried. More on performance and use of segments to round things off.

GINO 5.0 Workshop
The GINOMENU v5.0 workshop will take the form of a hands-on tutorial looking at the new features of v5.0 such as progress bars, table-boxes and guages. Participants will then be extending an existing program and developing it into a fully featured RTF word-processor type application.

Workshop Goal
To learn and be familiar with the new features of GINOMENU v5.0

The workshop is limited to twelve persons.


  1. Existing knowledge of GINOMENU.
  2. Experience in programming Fortran 77, 90 or 95.
  3. No experience in C or Windows programming is necessary.
  4. While at the workshop, participants use Pentium-class computers provided by Lahey. The Lahey/Fujitsu Fortran 95 language system will be installed on the computers. NOTE: If you prefer to use a different language system, you may bring your own notebook computer and Fortran 90 or 95 language system.

GINO 5.0 Workshop Agenda

Thursday, May 4, 2001
8:00 - 8:30 a.m. - Registration and continental breakfast hosted by Bradly

8:30 - 9:30 a.m. - Session 1
New widgets - gauges, progress-bars, table-boxes.

10:30 - 10:45 a.m. - Coffee

10:45 a.m. - 12:00 noon - Session 2
Introduction to Font and Paragraph properties.

12:00 noon - 1:30 p.m. - Lunch break

1:30 - 3:30 p.m. - Session 3
Building a word-processor application.

3:30 - 3:45 p.m. - Tea break

3:45 - 5:00 p.m. - Session 4
RTF File Handling.
The Printing Mechanism.

GINOMENU Studio Workshop
GINOMENU Studio is an interactive GUI builder and development environment for the Fortran programmer. GUI projects can be saved as Fortran-77 or Fortran-90 code containing calls to GINOMENU.

The GINOMENU Studio workshop will take the form of a hands-on tutorial looking at interactively developing Fortran GUI front-ends and applications using drag-and-drop methodology. It will be shown how to produce menus, dialogs, widgets and icons, and interactively link up user actions with event-handling code all from the same development environment. The workshop will be led by David and Kevin Bradly, Bradly Associates Ltd.

Workshop Goal
To be able to produce GUI front-ends and applications using an interactive development environment.

The workshop is limited to twelve persons.


  1. Limited experience in programming Fortran 77, 90 or 95.
  2. No experience in C or Windows programming is necessary.
  3. You will need to bring your own notebook computer and F90/F95 language system.

GINOMENU Studio Workshop Agenda

Thursday, May 4, 2001
8:00 - 8:30 a.m. - Registration and continental breakfast hosted by Bradly

8:30 - 9:30 a.m. - Session 1
Understanding the Desktop
Differences between F77 and F90 projects
Adding Widgets for forms
Buttons, Toggles, Sliders and Text/Value entries

9:30 - 10:30 a.m. - Session 2
Saving the project to Fortran
Compiling, Linking and Running

10:30 - 10:45 a.m. - Coffee

10:45 a.m. - 12:00 noon - Session 3
Adding Combo/List boxes
Adding Status-bars, Toolbars and Radio boxes
Adding Menu-bars, Pull-downs and Icons

12:00 noon - 1:30 p.m. - Lunch break

1:30 - 2:30 p.m. - Session 4
Understanding Callbacks
The Callback Editor

2:30 - 3:30 p.m. - Session 5
Adding Fortran code
User Code Editor

3:30 - 3:45 p.m. - Tea break

3:45 - 5:00 p.m. - Session 6
Graphics Frames
Graphics Frames Callbacks

Workshop Tuition and Fees
The fees do not include food, accommodation, or travel expenses. Payment may be made by credit card or check. Reservations and fees are accepted at any time. Fees are non-refundable.

Fortran 95 Workshop
The fee for the Fortran 95 Workshop is US$1,200 per person. The fee covers all instructional documents for each session (proprietary papers prepared especially for the workshop), copies of published papers, a copy of the book Upgrading to Fortran 90, and a disk containing copies of the Fortran code discussed in the workshop.

Basic GINOMENU Workshop
The fee for the Basic GINOMENU Workshop is US$400.

GINO/OpenGL Workshop
The fee for the GINO/OpenGL Workshop is US$400.

GINO 5.0 Workshop
The fee for the GINO 5.0 Workshop is US$400.

GINOMENU Studio Workshop
The fee for the GINOMENU Studio Workshop is US$400.

Special Pricing
If you register for the Fortran 95 Workshop and two GINO Workshops, the cost is reduced by 10% for each workshop.

If you register and pay for a workshop before March 31, 2001, the cost is reduced by 10%.

Workshop participants receive a 25% discount on all Lahey Language Systems and GINO products until July 4 2001.

Travel and Accommodations
Arrangements have been made with the Tahoe Biltmore Hotel, Crystal Bay, NV, 775-831-0660. One night, single occupancy is US$49. Early registration is advised. The Tahoe Biltmore Hotel is located three miles east of Lahey's offices on the north shore of Lake Tahoe. Lahey will provide a shuttle each morning and evening from the Tahoe Biltmore to the Workshops and back.

We recommend flying into Reno-Tahoe International Airport. Take Highway 395 South from the airport and exit at Mt. Rose Highway (State Route 431). Travel approximately 35 miles until you reach Highway 28. Turn right on Highway 28 for about 2 mile. The Tahoe Biltmore is on the right at the Nevada-California state line. From the Biltmore, travel east on Highway 28 for about 3 miles (past Mt. Rose Highway 431). The Lahey offices are located between Southwood Boulevard and Village Drive on the Lake Tahoe side of Highway 28 at 865 Tahoe Boulevard (Highway 28) in the Centerpointe Building. Rental cars are available at the airport. You may also contact Budget Chauffeur at 800-426-5644 for shuttle service. They leave the Reno airport for Incline Village and the Tahoe Biltmore numerous times during the day and night. Please make arrangements in advance.

Travel to the Lake Tahoe, Incline Village area from California:
Take Interstate 80 East from Sacramento to Truckee and exit at Highway 267 to the North Shore of Lake Tahoe. When you reach Kings Beach, turn left on Highway 28. Continue approximately 4 miles until you reach Incline Village. The Lahey offices are located between Southwood Boulevard and Village Drive on the West side of Highway 28 at 865 Tahoe Boulevard (Highway 28) in the Centerpointe Building.

CEO's Letter
Dear Fortran Programmer,
As you can see from this edition of Fortran SOURCE, the Lahey/Fujitsu partnership has committed to parallel processing in a big way with our Linux Version 6.0. To be frank, there are a number of issues we're concerned about:

  1. Will Fortran users continue to demand parallel processing?
  2. Is the parallelization technology that Lahey provides the answer to the Fortran world's problems?
  3. Is Linux the answer to the Fortran community's prayers? Or will fragmentation (the proliferation of not-completely-compatible-with-each-other Linux releases) send Linux to the dust bin? Fragmentation has become a serious problem. Fragmentation is prominent among the reasons for how long it took Lahey to prepare Version 6.0. Lahey had to do significant work to make LF95 install and run on the different distributions of Linux.
I expect we will learn the answers to these questions in the coming year. Lahey does know the following:

  • Scientific problem-solvers are experimenting with and using Linux clusters.
  • The advice Lahey has received from our gurus has helped us determine the path we are pursuing.
  • Some big names are backing Linux: HP, IBM, Intel, and NEC are each expected to spend millions on a new Open Source Development Lab. The Lab's goal is to make Linux reliable enough for the corporate world.
On the negative side, we know that in the past, a number of parallel strategies have been pursued (HPF comes to mind) without becoming the panacea the Fortran programming community seeks. Regardless, you and Lahey, as we have done together in the past, will continue to evolve until we both get it right.

There's another aspect: The chips are getting faster and faster, cheaper and cheaper. Both Intel (IA-64) and AMD are working on 64-bit chips that will (eventually) execute programs faster; especially if the programs need to do extended-precision arithmetic.

Last but not least: We will conduct a Fortran 95 Workshop here in Incline Village on the shore of Lake Tahoe: April 30, May 1 & 2. Truckee Meadows Community College will provide computers (but not cameras). All you need is a reasonable size (50,000 lines at most) program coded in FORTRAN 77 that your boss would like you to begin porting.


News Briefs
Need a Linux Cluster?
Ready to try your code on a Linux cluster? PSSC Labs can provide you with a turn-key Linux Beowulf cluster that meets your specifications and budget. Low price, professional service, and over 10,000 options make PSSC Labs the place to shop. Lahey recently ordered an 800 MHz Athlon cluster from PSSC. "The machines are great and the service outstanding," said Bill Lassaline, President, Lahey Computer Systems, Inc. Visit PSSC at or give them a call at 949-380-7288.

Since 1982, Microway has earned its reputation as the "World Leader in High-Performance Numerics" in the workstation and server-user community. Currently Microway specializes in designing custom configurations of Alpha- Athlon-, and Pentium-based Linux Beowulf clusters, workstations, and fault-tolerant SCSI RAID arrays. Clusters are configured with Myrinet, Wulfkit, or ethernet. Microway will be providing Lahey Fortran for Linux on their Pentium and Athlon clusters. Visit Microway at or give them a call at 508-746-7341.

GINO v5.0 Available
GINO is a suite of portable graphics development tools aimed at scientific and engineering applications. GINO contains over 700 routines and is available for use with Fortran 9x and C language systems.

In addition to containing the more common graphing features such as line graphs, charts, contour maps and 3D surfaces, GINO includes a fully programmable GUI interface (GINOMENU), and a host of low-level drawing routines for graphics development in 2D and 3D. Version 5.0 features fully integrated OpenGL functionality including facets, lighting, shading, and texture-mapping for developing state-of-the-art 3D models. GINO runs under Windows, Linux, OpenVMS, and most UNIX systems.

The major new facility that has been added to the GINO library is the ability to create photo-realistic images using lighting and shading facilities, in conjunction with facets, ready-made objects, and surfaces. These new facilities are utilized with two new 3D device drivers, WOGL and GLX, both of which interface to the OpenGL API on PCs and UNIX workstations.

GINO v5.0 libraries are available from Lahey Computer Systems, Inc.

Wineracter v3.0 Available
Winteracter is a user-interface and graphics package for Fortran 90/95 developers. Visual development tools and a substantial subroutine library are provided. Winteracter is available for Win32 and Unix/Linux operating systems on Intel, Alpha, and SPARC hardware and is compatible across platforms. A broad range of Fortran 9x compilers is supported.

Following are just a few of the many enhancements to Winteracter v3.0:

The main functionality of the Unix/Linux version of Winteracter is now synchronized with the Win32 implementation.

The Winteracter User Guide has undergone substantial revision. Greater emphasis has been placed on tutorial and task-oriented content. New material has been written on subjects such as dialogs and menus. Grouping of common topics has also been improved.

Windows and Dialogs
You can now combine windows and dialogs, allowing a menu and toolbars to be attached to a dialog. You also have run-time control over dialog size.

Grid Controls
An arbitrary rectangle of cells can now be selected for cut/copy operations in grid controls. The memory requirements of numeric cells have been substantially reduced. For integer and real grid cells, memory usage has been reduced by a factor of 12. Grid rows can be added or removed under program control.

PNG Files
Substantial support has been added for PNG (Portable Network Graphics) files. This bit image file format is an open replacement for the GIF format. PNG provides good compression ratios, 24-bit color support and no patent/licensing issues. Most usefully, PNG files can be viewed in web browsers such as IE5 and Netscape 4 or greater.

Presentation Graphics
Among other PG enhancements, plotting using polar coordinates is now supported.

Help Files
Help2HTM, a new visual tool that can convert Windows Help projects created by HelpEd (or Help files from some other sources) to HTML format has been added. Also, files in Microsoft's Help/HTML hybrid known as Compiled HTML (CHTML) can now be invoked via WhelpFile under Windows.

Visual Tools
A number of enhancements to DialogED and WiDE were made. A "New Graph Wizard" was added to GraphED, simplifying graph design.

From five new demos to a fast sorting routine based on the recursive quick sort algorithm, numerous improvements were made throughout the library.

Winteracter is available from Lahey Computer Systems, Inc.

By the Solutions Department.

Q: Can I create a program that runs on and takes advantage of more than one computer, each with two processors?
A: Yes. Use OpenMP together with MPI.

Q: Will my program take less time to run if I use the new parallel programming features in v6.0?
A: Here's what beta tester Lloyd Young, Los Alamos National Lab, said about automatic parallelization: "I used a couple of the directives to parallel the DO loops and now have increased the speed 40% in the code amix.for." Yet, we've also had reports that automatic parallelization caused some programs to run slower. So, the answer is, it depends on your code and how much effort you put into parallelizing it. Read "Chapter 4, Multi-Processing" in the LF95 User's Guide (online at for an explanation of the impediments to performance improvement.

Q: Why does my program run slower on some newer distributions of Linux?
A: We found that some programs run slower on newer distributions of Linux, for example, Red Hat 5.2 vs. Red Hat 6.2. The cause of this appears to be the newer version of the glibc (GNU C runtime) on the newer distribution. The slower performance manifests itself only in programs dynamically linked with the C runtime.

Workaround: Specify the -static option on your LF95 command line to statically link all the GNU C runtime (part of the Linux operating system) and Fortran runtime libraries into your executable program. This will make a much larger executable file than a dynamically linked one. Note: We don't recommend that you distribute this type of application, as it will be governed by the GNU Public License due to the copy of the GNU C runtime that it contains.

Q: I'm going to move my code from LF95 Windows v5.6 to LF95 Linux v6.0. What do I need to know?
A: There are a few things to consider. 1) If you use a Windows user-interface and graphics library or other third-party library, you'll need compatible versions of the libraries for Linux. 2) Under Linux, all multiple-character compiler and linker options are specified with two hyphens, whereas, under Windows a single hyphen is used. While most LF95 Windows options are available under Linux by adding an extra hyphen (e.g., -chk and --chk), there are some differences (e.g., -w vs. --warn), and some options specific to each platform (e.g., -dll vs. --wide). 3) Some procedures and statements are available only with LF95 Windows: DVCHK, NDRERR, NDPEXC, OVEFL, and UNDFL procedures and the DLL_EXPORT and DLL_IMPORT statements.

Q: How can I make sure the Linux executables I create run on multiple Linux distributions and are backwards compatible with older distributions, as well as compatible with Linux distributions yet to come?
A: That's a tall order in the Linux world. We can tell you what works for us: We build the LF95 Linux tools on RedHat 5.2 -- Linux kernel 2.0.36 and glibc 2.0.7. Using this approach we expect compatibility with versions newer than those given the backward compatibility built into the newer kernels and runtimes. We do not expect compatibility with older versions.

Q: Lahey keeps referring to Linux as if it were an operating system. Is that correct?
A: Not really. Linux is actually the kernel, not the operating system. A "Linux operating system" as a whole is basically the GNU system, with Linux added as the kernel. GNU stands for "GNU's Not Unix." The GNU Project ( is the system's principal developer. More at and

Help us end waste. Let us know if you change your address, receive duplicate copies of Fortran SOURCE, or would like to be removed from our mailing list.  Call us toll-free at 1-800-548-4778 or send us e-mail at  Thank you.