Porting Scientific and Engineering Programs to Linux
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.
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.
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Three More Lessons
- Django Models and Migrations
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- The Controversy Behind Canonical's Intellectual Property Policy
- Secure Server Deployments in Hostile Territory, Part II
- Shashlik - a Tasty New Android Simulator
- Huge Package Overhaul for Debian and Ubuntu
- General Relativity in Python
- Embed Linux in Monitoring and Control Systems