return to first page linux journal archive
keywordscontents

Porting Scientific and Engineering Programs to Linux

You can port nuclear engineering programs written in FORTRAN and C to Linux easily and efficiently.

by Charles T. Kelsey IV and Gary L. Masters

The relatively exorbitant cost of hardware and compilers necessary to put together a fully functional engineering workstation puts them out of reach of most students or professionals, who desire a workstation at home. Even for large companies cutting costs without loss of efficiency is desirable. With the advances in Intel processor speed and the ever growing software base available for Linux, the combination presents a good solution for the low cost workstation.

For engineers and scientists a full featured FORTRAN 77 compiler is a must. Additionally, a readily accessible library of numerical functions and subroutines is needed. Full featured FORTRAN 77 compilers regardless of platform, such as Lahey's compiler for DOS and Sun's compiler for SPARCstations, are priced at around eight-hundred American dollars. Commercial numerical libraries, such as IMSL, can cost thousands of dollars.

Compiling Scientific and Engineering Code Under Linux

Readily available under Linux are a couple of free FORTRAN 77 options. The first is f2c, a FORTRAN to C source code converter. The other is g77, a FORTRAN compiler produced by the GNU project. The limitations of f2c leave g77 as the only viable alternative for compiling large complex applications written in FORTRAN 77 under Linux. Short pieces of FORTRAN code were written as needed for particular engineering tasks and were compiled with g77 to test the compiler abilities as a tool for day to day engineering activities. It was found that g77 produced efficient binaries and behaved as a good FORTRAN compiler should.

The next step was to compile a more significant piece of engineering code that is commonly run on workstations in the ten to twenty thousand dollar range. As radiation safety professionals, a code frequently used is MCNP, that implements the ``Monte Carlo'' method to transport neutral particle radiations. (The current version of MCNP is 4A; 4B will be released soon.) MCNP represents hundreds of man years of coding and is considered the best available technology for this type of calculations. Like most science and engineering code packages with long development histories, MCNP is written predominantly in FORTRAN 77, and language conversion is not considered a reasonable development step.

One thing that makes porting this code to a new platform somewhat challenging is that it is a safety related, pedigreed code, so one cannot just start changing things. Any changes must be made using patch files with the provided implementation utility. This utility is called PRPR and is also written in FORTRAN 77. PRPR is relatively simple code. The first step in porting MCNP to Linux was to compile PRPR, without modification, using g77. This operation was successful--an encouraging but misleading fact. The rest of the package was not as cooperative.

MCNP had already been ported to numerous platforms, everything from VMS to UNICOS. The first obvious approach was to try the patch files provided for similar platforms. None were successful, but these attempts did result in numerous educational error messages.

An initial hurdle to overcome was the absence of the fsplit command in Slackware distributions. This problem was resolved by getting fsplit from a BSD distribution.

The second hurdle was the absence of some VAX FORTRAN extensions, specifically those related to signal handling, date and time calls and execution timing. Although not part of the FORTRAN 77 standard, they are included with many of the commercial FORTRAN compilers. The necessary functions of most of the VAX FORTRAN extensions are simple enough to replicate with short C routines that can be linked with the FORTRAN objects when the executable is produced. The MCNP source includes a C routine to handle execution time.

Once the VAX FORTRAN extension problems had been solved, the remaining tens of error messages were related to problems with integrating the FORTRAN and C objects. With MCNP plotting routines written in ANSI C, the integration of objects is necessary to generate a fully functional executable. The errors result from incorrect syntax of subroutine declarations, which varies from one FORTRAN and C compiler pair to another.

Once the executable binary had been produced successfully--that is, a compile completed with no errors--the provided test problems were run. Test problems are provided with safety related codes, so that the user can verify not only that they compiled a binary, but also that the binary produced reasonable answers. A comparison of the test problem output from the Linux binary to the supplied output revealed only differences attributable to differences in architecture. The machine that produced the standard was a SPARCstation 5, and the first Linux box to run the MCNP binary was a 75 MHz Pentium.

Since that first platform, MCNP Version 4A has been complied and run on 100 and 200 MHz Pentiums. While the Pentiums are not quite as fast as a SPARCstation 20/151 (150 MHz HyperSPARC), they are quite fast when their cost is considered relative to the SPARCstation. Note that the referenced HyperSPARC module alone costs over four thousand dollars.

The PRPR implemented patch files necessary to compile MCNP Version 4A under Linux are shown in Listing 1 and 2. Note that both the FORTRAN and the C patch are necessary. It should also be noted that the best MCNP graphical behavior occurs when running under the OpenLook Window manager.

Listing 1. FORTRAN Patch File

Listing 2. C Patch File

While we do not expect that all scientists and engineers use MCNP, we do hope that this documentation of the MCNP port will be helpful to those looking for an inexpensive workstation to run their code.

Library of Numerical Routines for g77 Under Linux

A free collection of routines written in FORTRAN 77 is SLATEC. This collection includes over 1400 mathematical and statistical subroutines that are very well documented with comment lines in a standard format at the head of each piece of source code. In order for this collection to be efficiently used by a work group sharing a workstation, it was found that the creation of a library archive was most appropriate. The more, head, and grep commands with some occasional awking have proven most adequate for finding the subroutine desired and reviewing the documentation integrated in the source code collection.

The SLATEC Version 4.1 library was complied and created using g77 under Linux, and none of the sources required patching. There is one hitch: some of the routines call user supplied subroutines, and therefore, cannot be included in the library. These routines are bvder, bvpor, bvsup, dbvder, dbvpor, dbvsup, dexbvp, drkfab, exbvp and rkfab. The library was created by placing the script in Listing 3 along with all of the .f sources in the directory /usr/local/src/slatec and executing the script.

Listing 3

Shell Script to Create the SLATEC Library

The resulting library, libslatec.a, is placed in /usr/local/lib and can be accessed at compile time by any user, assuming /usr/local/lib is in their library path, with a command like:

g77 -o somefile somefile.f -lslatec

Conclusions

We have demonstrated that with a little work g77 can be used to compile very significant FORTRAN code packages. With the addition of two simple C routines, g77 was used to compile MCNP, and with no source code modification at all, it compiled the vast mathematical source collection know as SLATEC. g77 has proven to be a FORTRAN compiler that can truly make Linux on Intel hardware, a workstation option for the engineer and scientist, especially one on a budget.

Charles Kelsey and Gary Masters are Radiological Engineers at the Rocky Flats Environmental Technology Site. Gary's duties include general health physics, some light number crunching and the care and feeding of the department's UNIX workstations and DEC Alpha database server that runs VMS (yuck). Charles' duties include general health physics, some heavy number crunching and supplemental care and feeding of the department's UNIX workstations. He tries to stay away from VMS. These guys are so weird that they even write nuclear engineering applications for the HP48 calculator. Comments are welcome, and subject to being funneled to /dev/null, at ckelsey@devcg.denver.co.us and/or gmasters@devcg.denver.co.us. More information about Charles' and Gary's computational endeavors is available at http://www.csn.net/~ckelsey.