Automatic Parallelization and OpenMP Offloadingof Fortran Array Notation
Explore the source record for details and available documents.
SEARCH · Engineering Papers
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
The University of Oregon has produced a Fortran parser based on an SDF (Syntax Definition Formalism) grammar. Primary partners in this effort were Rice University and Lawrence Livermore National Laboratory. The developed Fortran parser incorporates the full Fortran 2008 standard with extensions from the more recent document, TS 29113, “Further Interoperability of Fortran with C,” (to be included in the Fortran 2018 standard). In the final year of the project, the Fortran parser was updated to comply with the complete 2018 standard, as specified in the ISO/IEC document, JTC 1/SC 22/WG 5/N2146. The research explored in this project provided the expression of the Fortran grammar in SDF form for integration with the Rosebud DSL framework developed by Rice University. The Rosebud framework is a cohesive interface allowing modular DSL plugins to be developed independently and then distributed and combined in HPC applications. These plugins implement a form of generalized DSL which includes both concrete languages used to write application source code and abstract languages used within the compilation process. ROSE’s predefined DSL Building Blocks (for example the Fortran base language) are represented as abstract language plugins and DSL developers can use Rosebud to construct additional building blocks in the same way.
High Performance Fortran (HPF), the high-level language for parallel Fortran programming, is based on Fortran 90. HALF was defined by an informal standards committee known as the High Performance Fortran Forum (HPFF) in 1993, and modeled on TMC's CM Fortran language. Several HPF features have since been incorporated into the draft ANSI/ISO Fortran 95, the next formal revision of the Fortran standard. HPF allows users to write a single parallel program that can execute on a serial machine, a shared-memory parallel machine, or a distributed-memory parallel machine. HPF eliminates the complex, error-prone task of explicitly specifying how, where, and when to pass messages between processors on distributed-memory machines, or when to synchronize processors on shared-memory machines. HPF is designed in a way that allows the programmer to code an application at a high level, and then selectively optimize portions of the code by dropping into message-passing or calling tuned library routines as 'extrinsics'. Compilers supporting High Performance Fortran features first appeared in late 1994 and early 1995 from Applied Parallel Research (APR) Digital Equipment Corporation, and The Portland Group (PGI). IBM introduced an HPF compiler for the IBM RS/6000 SP/2 in April of 1996. Over the past two years, these implementations have shown steady improvement in terms of both features and performance. The performance of various hardware/ programming model (HPF and MPI (message passing interface)) combinations will be compared, based on latest NAS (NASA Advanced Supercomputing) Parallel Benchmark (NPB) results, thus providing a cross-machine and cross-model comparison. Specifically, HPF based NPB results will be compared with MPI based NPB results to provide perspective on performance currently obtainable using HPF versus MPI or versus hand-tuned implementations such as those supplied by the hardware vendors. In addition we would also present NPB (Version 1.0) performance results for the following systems: DEC Alpha Server 8400 5/440, Fujitsu VPP Series (VX, VPP300, and VPP700), HP/Convex Exemplar SPP2000, IBM RS/6000 SP P2SC node (120 MHz) NEC SX-4/32, SGI/CRAY T3E, SGI Origin2000.
VENTSAR: Originated as VENTAX (Smith and Weber 1983) on the IBM Mainframe at the Savannah River Site (SRS) as a Fortran program. Updated to VENTSAR XL V1.0 (Simpkins 1997) as a spreadsheet version using macros created in Microsoft Excel. Later updated to VENTSAR XL V2.0 (Dixon 2018) as a spreadsheet executing a modified version of the original VENTAX Fortran code. Estimates contaminant concentrations on or near a building from a release at a nearby location. Calculates concentrations for a given meteorological exceedance probability or for a given stability and wind speed combination. Can model a single building with or without a penthouse on top or a ground location from either a stack or ground release. Plume rise can be considered. Contaminant releases can be chemical or radioactive with downwind concentrations determined at user-specified distances. Wind passing over and around buildings creates a complicated dispersion pattern. Air-intake vents may be located on building roofs or near the ground downwind of a release source. An estimation of pollutant concentrations on or near a structure is important in determining expected pollutant levels. Meteorological data are selected based on a specific area of the site. Fortran-based VENTAX able to make fast, complex mathematical calculations. Not user-friendly VENTSAR XL V1.0 no longer supported due to obsolete Excel macros. VENTSAR XL V2.0 an interim solution using an Excel spreadsheet to interface with the modified VENTAX Fortran code. Requires user to have Microsoft Excel. Not an intuitive interface for someone unfamiliar with VENTSAR. Does not perform dose calculations. VENTSAR V3.0 goal to combine the strengths of previous versions of VENTSAR into a single, powerful yet user-friendly program with a Graphical User Interface (GUI). Not dependent upon a specific program or plug-ins. Self-contained package to be used on any computer running Microsoft Windows. User-friendly, intuitive GUI created in Python for parameter input. Executes same modified VENTAX Fortran code as VENTSAR XL V2.0. Outputs formatted text file of completed calculations for easy review and dissemination. Performs inhalation and plume shine dose calculations for up to 11 user-selected nuclides from a nuclide dose factor library of almost 500 nuclides. 12 test cases were created for verification of V1.0 and V2.0. Same test cases run in V3.0 to verify correct performance. V3.0 produced similar results to V1.0. Confirmed GUI did not alter calculations in any way. Comparisons of the test case results confirm the V3.0 GUI does not influence the VENTSAR calculations. Simply passes same input parameters to VENTAX Fortran code for execution. Provides end user an easy-to-use, intuitive tool to quickly make building effect and plume rise calculations, as well as, inhalation and plume shine dose calculations. No experience with or working knowledge of Fortran, Excel, command line, or macros required. Self-contained package allows VENTSAR be deployed to any Windows computer without the need for specific programs or plug-ins.
Recently, there has been an increase in the development of intelligent engine technology with advanced active component control. The computer engine models used in these control studies are component-level models (CLM), models that link individual component models of state space and nonlinear algebraic equations, written in a computer language such as Fortran. The difficulty faced in performing control studies on Fortran-based models is that Fortran is not supported with control design and analysis tools, so there is no means for implementing real-time control. It is desirable to have a simulation environment that is straightforward, has modular graphical components, and allows easy access to health, control, and engine parameters through a graphical user interface. Such a tool should also provide the ability to convert a control design into real-time code, helping to make it an extremely powerful tool in control and diagnostic system development. Simulation time management is shown: Mach number versus time, power level angle versus time, altitude versus time, ambient temperature change versus time, afterburner fuel flow versus time, controller and actuator dynamics, collect initial conditions, CAD output, and component-level model: CLM sensor, CAD input, and model output. The Controls and Dynamics Technologies Branch at the NASA Glenn Research Center has developed and demonstrated a flexible, generic turbofan engine simulation platform that can meet these objectives, known as the Modular Aero-Propulsion System Simulation (MAPSS). MAPSS is a Simulink-based implementation of a Fortran-based, modern high pressure ratio, dual-spool, low-bypass, military-type variable-cycle engine with a digital controller. Simulink (The Mathworks, Natick, MA) is a computer-aided control design and simulation package allows the graphical representation of dynamic systems in a block diagram form. MAPSS is a nonlinear, non-real-time system composed of controller and actuator dynamics (CAD) and component-level model (CLM) modules. The controller in the CAD module emulates the functionality of a digital controller, which has a typical update rate of 50 Hz. The CLM module simulates the dynamics of the engine components and uses an update rate of 2500 Hz, which is needed to iterate to balance mass and energy among system components. The actuators in the CAD module use the same sampling rate as those in the CLM. Two graphs of normalized spool speed versus time in seconds and one graph of normalized average metal temperature versus time in seconds is shown. MAPSS was validated via open-loop and closed-loop comparisons with the Fortran simulation. The preceding plots show the normalized results of a closed-loop comparison looking at three states of the model: low-pressure spool speed, high-pressure spool speed, and the average metal temperature measured from the combustor to the high-pressure turbine. In steady state, the error between the simulations is less than 1 percent. During a transient, the difference between the simulations is due to a correction in MAPSS that prevents the gas flow in the bypass duct inlet from flowing forward instead of toward the aft end, which occurs in the Fortran simulation. A comparison between MAPSS and the Fortran model of the bypass duct inlet flow for power lever angles greater than 35 degrees is shown.
The Fortran sub-committee of the MPI-3 Forum would like to define the MPI Fortran interface with explicit interfaces. To ease the implementation of portable MPI libraries, it would be helpful if this interface can be defined as BIND (C). With BIND (C), the MPI library can be implemented portably across different Fortran compilers. For backward-compatibility reasons, it is essential to guarantee that existing MPI programs still run with MPI libraries based on the new Fortran 2003 compatible MPI interface specification. To achieve this goal, all existing intrinsic (with default kind parameter) and derived Fortran types should be usable as actual arguments in routines defined with BIND (C), Unfortunately, intrinsic Fortran types with default kind parameter may not be interoperable.
Given a pre-trained neural network, Inference-Engine performs maps network inputs to outputs by executing the forward pass through the provided network. Although the predominant programming language for machine-learning is Python, most high-performance computing (HPC) applications are written in Fortran, C, or C++. Inference-Engine aims to support HPC programs and is written in Fortran, a language with a large feature set supporting interoperability with C. This software exposes concurrency in a portable way by using standard language features that some modern Fortran compilers can exploit with various optimizations, including offloading computation to a Graphics Processing Unit (GPU). In particular, this software makes extensive use of Fortran's "do concurrent" parallel loop construct, implicitly parallel array statements, and pure procedures that can be invoked inside "do concurrent" blocks. Inference-Engine also supports dynamic choice of inference methods at runtime. Two current options include one method that uses Fortran's "dot_product" intrinsic function inside "do concurrent" blocks and another method that instead uses Fortran' "matmul" array intrinsic function. We plan to investigate automatic compiler offloading of "do concurrent" calculations to GPUs and compile-time substitution of optimized libraries such as the Basic Linear Algebra Library (BLAS) for "matmul" invocations. We also envision the potential for the choice of which method to use could happen at program launch based on in situ performance measurements on any given platform.
With the development of a Fortran Interface to Trilinos, ForTrilinos, modelers using modern Fortran will be able to provide their codes the capability to use solvers and other capabilities on exascale machines via a straightforward infrastructure that accesses Trilinos. This document outlines what ForTrilinos does and explains briefly how it works. We show it provides a general access to packages via an entry point and uses an xml file from fortran code. With the first release, ForTrilinos will enable Teuchos to take xml parameter lists from Fortran code and set up data structures. It will provide access to linear solvers and eigen solvers. Several examples are provided to illustrate the capabilities in practice. We explain what the user should have already with their code and what Trilinos provides and returns to the Fortran code. We provide information about the build process for ForTrilinos, with a practical example. In future releases, nonlinear solvers, time iteration, advanced preconditioning techniques, and inversion of control (IoC), to enable callbacks to Fortran routines, will be available.
The manual is intended to show the revisions and additions to the current STAR FORTRAN. The changes are made to incorporate an FMP (Flow Model Processor) for use in the Numerical Aerodynamic Simulation Facility (NASF) for the purpose of simulating fluid flow over three-dimensional bodies in wind tunnel environments and in free space. The FORTRAN programming language for the STAR-100 computer contains both CDC and unique STAR extensions to the standard FORTRAN. Several of the STAR FORTRAN extensions to standard FOR-TRAN allow the FORTRAN user to exploit the vector processing capabilities of the STAR computer. In STAR FORTRAN, vectors can be expressed with an explicit notation, functions are provided that return vector results, and special call statements enable access to any machine instruction.
The ForTrilinos subproject of the Exascale Computing Project (ECP) was initiated to bring the capabilities and scalability of the Trilinos numerical solver collection to Fortran scientific application codes. A novel Fortran extension to the Simplified Wrapper and Interface Generator (SWIG) tool, which automatically generates Fortran bindings from existing C/C++ library code, has been applied to key Trilinos solver libraries to generate the new ForTrilinos libraries. SWIG-Fortran has additionally been used to generate new Fortran compatibility layers for additional scientific libraries and applications. This report summarizes the products and impact of the ForTrilinos subproject.
The parallel implementation of scientific computing environment (PISCES) is a project to provide high-level programming environments for parallel MIMD computers. Pisces 1, the first of these environments, is a FORTRAN 77 based environment which runs under the UNIX operating system. The Pisces 1 user programs in Pisces FORTRAN, an extension of FORTRAN 77 for parallel processing. The major emphasis in the Pisces 1 design is in providing a carefully specified virtual machine that defines the run-time environment within which Pisces FORTRAN programs are executed. Each implementation then provides the same virtual machine, regardless of differences in the underlying architecture. The design is intended to be portable to a variety of architectures. Currently Pisces 1 is implemented on a network of Apollo workstations and on a DEC VAX uniprocessor via simulation of the task level parallelism. An implementation for the Flexible Computing Corp. FLEX/32 is under construction. An introduction to the Pisces 1 virtual computer and the FORTRAN 77 extensions is presented. An example of an algorithm for the iterative solution of a system of equations is given. The most notable features of the design are the provision for several granularities of parallelism in programs and the provision of a window mechanism for distributed access to large arrays of data.
Issues involved in the continuing development of an advanced simulation complex are discussed. This approach provides the capability to perform the majority of tests on advanced systems, non-destructively. The controlled test environments can be replicated to examine the response of the systems under test to alternative treatments of the system control design, or test the function and qualification of specific hardware. Field tests verify that the elements simulated in the laboratories are sufficient. The digital computer is hosted by a Digital Equipment Corp. MicroVAX computer with an Aptec Computer Systems Model 24 I/O computer performing the communication function. An Applied Dynamics International AD100 performs the high speed simulation computing and an Evans and Sutherland PS350 performs on-line graphics display. A Scientific Computer Systems SCS40 acts as a high performance FORTRAN program processor to support the complex, by generating numerous large files from programs coded in FORTRAN that are required for the real time processing. Four programming languages are involved in the process, FORTRAN, ADSIM, ADRIO, and STAPLE. FORTRAN is employed on the MicroVAX host to initialize and terminate the simulation runs on the system. The generation of the data files on the SCS40 also is performed with FORTRAN programs. ADSIM and ADIRO are used to program the processing elements of the AD100 and its IOCP processor. STAPLE is used to program the Aptec DIP and DIA processors.
Fortran and C++ are the dominant programming languages used in scientific computation. Consequently, extensions to these languages are the most popular for programming massively parallel computers. We discuss two such approaches to parallel Fortran and one approach to C++. The High Performance Fortran Forum has designed HPF with the intent of supporting data parallelism on Fortran 90 applications. HPF works by asking the user to help the compiler distribute and align the data structures with the distributed memory modules in the system. Fortran-S takes a different approach in which the data distribution is managed by the operating system and the user provides annotations to indicate parallel control regions. In the case of C++, we look at pC++ which is based on a concurrent aggregate parallel model.
Many people use compound equilibrium programs for very different reasons, varying from refrigerators to light bulbs to rockets. A commonly used equilibrium program is CEA. CEA can take various inputs such as pressure, temperature, and volume along with numerous reactants and run them through equilibrium equations to obtain valuable output information, including products formed and their relative amounts. A little over a year ago, Bonnie McBride created the program subeq with the goal to simplify the calling of CEA. Subeq was also designed to be called by other programs, including Excel, through the use of Visual Basic for Applications (VBA). The largest advantage of using Excel is that it allows the user to input the information in a colorful and user-friendly environment while allowing VBA to run subeq, which is in the form of a FORTRAN DLL (Dynamic Link Library). Calling subeq in this form makes it much faster than if it were converted to VBA. Since subeq requires such large lists of reactant and product names, all of which can't be passed in as an array, subeq had to be changed to accept very long strings of reactants and products. To pass this string and adjust the transfer of input and output parameters, the subeq DLL had to be changed. One program that does this is Compaq Visual FORTRAN, which allows DLLs to be edited, debugged, and compiled. Compaq Visual FORTRAN uses FORTRAN 90/95, which has additional features to that of FORTRAN 77. My goals this summer include finishing up the excel spreadsheet of subeq, which I started last summer, and putting it on the Internet so that others can use it without having to download my spreadsheet. To finish up the spreadsheet I will need to work on debugging current options and problems. I will also work on making it as robust as possible, so that all errors that may arise will be clearly communicated to the user. New features will be added old ones will be changed as I receive comments from people using the spreadsheet. To implement this onto the Internet, I will need to develop an XML input/output format and learn how to write HTML.
ForTrilinos stands for interfaces to Trilinos. It effectively replaces common practices for interfacing Fortran codes with Trilinos C++ packages. Common practices include writing user-specific drivers and exploiting the name-mangling schemes of specific compilers. ForTrilinos improves portability and robustness by exploiting the C interoperability constructs of Fortran 2003. These constructs facilitate binding Fortran interface bodies to their equivalent C function prototypes, providing for name resolution independent of the compiler™s underlying mangling scheme and guaranteeing compatible type bit representations. Furthermore, ForTrilinos maintains the overall design philosophy and architecture of Trilinos by creating a derived type structure in Fortran similar to the class hierarchy in the underlying C++.ForTrilinos can be applied wherever the underlying Trilinos packages can be applied.
Pyranda Is fortran 90 code which solves compact finite difference equations on a three dimensional fortran arrays, domain decomposed using the Message Passing Interface (MPI). The fortran source solves the linear system of equations which forms a pentadtagona1 matrix. Derivatives are used to construct hyperbolic partlal differential equation (PDE) operators, namely gradient, divergence, Laplacian, and curl operators. 5. Solution Method: The library provides a python Interface which facilitates problem setup and description. However, the core solver Is written in the fortran 90 language. The solver couples MPI communication and linear solves together so that a direct (non-iterative) solution to the linear system of equations can be computed with minimal communication. Domain decomposition is limited to a uniform data size but provides perfect load balancing. 6. Computer for which the code Is written:
'ForTrilinos' is related to The Trilinos Project, which contains a large and growing collection of solver capabilities that can utilize next-generation platforms, in particular scalable multicore, manycore, accelerator and heterogeneous systems. Trilinos is primarily written in C++, including its user interfaces. While C++ is advantageous for gaining access to the latest programming environments, it limits Trilinos usage via Fortran. Sever ad hoc translation interfaces exist to enable Fortran usage of Trilinos, but none of these interfaces is general-purpose or written for reusable and sustainable external use. 'ForTrilinos' provides a seamless pathway for large and complex Fortran-based codes to access Trilinos without C/C++ interface code. This access includes Fortran versions of Kokkos abstractions for code execution and data management.