Legacy Fortran Codes Research Articles

Making legacy Fortran code type safe through automated program transformation

Fortran is still widely used in scientific computing, and a very large corpus of legacy as well as new code is written in FORTRAN 77. In general this code is not type safe, so that incorrect programs can compile without errors. In this paper, we present a formal approach to ensure type safety of legacy Fortran code through automated program transformation. The objective of this work is to reduce programming errors by guaranteeing type safety. We present the first rigorous analysis of the type safety of FORTRAN 77 and the novel program transformation and type checking algorithms required to convert FORTRAN 77 subroutines and functions into pure, side-effect free subroutines and functions in Fortran 90. We have implemented these algorithms in a source-to-source compiler which type checks and automatically transforms the legacy code. We show that the resulting code is type safe and that the pure, side-effect free and referentially transparent subroutines can readily be offloaded to accelerators.

EQMO: Equation of motion method for efficient electronic structure calculations

Equation of motion method has proven efficient for electronic structure calculations of very large systems, i.e. containing several million atoms. In this work, we redesign its previously published implementation and hereby release a revised software tool, EQMO, now capable of solving a crystalline TiO 2 test sample of nearly a quarter of a billion atoms on NEC SX-Aurora TSUBASA vector computer. The legacy code has been rewritten in modern free-form Fortran , and the main developments include MPI support and optimisations for parallel execution. Program Title: EQMO CPC Library link to program files: https://doi.org/10.17632/5m7jp4nb4y.1 Developer's repository link: https://git.icm.edu.pl/herman/eqmo Licensing provisions: GPLv3 Programming language: Fortran Journal reference of previous version: Marek T. Michalewicz, Herbert B. Shore, N. Tit, J.W. Halley, Equation of motion method for the electronic structure of disordered transition metal oxides , Comput. Phys. Commun. 71 (1992) 222–234. Does the new version supersede the previous version?: Yes Reasons for the new version: Major revision Summary of revisions: The legacy Fortran code has been rewritten in modern free-form Fortran. The OpenMP support has been replaced with OpenMPI suitable for NEC SX-Aurora TSUBASA architecture. The sequential and MPI versions can be built independently to produce two separate binary files for both x86_64 CPU and NEC vector computer. The program has been developed and tested with GNU Fortran and NEC Fortran compilers. Nature of problem: Electronic structure calculation of a large system, i.e. containing several million atoms, is a computationally demanding task. The problem is to determine electronic properties of solid state systems in an efficient manner. The program, at its current development stage, is capable of calculating electronic properties (density of electronic states) of rutile TiO 2 structure distorted by point defects , and is intended to be further developed towards treating a wide range of crystalline systems. Solution method: EQMO software tool is an equation of motion implementation designed to determine electronic structure (density of electronic states) of large-scale crystalline systems. The solution method is based on solving the Schrödinger equation with a tight-binding Hamiltonian, and its physical and mathematical foundations remain unchanged with respect to the previous release. For an explicit formalism with elaborate description, the reader is referred to the literature referenced below [1,2,3,4,5,6,7,8,9,10], and in particular – to the journal reference of the previous implementation along with the supplemented dataset [5]. The program is able to perform a benchmark on a TiO 2 sample of nearly a quarter of a billion atoms on NEC SX-Aurora TSUBASA vector computer, and its functionality can be further expanded. [1] J.W. Halley, Phys. Rev. B 36 (1987) 6640. [2] J.W. Halley, M.T. Michalewicz, N. Tit, Phys. Rev. B 41 (1990) 10165. [3] J.W. Halley, M. Kozlowski, M. Michalewicz, W. Smyrl, N. Tit, Surf. Sci. 256 (1991) 397–408. [4] Nacir Tit, J.W. Halley, M.T. Michalewicz, Surf. Interface Anal. 18 (1992) 87–92. [5] Marek T. Michalewicz, Herbert B. Shore, N. Tit, J.W. Halley, Comput. Phys. Commun. 71 (1992) 222–234. [6] Nacir Tit, J.W. Halley, Marek T. Michalewicz, H. Shore, Appl. Surf. Sci. 65/66 (1993) 246–251. [7] Marek T. Michalewicz, Comput. Phys. Commun. 79 (1994) 13–23. [8] Marek T. Michalewicz, Mark Priebatsch, Parallel Comput. 21 (1995) 853–870. [9] M.T. Michalewicz, Roger Brown, in: Computational Chemistry and Chemical Engineering, World Scientific, ISBN 978-981-4545-80-8, 1996, pp. 301–313. [10] Marek T. Michalewicz, Per Nyberg, Aust. J. Phys. 52 (5) (1999) 919–927.

Challenges and opportunities in New Zealand seismic hazard and risk modeling using OpenQuake

The corrected 2010 New Zealand National Seismic Hazard Model has been adapted for use in the Global Earthquake Model’s OpenQuake engine through an extensive benchmarking exercise with GNS Science’s legacy Fortran code. Resolution of differences between the legacy code and OpenQuake result in hazard curve output comparisons with discrepancies of less than 3% nationally and remaining discrepancies highlight challenges faced when moving away from in-house legacy code. OpenQuake’s multiple and varied computation options for both hazard and risk and OpenQuake’s consistent, software-friendly output formats allow for exploration and development of innovative approaches to future seismic hazard and risk modeling in New Zealand. The end-to-end seismic hazard-to-risk capabilities already enabled by the inclusion of New Zealand seismic hazard, vulnerability, and building exposure models in OpenQuake have already had significant impact on post-disaster response to the 2016 Kaikōura earthquake.

Automatic Pipelining and Vectorization of Scientific Code for FPGAs

There is a large body of legacy scientific code in use today that could benefit from execution on accelerator devices like GPUs and FPGAs. Manual translation of such legacy code into device-specific parallel code requires significant manual effort and is a major obstacle to wider FPGA adoption. We are developing an automated optimizing compiler TyTra to overcome this obstacle. The TyTra flow aims to compile legacy Fortran code automatically for FPGA-based acceleration, while applying suitable optimizations. We present the flow with a focus on two key optimizations, automatic pipelining and vectorization. Our compiler frontend extracts patterns from legacy Fortran code that can be pipelined and vectorized. The backend first creates fine and coarse-grained pipelines and then automatically vectorizes both the memory access and the datapath based on a cost model, generating an OpenCL-HDL hybrid working solution for FPGA targets on the Amazon cloud. Our results show up to 4.2× performance improvement over baseline OpenCL code.

Application Migration from Ultrix to Linux Operating System

During the recent twenty years there has been substantial investments aimed to migrate legacy application hosted on legacy operating systems to modern applications to be host on modern operating systems, This process can be expensive, both in terms of actual cost and the risk, the migration will lead to changing core applications and can significantly change the way the entire organization operates. Legacy systems are successful and therefore mature, and likely have been in existence for a long period of time. A consequence is that legacy software is built using technologies available at the time it was constructed, as opposed to the most modern software technologies. Older technologies are more difficult to maintain, and this is a key point of pain for many legacy system owners. The aim of this paper is to get a generic methodology for migrating application hosted on legacy UNIX (Ultrix) or its derivative to be hosted on modern Linux operating system. We have already got a legacy application hosted on Ultrix operating system as a case study and we will perform a successful migration to be host on Linux operating system through our proposed migration methodology.Simply the idea of our proposed method lies in getting the architectural and functional differences between Ultrix and Linux in order to get the best method for migration. The assumption is that RedHat and other Linux variants, being similar to Ultrix isn’t strictly true. After we had understood the functional differences between Ultrix and Linux, we had mappedsystem calls to a correct corresponding system calls in new modern platform in order to maintain the same behavior of application and overcoming the problem of endian. Moreover, there are differences in compiler options, building options, the synchronization methods used and signals. Furthermore, we got a methodology to migrate legacy Fortran code and Ingres database to modern ones. This paper organize into five sections, section one, introduction and overview on the Ultrix and Linux history, section two, challenges facing legacy application and why most organizations nowadays concerning with migration, section three, our proposed migration methodology and how overcoming the issues mentioned above in abstract, section four, summary and conclusion, and section five, references.

A Framework for Running the ADCIRC Discontinuous Galerkin Storm Surge Model on a GPU

Abstract Hybrid architectures utilizing GPUs provide a unique opportunity in a high performance computing environment. However, there are many legacy codes, particularly written in Fortran, that can not take immediate advantage of GPUs. Furthermore, many of these codes are under active development and so completely rewriting the code may not be an option. The advanced circulation and storm surge finite element model (ADCIRC) is one such code base. In this paper we present our semi-automatic methodology for porting portions of ADCIRC to run on the GPU and some preliminary scaling results of these subroutines. We have implemented a C++ array class and pre-processor macros to create a type of application framework to simplify the conversion and maintenance tasks. This allows the C++ syntax to be similar to Fortran, to provide for a more straight forward syntactical conversion from the original Fortran to C++ and simplified calling conventions between the two. After the necessary subroutines are converted to the C++ framework, the CUDA library can be easily used and also we are able to provide a simplified abstraction layer for accessing basic GPU functionality. For example, the problem of transferring the correct data on/o_ the GPU is addressed by our framework by a one time code change and a script to resolve data dependencies. Although it is currently specific to ADCIRC, our framework provides a starting point for utilizing GPUs with legacy Fortran codes, from which more specific GPU optimizations can be implemented.

Partial wave analysis using graphics processing units

Partial wave analysis is an important tool for determining resonance properties in hadron spectroscopy. For large data samples however, the un-binned likelihood fits employed are computationally very expensive. At the Beijing Spectrometer (BES) III experiment, an increase in statistics compared to earlier experiments of up to two orders of magnitude is expected. In order to allow for a timely analysis of these datasets, additional computing power with short turnover times has to be made available. It turns out that graphics processing units (GPUs) originally developed for 3D computer games have an architecture of massively parallel single instruction multiple data floating point units that is almost ideally suited for the algorithms employed in partial wave analysis. We have implemented a framework for tensor manipulation and partial wave fits called GPUPWA. The user writes a program in pure C++ whilst the GPUPWA classes handle computations on the GPU, memory transfers, caching and other technical details. In conjunction with a recent graphics processor, the framework provides a speed-up of the partial wave fit by more than two orders of magnitude compared to legacy FORTRAN code.

A comparison of methods for locating features in legacy software

Software engineers frequently need to locate the code that implements a specific feature of a program in order to fix a problem or add an enhancement. Several methods have recently been proposed to aid in feature location, notably the software reconnaissance method, which uses dynamic analysis of traces of execution, and the dependency graph method which involves static tracing of calling and data flow relationships in the program’s dependency graph. Most studies performed so far on these methods have used relatively modern C code. However there is a large body of existing legacy software in Fortran and similar languages which is often much more poorly structured. This paper describes a case study to locate two features in a sample of poorly structured legacy Fortran code. Both methods were applied to locate the features, along with the well known “grep” text search method for comparison. Both the software reconnaissance and dependency graph methods located both features, although some difficulties were encountered and adaptations were needed due to the very tangled nature of the code. The “grep” search method worked well for one of the two features, but was ineffective for the second, more complex case.

A CORBA-Based Distributed Component Environment for Wrapping and Coupling Legacy Scientific Codes

Within NASA's High Performance Computing and Communication (HPCC) program, the NASA Glenn Research Center (GRC) is developing a large scale, detailed simulation environment for the analysis and design of aircraft engines called the Numerical Propulsion System Simulation (NPSS). The three major aspects of modeling capabilities focused in NPSS, including integration of different engine components, coupling of multiple disciplines, and engine component zooming at appropriate level of fidelity, require relatively tight coupling of different analysis codes. Most of these codes in aerodynamics and solid mechanics are written in Fortran. Refitting these legacy Fortran codes with distributed objects can increase these codes reusability. In this paper, we describe our experiences in building a CORBA-based component development environment for programmers to easily wrap and couple legacy Fortran codes. This environment consists of a C++ wrapper library to hide the details of CORBA and an efficient remote variable scheme to facilitate data exchange between the client and the server. We also report empirical performance evaluation results and describe current applications.

Migrating legacy scientific applications towards CORBA‐based client–server architectures

AbstractA distributed object is a reusable, self‐contained piece of software that cooperates with other objects on the same machine or across a network in a plug‐and‐play fashion via a well‐defined interface. The Numerical Propulsion System Simulation (NPSS) attempts to provide a collaborative aircraft engine design and simulation environment based on this concept. Many scientific applications in aerodynamics and solid mechanics are written in Fortran. Refitting this legacy Fortran code with distributed objects can increase code reusability. In this paper, we focus on the novel use of a remote variable scheme to help programmers migrate the Fortran code towards a client–server architecture. This scheme gives the client the capability of accessing variables at the server site and makes it easier for programmers to couple component engine code. Through the operator overloading features in C++, remote variables can be used in much the same way as traditional variables. The remote variable scheme adopts the lazy update approach and the prefetch method. Preliminary performance evaluation shows that communication overhead can be greatly reduced. Copyright © 2001 John Wiley & Sons, Ltd.

A coupled model of water, heat and mass transfer using object orientation to improve flexibility and functionality

The challenge of our software development is to introduce user-friendly document-orientation and graphical features that are typical in Windows software and to retain the possibility of easily extending existing legacy Fortran code. Keys to this development were the use of five development tools and our special management of shared memory. Numerical development of the code was thus continued in Fortran while the newly introduced multiple-document interface allows the new graphical features that are considered more user friendly (e.g. tool bar, status bar, animation, etc.) can be further refined and adjusted using Visual C++6.0 and the MS Visual Studio. Object orientation makes it possible to include modules with different type of dependencies that restrict the user interface to the specific use of the model. A large number of sub-models are combined and all input/output data have been adapted to an object-oriented standard. Multiple-run features and built-in links to a common database are new important features.

Creating object-oriented designs from legacy FORTRAN code

The majority of scientific and engineering software systems currently in use are on average 10 to 15 years old. They have undergone extensive maintenance and, therefore, suffer from such problems as inaccurate or missing documentation, poorly structured code, and low modular cohesion. Moreover, the mere age of such systems has prohibited their realization of such recent innovations as object orientation. This paper addresses these concerns in the context of reverse engineering. It discusses the development of a method to identify objects in legacy systems, specifically those coded in the imperative language, FORTRAN-77. Algorithms that use a greedy approach to object extraction are presented. Viewing the subroutine as the unit of functionality, the attributes of candidate objects are extracted from two areas: parameters and global variables. Because FORTRAN-77 uses the COMMON block as the mechanism for realizing global variables, additional algorithms are presented to handle the resulting concerns. Using a modification of the program slicing concept introduced by Weiser in 1984, methods are defined for each set of attributes. The combination of the extracted attributes and methods forms the set of candidate objects. Throughout the paper, an example is used to illustrate the methodology.